Índice

Objetivo

O objetivo da InternalId é permitir trafegar em um só campo a composição da chave das entidades de cada produto. Isto foi necessário, pois várias entidades dos produtos possuem composições de chaves diferentes e não pode ser responsabilidade dos produtos entender a complexidade da composição destas chaves uns dos outros.

Bloco de código

title	Exemplo

Fornecedor no Protheus: empresa + filial + loja + código
Fornecedor no Logix: empresa + código

Para o Logix o campo Loja do Protheus não faz sentido, portanto não alterará o produto para começar a reconhecer uma loja. Ao mesmo tempo em que Logix só tem campo “empresa” e Protheus trabalha com “empresa + filial”.

Utilizando a InternalId e o ferramental de de/para disponível, será possível associar a empresa da seguinte forma:

Empresa Logix 23 == Empresa Protheus 50|10 ou seja, a empresa 23 do Logix corresponde a empresa 50 e filial 10 do Protheus.

Ao compor o valor da InternalId o caracter “|” (pipe) é recomendado a ser utilizado como separador.

A definição atual é que toda mensagem que for enviada por um produto levará os seus próprios códigos. Ou seja, não deverá existir um cenário, onde um produto possuindo um de/para próprio deverá enviar o código do produto oposto integrado em uma mensagem.

O funcionamento e forma de tratamento que o adapter deverá fazer para a chave interna recebida permitirá saber que, por exemplo, o CompanyInternalId do Logix com o valor 23 corresponde ao CompanyInternalId do Protheus valor 50|10. O adapter do Protheus assim como de qualquer outro produto, deverá estar preparado para extrair da informação “50|10” o código da empresa e código da filial, pois o Protheus tem condições de reconhecer esta estrutura.

Por mais que sempre existirão juntas as tags próprias (exemplo: CompanyId e BranchId) e as tags de InternalId (CompanyInternalId) o ideal é que os adapters passem a priorizar o reconhecimento das informações recebidas via InternalId. Ou seja, se a CustomerInternalId recebida em uma mensagem já existe nos valores de de/para do produto, quer dizer que já existe um registro local associado. Sendo assim, é mais fácil extrair da informação “50|123456” o código da empresa e cliente do Logix, do que resolver separadamente os de/para de empresa e de cliente, caso fosse esta a estratégia.

Identificação única de De/Para de InternalId

Atualmente cada produto (ex.: Logix, Datasul, Protheus e RM) tem seu próprio ferramental de de/para, ou seja, conjunto de tabelas e funções que permitem gravar valores de de/para referente a um determinado produto.

Bloco de código

title	Exemplo Logix
collapse	true

Tabela VDP_DPARA_GERAL
   TABELA_DPARA    CHAR(18)
   CAMPO_DPARA     CHAR(150)
   CARACTER_LOGIX  CHAR(150)
   SISTEMA_INTEGR  CHAR(20)
   CARACTER_INTEGR CHAR(150)

Este ferramental de de/para que cada produto possui, armazena as informações relativas a si mesmo, ou seja código 50 do sistema externo corresponde ao código 23 da tabela empresa, campo cod_empresa.

Porém, a partir do momento que existe uma mensagem única entre os produtos, e esta mensagem única possui um determinado campo que em que todos os produtos terão um de/para, nada mais certo que este de/para que será alimentado também tenha um nome único entre os produtos.

Por isso, ficou definido que deverá existir para cada campo que possua um InternalId, um nome único entre todos os produtos. Este nome será sempre “Nome da Mensagem”.

InternalId para a mensagem City: City.
InternalId para a mensagem CustomerVendor: CustomerVendor.

Informações

title	Importante

Este padrão é válido para o retorno do de/para por parte do aplicativo destino. Nos casos em que é necessário trafegar na mensagem um InternalId que representa uma chave estrangeira, o padrão adotado deve ser Nome da Mensagem + "InternalId", conforme descrito mais adiante.

Assim, tendo os ferramentais de de/para de cada produto uma referência a este nome, será possível no futuro fazer uma rotina de conferência de integridade de de/para entre os produtos.

Múltiplas referências a uma InternalId na mesma mensagem

