Histórico

Durante o processo de consolidação de marcas, iniciado pela TOTVS, várias empresas diferentes foram adquiridas e com elas vários produtos passaram a compor o portfólio de ofertas disponível aos clientes. Esta expansão de ofertas permitiu que clientes de uma marca, antes limitados pelas opções com aquela “etiqueta”, pudesse agora compor o seu ambiente de TI utilizando produtos de origens diferentes (Ex.: BackOffice Protheus + TOTVS Obras e Projetos).

Com o objetivo de padronizar a integrações com os produtos TOTVS, foi definida uma nova diretriz para os projetos de integração: todos os produtos TOTVS devem se comunicar 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 CLIENTES, 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, também será uniforme o tratamento destas mensagens XML pelos aplicativos, principalmente no que diz respeito à capacidade de rastreamento. 

Anatomia da Mensagem TOTVS

A Mensagem Padronizada TOTVS estabelece alguns padrões que devem ser seguidos por todos os aplicativos que participam 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.

Anatomia básica de uma mensagem de negócio:

O totvsmsg.xsd define o layout completo da mensagem padronizada, com cabeçalho e elementos com informações de origem e destino, status de processamento, erros e histórico.

Isto permite que dentro de uma mensagem específica seja definido apenas o conteúdo de negócio e retorno, mas quando a mensagem completa for trafegar entre os produtos, todas as informações citadas acima também façam parte da estrutura da mensagem.

Veja abaixo um exemplo do XML de uma mensagem padronizada (XML) completa:

Exemplo de um XML de resposta de processamento sem erros:

<?xml version="1.0" encoding="UTF-8" ?>
<TOTVSMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="xmlschema/general/events/Bank_1_000.xsd">
	<MessageInformation version="1.000">
		<UUID>25121218-a5c8-e581-b010-0a139a59f4bf</UUID>
		<Type>Response</Type>
		<Transaction>Bank</Transaction>
		<StandardVersion>1.0</StandardVersion>
		<SourceApplication>Logix</SourceApplication>
		<Product name="LOGIX" version="12.1.19"/>
		<GeneratedOn>2001-12-31T12:00:00</GeneratedOn>
	</MessageInformation>
	<ResponseMessage>
		<ReceivedMessage>
			<SentBy>dts11</SentBy>
			<UUID>24121218-a5c8-e581-b010-0a139a59f4bf</UUID>
			<Event>upsert</Event>
			<MessageContent>
				<![CDATA[
					...mensagem original
				]]>
			</MessageContent>
		</ReceivedMessage>
		<ProcessingInformation>
			<ProcessedOn>2001-12-31T12:00:00</ProcessedOn>			
			<Status>OK</Status>
		</ProcessingInformation>
		<ReturnContent>
			<ListOfInternalId>
				<InternalId>
					<Name>BankInternalId</Name>
					<Origin>01|99|123</Origin>
					<Destination>01|99|abc</Destination>
				</InternalId>
			</ListOfInternalId>
		</ReturnContent>
	</ResponseMessage>
</TOTVSMessage>

Exemplo de um XML de resposta de processamento com erros:

<?xml version="1.0" encoding="UTF-8" ?>
<TOTVSMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="xmlschema/general/events/Bank_1_000.xsd">
	<MessageInformation version="1.000">
		<UUID>25121218-a5c8-e581-b010-0a139a59f4bf</UUID>
		<Type>Response</Type>
		<Transaction>Bank</Transaction>
		<StandardVersion>1.0</StandardVersion>
		<SourceApplication>Logix</SourceApplication>
		<Product name="LOGIX" version="12.1.19"/>
		<GeneratedOn>2001-12-31T12:00:00</GeneratedOn>
	</MessageInformation>
	<ResponseMessage>
		<ReceivedMessage>
			<SentBy>dts11</SentBy>
			<UUID>24121218-a5c8-e581-b010-0a139a59f4bf</UUID>
			<Event>upsert</Event>			
		</ReceivedMessage>
		<ProcessingInformation>
			<ProcessedOn>2001-12-31T12:00:00</ProcessedOn>			
			<Status>error</Status>
			<ListOfMessages>
				<Message type="warning" code="254">Messagem de Aviso</Message>
				<Message type="error"   code="-25">Messagem de erro</Message>
				<Message type="error"   code="EAI30">Mensagem de Teste3</Message>
			</ListOfMessages>
		</ProcessingInformation>		
	</ResponseMessage>
</TOTVSMessage>

Exemplo de um XML de recibo, devolvido pelo EAI quando a mensagem enviada for assíncrona:

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. Exemplo: 

Onde:

• MessageInformation 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.
• 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).
• 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.
• StandardVersion: Identifica a versão do padrão TOTVS, ou seja, do formato utilizado nas áreas genéricas da mensagem TOTVS. Caso o padrão TOTVS seja alterado, este valor será alterado. 
• 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. 
• CompanyId/BranchId/UserId: Identificador da empresa/filial e usuário que gerou a mensagem. Esta informação é apenas documental e não deve ser utilizada para o processamento da mensagem já que não existe garantia da sua existência na mensagem. Quando a informação for relevante para o negócio, é preciso buscar esta informação do conteúdo da mensagem de negócio.
• Product: 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.  
• 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.

Tipos de Mensagens

O padrão de mensagem TOTVS 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:

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

Onde:

• Entity: Identifica qual foi a entidade de negócio que sofreu o evento
• Event: Qual foi o evento associado à mensagem (pode ser upsert – inclusão/alteração – ou delete – eliminação).
• Identification/Keys: Campos-chave para identificação do registro impactado pela alteração
• BusinessContent: XML 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:

Onde:

• Operation: Identifica qual a operação que se deseja executar
• BusinessContent: XML com informações necessárias para o processamento, normalmente parâmetros de entrada

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.

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

<ResponseMessage>
	<ReceivedMessage>
		<SentBy>PROTHEUS</SentBy>
		<UUID>25121218-a5c8-e581-b010-0a139a59f4bf</UUID>
		<Event>upsert</Event>
		<MessageContent>
			<![CDATA[
			... mensagem original...
			]]>
		</MessageContent>
	</ReceivedMessage>
	<ProcessingInformation>
		<ProcessedOn>2011-06-23T17:04:16</ProcessedOn>
		<Status>error</Status>
		<ListOfMessages>
			<Message type="warning" code="254">Mensagem de aviso</Message>
			<Message type="error"   code="-25">Mensagem de erro</Message>
			<Message type="error"   code="EAI30">Mensagem de Teste3</Message>
		</ListOfMessages>
	</ProcessingInformation>
	<ReturnContent>
		...
	</ReturnContent>
</ResponseMessage>

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).
  • MessageContent: XML da mensagem original (opcional).
• 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)
  • ListOfMessages: Lista de mensagens (erro ou aviso) retornadas no processamento.
• ReturnContent: XML com as informações de negócio retornadas no processamento

Obs: Consultar Catalogo de Erros 

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 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
  • MessageContent: XML da mensagem original (opcional).
• 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,

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

Para verificar os formatos de envio e respostas nos modos síncronos e assíncronos para json consulte o arquivo anexo eai_formatos_json.zip.