Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
|---|
| Índice |
|---|
Informações Gerais
Especificação | |||
Produto | TOTVS | Módulo | EAI |
Segmento Executor | Framework | ||
Projeto1 | DEAI1 | IRM/EPIC1 | |
Requisito/Story/Issue1 | DEAI1-2657 | Subtarefa1 | DEAI1-2648 |
Chamado/Ticket2 | |||
País | ( ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( X ) TODOS. | ||
Outros | <Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>. | ||
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.
| Informações | ||
|---|---|---|
| ||
Este documento leva em consideração que o leitor tenha um conhecimento prévio da mensagem padronizada TOTVS. Caso algum termo não esteja suficientemente descrito aqui, recomenda-se consultar o documento Padrão para criação de mensagem padronizada, disponível no portal de Integrações TOTVS. |
Definições Gerais
Com a padronização das integrações entre os ERP's 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ários, adapter, para cada ERP envolvido, ou seja, o relacionamento entre a mensagem e o adapter é de um para um.
Todas as linhas deverão adequar seus adapters para que não exista mais de um código fonte centralizado relacionado a uma mensagem padronizada.
Desta forma garantiremos que não haverão problemas nos EAIs, como ter mais de um adapter processando uma mesma mensagem para cenários distintosUma 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.
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 . Esta orquestração não é pode ser exposta para quem está consumindo os adapters.Desta 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 processamento da mensagem trafegada entre o emissor e receptor
| Informações | ||
|---|---|---|
| ||
Cenário de envio da mensagem INVOICE no ERP Protheus Atualmente a mensagem é utilizada para tratar duas situações
O , para evitar que ocorra erro de negócio ocorre por existirem dois adapters lidando com uma mesma mensagem. A solução para este cenário no processamento onde a mensagem INVOICE lidando com notas fiscais de compra e venda de mercadoria seja processada pelo adapter INVOICE que está preparado para lidar com notas fiscais de compra de serviços e vice-versa, a proposta é que exista apenas um código fonte relacionado ao adapter INVOICE em todas as linhas, orquestrando a chamada para a rotina A, que lida com notas fiscais de compra e venda de mercadoria a Situação 1 ou a rotina B, que lida com notas fiscais de compra de serviçosa Situação 2, de acordo com o conteúdo de negócio da mensagem, evitando assim um aumento desnecessário na complexidade do EAI. |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
|---|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas