Frameworksp

Atalhos

Páginas filhas
  • ER_DEAI1_Relacao_Mensagem_Adapter

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.                                                             



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.


Para sua informação

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 Entendendo a Mensagem Padronizada.


Definições Gerais

Com a padronização das integrações entre os 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 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 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 estar preparados para orquestrar chamadas internas com base no conteúdo de negócio da mensagem e de acordo com 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 adapter.

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: O responsável por realizar a transformação da mensagem e orquestrar a chamada dos serviços que realizarão o processamento da mensagem


Exemplo

Cenário de processamento de notas fiscais (mensagem INVOICE)

Atualmente a mensagem é utilizada para tratar duas situações

  • Situação 1: Notas fiscais de compra e venda de mercadoria.
  • Situação 2: Notas fiscais de compra de serviços.

O erro de negócio ocorre por existirem dois adapters lidando com uma mesma mensagem.

A solução para este cenário é que exista apenas um código fonte relacionado ao adapter INVOICE em cada sistema, orquestrando a chamada para a rotina A, que lida com a Situação 1 ou a rotina B, que lida com a Situação 2, de acordo com o conteúdo de negócio da mensagem.

Exemplo

Cenário de renegociação de financiamento

Foi criado um contrato de financiamento de 12 parcelas, onde 6 já foram pagas e o cliente deseja renegociar o contrato para quitar o restante em 8 parcelas.

Para que esta renegociação seja efetuada, 3 passos devem ser executados, sendo eles:

  • Baixa das 6 parcelas quitadas;
  • Cancelamento das 6 parcelas futuras;
  • Criação do contrato de 8 parcelas de acordo com o saldo restante.

A solução para este cenário é que exista apenas um código fonte relacionado ao adapter de renegociação de contrato em cada sistema, orquestrando a chamada para as rotinas de baixa, cancelamento e criação de contrato para realização da renegociação do contrato.







 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.