Vamos supor que a mensagem DeliverySchedule tenha os campos OriginCityCode e DestinationCityCode, consequentemente existirão os campos OriginCityInternalId e DestinationCityInternalId. A existência destes dois campos não significa que haverá dois de/para diferentes, um para Origin e outro para Destination, o de/para deverá ser o mesmo, ou seja, CityInternalId, pois a origem da informação é a mesma.

Esta mesma regra vale para quando o campo da chave estrangeira, por qualquer motivo, não tem um nome idêntico ao padrão “Mensagem”+InternalId, não necessariamente precisa existir dois campos com a mesma fonte de informação na mesma mensagem.

Mensagem Order
- Campos VendorCode e VendorInternalId

Utilização na mensagem

A chave interna (InternalId) é utilizada em dois contextos, como chave primária e como chave estrangeira.

Regra para chave primária

Toda mensagem que seja de evento, deverá ter uma tag InternalId dentro de seu "BusinessContent" que irá trafegar a composição de chave da sua entidade. Deve-se ressaltar que mesmo que em um produto a chave de uma entidade não for composta deve-se utilizar a InternalId, pois se está é simples em um produto, mesmo assim poderá ser composta em outro.

Esta tag deverá estar localizada logo abaixo dos campos da mensagem, que fazem parte da sua composição. O exemplo a seguir é um trecho do schema RefundReason_1_000.json.

Bloco de código

title	RefundReason_1_000
collapse	true

(...)
				"Code": {
					"description": "Código do Motivo",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"field": "G8P.G8P_CODIGO",
							"required": true,
							"type": "Char",
							"length": "4",
							"note": "",
							"available": true,
							"canUpdate": false
						}
					]
				},
				"InternalId": {
					"description": "InternalId do Motivo",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"field": "cEmpAnt+G8P.G8P_FILIAL+G8P.G8P_CODIGO",
							"required": true,
							"type": "Char",
							"length": "136",
							"note": "",
							"available": true,
							"canUpdate": false
						}
					]
				},
(...)

Suponhamos que em um cenário tenhamos CompanyId com valor 23 e Code com valor 50. O internalId trafegado seguiria então a seguinte lógica:

Bloco de código

title	Exemplo

"CompanyId": "23"
"Code": "50"
"InternalId": "23|50"

Toda mensagem de evento (quando for Upsert) deverá conter em seu conteúdo de retorno "ReturnContent" campos de InternalId para armazenar a chave interna do gerador do evento e a chave interna gerada no recebedor do evento. A necessidade disso é para que o recebedor da mensagem de evento e o gerador da mensagem de evento tenham conhecimento da chave interna gerada em cada produto. O fluxo abaixo exemplifica este funcionamento, para o cenário de inclusão de um novo Cliente.

Image Added

Desta forma, a tag "ReturnContent" da mensagem (ainda utilizando RefundReason_1_000.json como exemplo) seria construída da seguinte forma:

Bloco de código

title	Exemplo
collapse	true

(...)
		"ReturnContentType": {
			"type": "object",
			"properties": {
				"ListOfInternalId": {
					"type": "array",
					"items": {
						"$ref": "https://raw.githubusercontent.com/totvs/ttalk-standard-message/master/jsonschema/schemas/types/ListOfInternalId_1_000.json#/definitions/ListOfInternalIdType",
						"type": "object"
					}
				}
			}
		}

O ListOfInternalIdType está definido em um arquivo a parte e está estruturado conforme o exemplo abaixo:

Bloco de código

title	Trecho do ListOfInternalIdType
collapse	true

(...)
"definitions": {
		"ReturnContentWithModelType": {
			"type": "object",
			"properties": {
				"ListOfInternalId": {
					"type": "object",
					"$ref": "#/definitions/ListOfInternalIdType"
				}
			}
		},
		"ListOfInternalIdType": {
			"type": "array",
			"items": {
				"$ref": "#/definitions/InternalIdType",
				"type": "object"
			}
		},
		"InternalIdType": {
			"type": "object",
			"properties": {
				"name": {
					"description": "Nome da InternalId, este nome será padronizado entre todas as linhas e  corresponderá ao nome da própria transação. Exemplo: City, Item, CustomerVendor. Observação: em outras partes da mensagem, que não sejam a tag ListOfInternalId, a regra pode ser diferente. Para mais informações, consulte  http://tdn.totvs.com/pages/viewpage.action?pageId=181142263",
					"type": "string"
				},
				"origin": {
					"description": "InternalId da origem",
					"type": "string"
				},
				"destination": {
					"description": "InternalId do destino",
					"type": "string"
				}
			}
		}
	}
