Objetivo


Com o objetivo de evitar problemas com padrão de mensagem para trocas entre sistemas, foi definida uma nova diretriz para os projetos de integração: A de que todos os produtos TOTVS devam trabalhar com uma mensagem XML única evitando, desta forma, o processo de transformação de mensagens. Neste cenário, teríamos o seguinte quadro:

Neste cenário, qualquer produto TOTVS trabalhará com o mesmo XML para uma mesma entidade, ou seja, supondo que tenhamos um XML correspondente à mensagem de item, ela poderá ser enviada para qualquer um dos produtos que suporte o recebimento desta entidade.

Uma vez que os vários produtos TOTVS terão um “idioma” comum (o XML único), as integrações entre estes produtos não exigirão mais que as mensagens sejam transformadas de um formato para outro. Com isto, será possível conectar diretamente dois produtos, sem a necessidade do TOTVS ESB, como no diagrama abaixo:

Além de questões referentes ao formato das mensagens, a mensagem única também torna uniforme o tratamento destas mensagens XML pelos aplicativos, principalmente no que diz respeito à capacidade de rastreamento.

Anatomia da Mensagem TOTVS


A Mensagem Única TOTVS estabelece alguns padrões que devem ser seguidos por todos os aplicativos que participem da integração. Estes padrões estabelecem alguns tipos de mensagens suportadas bem como informações obrigatórias que devem fazer parte do seu conteúdo.

A composição do conteúdo de cada uma das mensagens de negócio será definida em conjunto com especialistas de negócio e não faz parte do escopo deste documento.

Tipos de Mensagens


O padrão de mensagem TOTVS estabelece quatro tipos de mensagens: BusinessMessage, ResponseMessage, ReceiptMessage e MalformedMessage.

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 BusinessMessage podem assumir dois tipos:

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


EventRequest
ObjetivoReplicação de dadosCompartilhar lógicas
Quem geraUm (cadastro master)Vários (clientes que precisam da lógica)
Quem respondeVários (cadastros replicados)Um (detentor da lógica)
Uso comumAssíncrono (envia e esquece)Síncrono (envia e aguarda)
ExemploUpsert UnitOfMeasuregetCashAvailableOnDate

ResponseMessage


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.

Atributos da classe:

AtributoTipoDescrição
CustomInformationCustomInformationRetorna ou atribui informações customizadas
NUM-MESSAGESINTEGERRetorna número de mensagens de erro ou não na mensagem
ProcessedOnDATETIME-TZRetorna ou atribui data de processamento
ReceivedMessageInfoReceivedMessageInfoRetorna ou atribui informações da mensagem original (BusinessMessage)
ReturnContentLONGCHARRetorna ou atribui mensagem original (BusinessMessage)
STATUSCHARACTERRetorna se a resposta contém erros ou não: “OK” ou “ERROR”.
TYPECHARACTERRetorna o tipo do objeto: “Response”


Métodos da classe:

MétodoRetornoDescrição
addMessagevoidAdiciona mensagem na mensagem. Caso uma mensagem do tipo ERROR, o atributo STATUS é alterado para OK.
createResponseResponseMessageCria uma mensagem de resposta a partir de uma BusinessMessage.
GET-MESSAGE-CODECHARACTERRetorna o código de uma determinada mensagem. Usada em conjunto com o atributo NUM-MESSAGES.
GET-MESSAGE-DESCCHARACTERRetorna a descrição de uma determinada mensagem. Usada em conjunto com o atributo NUM-MESSAGES.
GET-MESSAGE-TYPECHARACTERRetorna o tipo de uma determinada mensagem. Usada em conjunto com o atributo NUM-MESSAGES.
prepare-messagevoidAltera o horário de processamento da mensagem com o horário corrente, antes de devolver ao sistema externo.

ReceiptMessage


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 entende-se que, se o aplicativo destino retornou um ReceiptMessage, 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.

MalformedMessage


A MalformedMessage não é propriamente uma mensagem de integração mas um registro de uma mensagem desconhecida, ou seja, que não esteja no padrão TOTVSMessage.

Composição das Mensagens


As mensagens TOTVS compartilham um conjunto de informações básicas que são utilizadas para identificar o seu tipo, versão e origem.

Informações comuns


As mensagens TOTVS possuem um segmento chamado MessageInformation que possui as principais informações utilizadas para identificação e roteamento da mensagem. O quadro abaixo apresenta um exemplo deste segmento:


Onde:

BusinessMessage – Event


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


Onde:

BusinessMessage – Request


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


Onde:

ResponseMessage


As mensagens de resposta contém informações sobre o resultado do processamento de uma BusinessMessage, como no exemplo abaixo:


Onde:

ReceiptMessage


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


Onde: