Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Documentar a relação entre um Adapter e sua Mensagem no padrão TOTVS de Mensagem Única.

Definições Gerais

Com a padronização das integrações entre os ERP's ERPs da TOTVS, foi definida uma mensagem única que estabelece algumas diretrizes que devem ser seguidas por todas as linhas que operem integrações dentro do ecossistema TOTVS.

Termos e Nomenclaturas

Os termos "DEVE", "NÃO DEVE", "REQUERIDO", "PODE", "NÃO PODE", "DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "NÃO RECOMENDADO" e "OPCIONAL" devem ser interpretados como descritos na BCP-14, RFC-2119 e RFC-8174.

Definições da Regra de Negócio

Em termos gerais, ficou definido que cada mensagem única deva ter um único ponto de entrada, e não váriosadapter, para cada ERP envolvido, ou seja, o relacionamento entre a mensagem e o adapter é de um para um.

Uma das principais razões pela escolha desta forma de operação é que, além de sua manutenção ser centralizada em um código fonte de adapter por mensagem, este código fonte centralizado pode orquestrar outras funcionalidade internas necessárias para o correto funcionamento do ERP sem quebrar as premissas da mensagem única.

Funcionamento

A dinâmica envolvida no processamento de mensagens (envio e recebimento) pode ser entendida como similar ao funcionamento de um serviço, onde cada endpoint com seu nome único é um ponto de entrada da mensagem padronizada e o adapter é o seu serviço.

Todas as linhas irão adequar seus adapters para que não exista mais de um código fonte centralizado relacionado a uma mensagem padronizada.

Todas as linhas deverão adequar seus adapters para que não exista mais de um código fonte relacionado a uma mesma mensagem padronizada.

Desta forma garantiremos que não haverão conflitos nos EAIs, como ter mais de um adapter processando uma mesma mensagem padronizada para cenários distintos.

Funcionamento

Por sua definição, cada mensagem padronizada é considerada como um serviço, similar a uma API REST, e assim sendo, deve possuir apenas um ponto de entrada. Seguindo esta analogia, o adapter é o equivalente ao código da API, que deve ser único.

Os adapters deverão Todos os adapters poderão estar preparados para orquestrar chamadas internas com base nos dados do corpo no conteúdo de negócio da mensagem e de acordo com a necessidade de cada linha e esta orquestração não é exposta para quem está consumindo os adapters.as suas regras.

O EAI é um sistema de roteamento de mensagens entre os ERPs da TOTVS, não compete a este sistema, analisar o conteúdo de negócio de cada mensagem afim de roteá-la. O adapter equivalente será identificado com base no conteúdo do cabeçalho da mensagem. A orquestração da chamada de rotinas compete ao segmento que as implementará internamente no adapterDesta forma garantiremos que cada mensagem terá apenas um ponto de entrada, evitando confusões como ter mais de um adapter processando uma mesma mensagem para cenários distintos e para que não seja necessário tornar o cenário de integração ainda mais complexo fazendo com que o EAI identifique qual o adapter que gerou a mensagem, para saber dizer qual o adapter que deveria processá-la.

Estrutura

A estrutura básica de uma integração se dá com as seguintes entidades.

• Emissor/Receptor: Correspondem aos ERPs dos quais se origina (emissor) e para os quais se destina (receptor)
• Mensagem: Corresponde ao conteúdo que trafega entre o emissor e receptor
• Adapter: Corresponde ao serviço que realizará O responsável por realizar a transformação da mensagem e orquestrar a chamada dos serviços que realizarão o processamento da mensagem trafegada entre o emissor e receptor