(...)

Como este retorno representa a resposta de uma mensagem enviada, deve-se entender a tag "origin" como a InternalId do produto que enviou a mensagem (a origem), e "destination" como a InternalId do produto que foi o destino da mensagem.

Regra para chave estrangeira

A utilização da InternalId se aplica também para chaves estrangeiras. Porém, neste caso a regra é que para cada tag que representar uma chave estrangeira também exista uma tag InternalId correspondente.

Na mensagem Warehouse_1_002 temos o seguinte trecho de definições:

Bloco de código

title	Warehouse 1_002
collapse	true

(...) 
				"InternalId": {					
					"description": "InternalId de Integração para o Grupo de Produto",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"available": true,
							"note": "O InternalID do Codigo do Armazém é formado por EMPRESA|NNR_FILIAL|NNR_CODIGO",
							"field": "EMPRESA|NNR_FILIAL|NNR_CODIGO",
							"length": "50",
							"type": "string"
						}
					]
				},
				"Code": {
					"description": "Código do Local de Estoque (armazém/almoxarifado/depósito)",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"available": true,
							"note": "Pode ter tamanho entre 02 e 06 dependendo da configuração do Protheus",
							"field": "NNRXX0.NNR_CODIGO",
							"length": "2",
							"type": "string",
							"required": true
						}
					]
				},
				"Description": {
					"description": "Descrição do Local de Estoque",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"available": true,
							"note": "Descrição do Local de Estoque(armazém/almoxarifado/depósito)",
							"field": "NNRXX0.NNR_DESCRI",
							"length": "20",
							"type": "string"
						}
					]
				}
(...)

Já na mensagem Item_4_006 temos o seguinte trecho de definições:

Bloco de código

title	Item_4_006
collapse	true

(...)
                "Code": {
					"description": "Código Item",
					"type": "string",
					"maxLength": 30,
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"field": "SB1.B1_COD",
							"required": true,
							"type": "char",
							"length": "15",
							"note": "campo expansivel ate 30",
							"available": true,
							"canUpdate": false
						},
						{
							"product": "RM",
							"field": "TPRODUTO.CODIGOPRD",
							"required": true,
							"type": "varchar",
							"length": "30",
							"note": "Código do produto",
							"available": true,
							"canUpdate": false
						}
					]
				},
				"InternalId": {
					"description": "InternalId de Integração",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"field": "SB1.B1_FILIAL+SB1.B1_COD",
							"required": true,
							"type": "char",
							"length": "",
							"note": "",
							"available": true,
							"canUpdate": false
						},
						{
							"product": "RM",
							"field": ".",
							"required": true,
							"type": "varchar",
							"length": "6",
							"note": "O InternalID do Produto é formado por TPRODUTO.CODCOLIGADA|TPRODUTO.IDPRD",
							"available": true,
							"canUpdate": false
						}
					]
				},


(...)
                "StandardWarehouseCode": {
					"description": "Código Depósito Padrão",
					"type": "string",
					"maxLength": 10,
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"field": "SB1.B1_LOCPAD",
							"required": true,
							"type": "char",
							"length": "2",
							"note": "",
							"available": true,
							"canUpdate": false
						},
						{
							"product": "RM",
							"field": "tabela.campo",
							"required": false,
							"type": "",
							"length": "",
							"note": "Não utiliza",
							"available": true,
							"canUpdate": false
						}
					]
				},
				"StandardWarehouseInternalId": {
					"description": "InternalId da chave completa de Depósito Padrão do produto",
					"type": "string",
					"x-totvs": [
						{
							"product": "PROTHEUS",
							"field": "NNR.NNR_FILIAL+SB1.B1_LOCPAD",
							"required": false,
							"type": "",
							"length": "",
							"note": "",
							"available": true,
							"canUpdate": false
						},
						{
							"product": "RM",
							"field": "tabela.campo",
							"required": false,
							"type": "",
							"length": "",
							"note": "Não utiliza",
							"available": true,
							"canUpdate": false
						}
					]
				},
				"StandardWarehouseDescription": {
					"description": "Descrição Depósito Padrão",
					"type": "string",
					"maxLength": 40,
					"x-totvs": [
						{
							"product": "RM",
							"field": "tabela.campo",
							"required": false,
							"type": "",
							"length": "",
							"note": "Não utiliza",
							"available": true,
							"canUpdate": false
						}
					]
				},


