A comunicação através do protocolo transaction (EAI) possui uma estrutura composta dos seguintes elementos:
O canal em que essa comunicação acontece pode ser algum dos seguintes:
Graficamente, a estrutura pode ser descrita conforme abaixo:
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.
<INSERIR AQUI MAIS INFORMAÇÕES SOBRE INTERNALID>
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.
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:
O padrão de mensagem TOTVS através do protocolo transactions (EAI) estabelece quatro tipos de mensagens: BusinessMessage, ResponseMessage e ReceiptMessage.
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:
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 | 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 |
As mensagens de eventos de negócio basicamente descrevem o evento ocorrido, como no exemplo abaixo:
Bloco de código | ||||
---|---|---|---|---|
| ||||
{
"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:
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 | ||||
---|---|---|---|---|
| ||||
{
"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:
Âncora | ||||
---|---|---|---|---|
|
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 | ||||||
---|---|---|---|---|---|---|
| ||||||
{
"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:
Exemplo de um JSON de resposta de processamento com erros:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
{
"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
Âncora | ||||
---|---|---|---|---|
|
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:
Quando uma BusinessMessage é recebida é ela for síncrona, ela deverá ser processada e receberá como resposta uma ResponseMessage,
Quando uma BusinessMessage é recebida é ela for assíncrona, ela receberá como resposta, no momento da recepção uma ReceiptMessage, e posteriormente quando for processada será enviada uma ResponseMessage para esta mensagem