(...)

Recomenda-se que a InternalId de chave estrangeira tenha o mesmo nome da tag normal – referenciando o InternalId de Warehouse, seria então WarehouseInternalId. No caso do exemplo acima, o analista optou por chamar de StandardWarehouseInternalId. Não há problema, porém é necessário que as outras definições que fazem referência a Warehouse sigam o mesmo padrão (StandardWarehouseCode e StandardWarehouseDescription).

Em qualquer posição que ocorra (sendo chave primária ou estrangeira), a tag InternalId sempre será uma tag "type":”string” sem tamanho definido.

Para a chave estrangeira o adapter também deverá dar prioridade em resolver o relacionamento pela InternalId. Ou seja, ao receber uma mensagem de Item (seguindo o exemplo), este deve primeiro consultar no seu ferramental de de/para se existe registro correspondente para o WarehouseInternaId recebido, pois este valor já irá fornecer a chave completa correspondente no produto.

Utilização no Adapter

É sabido que cada mensagem única terá um único adapter/versão nos produtos. Com o objetivo de centralizar a regra para composição da chave da InternalId é interessante que cada adapter seja responsável por receber os valores das chaves e concatena-los para a composição da InternalId. Se isto ficar a cargo de cada programa ou adapter que for utilizar o valor, este poderá correr o risco de ser concatenado de formas diferentes em cada ponto em que seja necessário, o que irá prejudicar completamente o funcionamento do recurso.

Ou seja, o adapter da mensagem Item deverá ter um método que recebe os valores da chave e retorne estes concatenados. Ao mesmo tempo que deverá ter um método que recebe o valor da InternalId e retorna o valor correspondente a uma informação da composição desta. Todos os adapters de mensagens que tenham o Item como chave estrangeira utilizarão esta mesma função.

Desta forma, utilizando sempre este mesmo mecanismo onde for necessário, será garantido que o valor será composto sempre da mesma forma e devolvido sempre da mesma forma também.

Bloco de código

title	Exemplo (em pseudocódigo)

Adapter da mensagem Item

	AdapterItem.Get_InternalId(cod_empresa, cod_filial, item)

	Retorna Empresa + “|” + Filial + “|” + Código

	Uso: AdapterItem.Get_InternalId(50,10,123456) =  “50|10|123456”


	AdapterItem.Get_InternalId_Value(InternalId, Campo)

	Retorna <retorna o valor correspondente a posição de “Campo”>

	Uso: AdapterItem.Get_InternalId_Value(“50|10|123456”,”cod_empresa”) == “123456”

Estrutura

A comunicação através do protocolo transaction (EAI) possui uma estrutura composta dos seguintes elementos:

Emissor/Receptor: correspondem aos aplicativos (ERPs) dos quais se origina (emissor) e para os quais se destina (receptor) a mensagem.
Mensagem: corresponde ao conteúdo que trafega entre o emissor e o receptor.
Interface: correspondem aos endpoints (/totvseai/standardmessage/v1/transactions) que permitem o envio e recebimento das mensagens.

O canal em que essa comunicação acontece pode ser algum dos seguintes:

REST
AMQP
SOAP (Legado)

Graficamente, a estrutura pode ser descrita conforme abaixo:

Image Removed

Funcionamento

Os modos de operação podem ser: síncrono e assíncrono, sendo que neste último temos a necessidade de uma fila e de um agente que se responsabilize por sua gestão (processador de fila).

A geração das mensagens é responsabilidade dos adapters, que entregam para a Engine do EAI a estrutura de dados necessária para gerar a mensagem no padrão TOTVS. Da mesma, forma o recebimento das mensagens é intermediada pelo Engine de EAI, que determinará qual o adapter responsável por processar a mensagem recebida.

O uso do InternalId é obrigatório nesse modelo.

Mensagem

A mensagem padronizada, utilizada através de transactions (EAI), é composta dos elementos Header e Content.

Header: contem informações sobre a mensagem sendo trafegada, como seu identificador único, data em que foi gerada, transação ao qual se refere, entre outras.

UUID: Identificador único desta mensagem e que não pode ser igual ao UUID de qualquer outra mensagem em qualquer um dos aplicativos participantes da integração.
Type: Identifica o tipo da mensagem (BusinessMessage, ReceiptMessage ou ResponseMessage).
SubType: Os valores esperados para o atributo subType são event e request;
Event: quando SubType é event, este atributo conterá os valores upsert ou delete, para indicar que a mensagem corresponde a uma inclusão/alteração ou a uma eliminação, respectivamente. Ele não é utilizado quando o SubType é request.
Transaction: identificador do tipo de transação da mensagem. Esta informação será utilizada pelos aplicativos para definir como os dados serão processados no recebimento.
Version: Identifica qual a versão daquela mensagem de negócio. Uma mensagem de Item, por exemplo, pode sofrer alterações no decorrer do tempo, sendo que cada uma destas alterações irá afetar esta informação.
SourceApplication: Identifica a instancia dos aplicativos TOTVS que gerou a mensagem. Uma instância representa uma instalação/configuração daquele aplicativo/produto. Caso duas instancia do mesmo aplicativo participem da mesma integração, cada um deverá ser identificado de forma única.
ProductName: Identifica o produto e versão que originou a mensagem. Neste caso, o valor pode ser o igual, mesmo em instâncias diferentes do mesmo aplicativo.
ProductVersion: indica a versão do produto origem;
GeneratedOn: Identifica o timestamp de geração desta mensagem.
DeliveryType: Forma de envio da mensagem, podendo ser sync ou async, ou seja, síncrono ou assíncrono.

Content: contem informações da mensagens de negócio, ou mensagens de resposta. Devido a isso, os atributos podem variar de acordo com a definição da transação.

Quando a mensagem for de resposta, o atributo Content terá ainda os seguintes atributos:

ReceivedMessage:
ProcessingInformation: Contém atributo Details, que por sua vez, contém as mensagens referentes ao processamento da mensagem original. Elas estarão estruturadas conforme definido no Guia de Implementação de APIs TOTVS, item Mensagens de erro, com a ressalva de que os atributos utilizaram a forma capitalizada, em vez do formato "camelCase", ou seja, em vez de "code", é usado "Code", por exemplo.
ReturnContent: Contém o resultado do processamento da mensagem original, conforme definido para a transação. Além disso, pode conter também o atributo ListOfInternalId, onde constam todos os internalIDs relacionados a mensagem. A estrutura correspondente ao internal ID tém os seguintes atributos:
- Name: nome da entidade correspondente ao valor sendo trafegado. Exemplo: "CustomerVendor", "Item", "SalesOrder";
- Origin: mesma definição da tag Origin;
- Destination: mesma definição da tag Destination.

Tipos de Mensagens

O padrão de mensagem TOTVS através do protocolo transactions (EAI) estabelece quatro tipos de mensagens: BusinessMessage, ResponseMessage e ReceiptMessage.

BusinessMessage

Uma mensagem do tipo BusinessMessage são aquelas que iniciam qualquer processo de troca de mensagens entre os aplicativos. Sempre que um aplicativo A quiser enviar ou solicitar informações do aplicativo B, ele enviará uma BusinessMessage que será processada pelo aplicativo destinatário.

As BusinessMessages podem assumir dois tipos:

Event: As mensagens de evento são aquelas cujo objetivo é notificar outros aplicativos da ocorrência de um evento. Estas mensagens são normalmente utilizadas para fins de replicação de dados, quando um dos aplicativos (cadastro master) envia para os demais (slaves) sobre a inclusão, alteração ou eliminação de um registro.
Request: As mensagens de solicitação são utilizadas para consumir um serviço de um aplicativo remoto. Pode ser entendido por serviço qualquer processamento feito pelo aplicativo chamado com base nas informações passadas pelo aplicativo chamador. As mensagens de request são normalmente enviadas por aplicativos-clientes aos aplicativos-servidores para iniciar um processamento (como a consulta do saldo de um item, por exemplo).

A tabela abaixo apresenta um comparativo entre mensagens de evento e de solicitação:

...

Objetivo

...

Replicação de Dados

...

Compartilhar Lógicas

...

Quem Gera (normalmente)

...

Um (cadastro Master)

...

Vários (clientes que precisam da lógica)

...

Quem Responde
(normalmente)

...

Vários (cadastros replicados)

...

Um (detentor da lógica)

...

Uso + comum

...

Síncrono (Envia e aguarda)

...

Assíncrono (envia e esquece)

...

Exemplo

...

Upsert UnitOfMeasure

...

getCashAvailableOnDate

BusinessMessage – Event

As mensagens de eventos de negócio basicamente descrevem o evento ocorrido, como no exemplo abaixo:

Bloco de código

language	js
title	BusinessMessage - Event

{
    "Header": {
        "UUID": "6c7b9b15-6126-972e-aad8-8f64edcf637a",
        "Type": "BusinessMessage",
        "SubType": "event",
		"Event": "upsert"
        "Transaction": "UNITOFMEASURE",
        "StandardVersion": "1.000",
        "SourceApplication": "RM_TS",
        "CompanyId": "1",
        "BranchId": "1",
        "GeneratedOn": "2019-01-18T11:54:40Z",
        "DeliveryType": "Async",
        "Version": "2.002",
        "ProductName": "RM",
        "ProductVersion": "12.1.23.0"
    },
    "Content": {
        "Code": "QS",
        "InternalId": "18|D MG|QS",
        "Description": "QS"
    }
}

Onde:

Event: Qual foi o evento associado à mensagem (pode ser upsert – inclusão/alteração – ou delete – eliminação).
Content: JSON com informações sobre o evento, normalmente contendo todas as informações pertinentes àquela entidade.

BusinessMessage – Request

As mensagens de request descrevem qual função se deseja executar e os parâmetros necessários, como no exemplo abaixo:

Bloco de código

language	js
title	BusinessMessage - Request

{
	"Header": {
		"UUID": "c18535da-75b8-4925-9e32-b6445d4f2927",
		"Type": "BusinessMessage",
		"SubType": "request",
		"Transaction": "AccountsReceivableOffsetting",
		"StandardVersion": "1.000",
		"SourceApplication": "RM",
		"CompanyId": "2",
		"BranchId": "2",
		"GeneratedOn": "2016-06-21T19:41:21",
		"DeliveryType": "Sync",
		"Version": "2.000",
		"ProductName": "RM",
		"ProductVersion": "11.83.55"
	},
	"Content": {
		"CompanyInternalId": "CompanyInternalId1",
		"CompanyId": "CompanyId1",
		"BranchId": "BranchId1",
		"InternalId": "InternalId1",
		"AccountReceivableDocumentInternalId": "AccountReceivableDocumentInternalId1",
		"AdvanceInternalId": "AdvanceInternalId1",
		"OffsettingDate": "1900-01-01T00:00:00",
		"HistoryText": "HistoryText1",
		"OffsettingValue": 1.0
	}
}

Onde:

BusinessContent: JSON com informações necessárias para o processamento, normalmente parâmetros de entrada

...

Uma ResponseMessage representa o resultado do processamento de uma BusinessMessage pelo aplicativo que a recebeu e o seu conteúdo pode variar de acordo com o tipo de mensagem e com o resultado do processamento.

Todas as respostas geradas por uma BusinessMessage devem ser associadas à mensagem original e mantidas pelo aplicativo-origem, como forma de rastrear quem processou aquela mensagem e qual o resultado do processamento.

A mensagem de resposta contém informações sobre o resultado do processamento de uma BusinessMessage.

Exemplo de um JSON de resposta de processamento sem erros

Bloco de código

language	js
title	Mensagem do Tipo Response (EAI)
linenumbers	true

{
    "Header" : {
        "UUID" : "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6",
        "Type" : "Response",
        "SubType" : "event",
        "Transaction" : "CostCenter",
        "Version" : "2.000",
        "SourceApplication" : "LGX12",
        "ProductName" : "LOGIX",
        "ProductVersion" : "12.1.15",
        "GeneratedOn" : "2017-11-14T11:47:15-03:00",
        "DeliveryType": "async"
    },
    "Content" : {
        "ReceivedMessage" : {
            "UUID" : "d6bbfa63-ca27-e2ac-0b14-101970f59a5b",
            "SentBy" : "P1299",
            "Event" : "upsert"       
        },
        "ProcessingInformation" : {
            "ProcessedOn" : "2017-11-14T11:47:15-03:00",
            "Status" : "Ok"           
        },
        "ReturnContent" : {           
            "ListOfInternalID" : [
                {
                    "Name" : "BankInternalId",
                    "Origin" : "01|99|123",
                    "Destination" : "01|99|abc"
                }
            ]
        }
    }
}

Onde:

ReceivedMessage: Segmento com informações sobre a mensagem original (BusinessMessage) que deu origem a esta resposta.
- SentBy: Indica qual foi a instancia que gerou a mensagem original
- UUID: Identificador universal da mensagem de origem
- Event: Qual foi o evento associado à mensagem (pode ser upsert – inclusão/alteração – ou delete – eliminação).
ProcessingInformation: Segmento com informações sobre o resultado do processamento
- ProcessedOn: Timestamp de quando a mensagem foi processada pelo destino
- Status: Situação final do processamento (ok ou error)
- Details: Lista de mensagens (erro ou aviso) retornadas no processamento.
ReturnContent: JSON com as informações de negócio retornadas no processamento

Exemplo de um JSON de resposta de processamento com erros:

Bloco de código

language	xml
title	Response com Erro
linenumbers	true

{
	"Header": {
		"UUID": "25121218-a5c8-e581-b010-0a139a59f4bf",
		"Type": "Response",
		"SubType": "event",
		"Transaction": "Bank",
		"StandardVersion": "1.0",
		"SourceApplication": "Logix",
		"GeneratedOn": "2001-12-31T12:00:00",
		"Version": "1.000",
		"ProductName": "LOGIX",
		"ProductVersion": "12.1.19"
	},
	"Content": {
		"ReceivedMessage": {
			"SentBy": "dts11",
			"UUID": "24121218-a5c8-e581-b010-0a139a59f4bf",
			"Event": "upsert"
		},
		"ProcessingInformation": {
			"ProcessedOn": "2001-12-31T12:00:00",
			"Status": "error",
			"Details": [{
					"Type": "warning",
					"Code": "254",
					"Message": "Messagem de Aviso"
				}, {
					"Type": "error",
					"Code": "-25",
					"Message": "Messagem de erro"
				}, {
					"Type": "error",
					"Code": "EAI30",
					"Message": "Mensagem de Teste3"
				}
			]
		}
	}
}

Obs: Consultar Catalogo de Erros

...

Uma ReceiptMessage representa a confirmação de recebimento de uma BusinessMessage pelo aplicativo destino.

Diferente da ResponseMessage, uma ReceiptMessage não irá conter qualquer informação relevante sobre o processamento da mensagem, uma vez que se entende que, se o aplicativo destino retornou um Receipt, ele não processou a mensagem naquele momento (comunicação assíncrona).

Quando a mensagem for processada pelo aplicativo-destino, uma mensagem de resposta (ResponseMessage) será gerada e encaminhada ao aplicativo que originou a BusinessMessage.

As informações contidas nas mensagens de recibo são genéricas e focam especificamente nos dados de recebimento da mensagem.

Onde:

ReceivedMessage: Segmento com informações sobre a mensagem original (BusinessMessage) que deu origem a esta resposta.
- SentBy: Indica qual foi a instancia que gerou a mensagem original
- UUID: Identificador universal da mensagem de origem
ReceiptData: Segmento com informações sobre o recebimento da mensagem
- - ReceivedOn: Timestamp do recebimento da mensagem.

Quando uma BusinessMessage é recebida é ela for síncrona, ela deverá ser processada e receberá como resposta uma ResponseMessage,

...

Páginas filhas

Versões comparadas

Versão antiga 7

Nova versão Atual

Chave

Objetivo

Identificação única de De/Para de InternalId

Múltiplas referências a uma InternalId na mesma mensagem

Utilização na mensagem

Regra para chave primária

Regra para chave estrangeira

Utilização no Adapter

Estrutura

Funcionamento

Mensagem

Tipos de Mensagens

BusinessMessage

BusinessMessage – Event

BusinessMessage – Request

Páginas filhas

Histórico da Página

Versões comparadas

Versão antiga 7

Nova versão Atual

Chave

Objetivo

Identificação única de De/Para de InternalId

Múltiplas referências a uma InternalId na mesma mensagem

Utilização na mensagem

Regra para chave primária

Regra para chave estrangeira

Utilização no Adapter

Estrutura

Funcionamento

Mensagem

Tipos de Mensagens

BusinessMessage

BusinessMessage – Event

BusinessMessage – Request