Histórico da Página
01. Apresentação
Este documento tem por objetivo apresentar as responsabilidades dos adapters de recebimento de Mensagens Padronizadas TOTVS.
02. Responsabilidades
Os Adapters de recebimento de mensagens são responsáveis por manipular o conteúdo recebido (BusinessContent), transformando no modelo de parâmetro esperado pelo serviço interno, processando o mesmo e retornando o resultado (ReturnContent) ao EAI para que seja enviado ao aplicativo integrado.
Dentre as diversas necessidades de integração, listamos a seguir dois fluxos comuns de integração que são o de processamento e de consulta de dados.
Fluxo de mensagem de processamento
O diagrama abaixo apresenta um possível fluxo de processamento de uma mensagem síncrona recebida, exemplificando com chamada a um Module, mas também se aplica ao consumo de DataServers, Subscribers ou qualquer outro objeto de negócio. Um exemplo de processo de integração que segue este fluxo é a mensagem CancelRequest, que realiza o cancelamento de movimentos.
draw.io Diagram | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Fluxo de mensagem de consulta
O diagrama abaixo apresenta um possível , de forma similar ao anterior, apresenta o fluxo de processamento de uma mensagem síncrona recebida, exemplificando com chamada a um Module, mas também se aplica ao consumo de DataServers, Subscribers ou qualquer outro objeto de negóciode consulta de dados.
draw.io Diagram border true viewerToolbar true fitWindow false diagramName AdapterReceiveConsulta simpleViewer false width diagramWidth 686 revision
1border | true |
---|---|
viewerToolbar | true |
fitWindow | false |
diagramName | AdapterReceiveConsulta |
simpleViewer | false |
width | |
diagramWidth | 686 |
revision |
2
2 |
Principais funções do adapter de recebimento
- Gerar Transformar o conteúdo dado de negócio da mensagem a enviar recebido (BusinessContent) .
- O adapter é responsável por implementar os padrões apresentados anteriormente, transformando o formato do dado original, enriquecendo ou empobrecendo o mesmo, além de realizar as validações necessárias.
- Após o adapter encaminhar ao EAI o dado de negócio (BusinessContent), todo o fluxo de envelopamento, salvamento na fila de mensagens e envio ao destinatário é de responsabilidade do EAI.
- O adapter é responsável por interpretar os dados recebidos e transformar no modelo esperado pela interface do Server que será consumido.
- Exemplo: Ao receber uma mensagem de Request, o adapter deve transcrever o BusinessContent na classe de parâmetros do Subscriber e realizar a chamada ao Módule.
- Interpretar o processamento e gerar o objeto com as informações Transformar e/ou processar as informações de negócio da resposta (ReturnContent).
- Em integrações para consulta de dados a mensagem de resposta deve ser transformada do formato da Mensagem Padronizada TOTVS para o modelo de retorno, esperado pelo módulo que originou a mensagem.
- Ex.: Mensagens de consulta de informações devem transformar o dado recebido antes de encaminhar para o módulo de consulta.
- É responsabilidade do adapter gerar o ReturnContent que será retornado ao aplicativo integrado.
- Exemplo: A mensagem de consulta de saldos e custos é responsável por buscar as informações no Módule interno ao sistema e converter para o objeto no formato da Mensagem Padronizada TOTVS.
- Exemplo 2: A mensagem de cadastro de produtos possui em seu ReturnContent uma propriedade que trafega a lista de De-Paras, que deve ser preenchida pelo Adapter
- Ex.: Mensagens de cadastro devem ter o De-Para armazenado na base de dados.
- Ex2.: Mensagens assíncronas que devam desbloquear o registro no momento do retorno de sucesso.
- Em integrações para consulta de dados a mensagem de resposta deve ser transformada do formato da Mensagem Padronizada TOTVS para o modelo de retorno, esperado pelo módulo que originou a mensagem.
03. Implementação de um adapter de recebimento
Para que uma classe seja um adapter de recebimento de enviomensagens, deve-se atender aos pré-requisitos listados abaixo e realizar as funções de integração listadas anteriormente.
Pré-requisitos
Implementar a interface IAdapterSend IAdapterReceive, implementando em cada método a sua respectiva responsabilidade, internamente a um projeto cuja Dll gerada siga o padrão "RM.*.TotvsMessage.Adapter.dll".
InitializeAdapter - Método responsável pela inicialização do Adapter, recebendo o contexto de execução por referência.
CanExecute - Método que permite ao adapter realizar verificações e informar se a mensagem deve ser processada, ignorada ou gerar exceção.
Prepare - Método responsável por retornar ao EAI o BusinessContent a ser enviado ao destinatário, juntamente com outras demandas específicas de negócio.
.
ChangeRMContext - Método que deve ser utilizado para compor o RMSContext a partir dos dados recebidos.
ValidateBusinessContentXsd - Método para validação do BusinessContent a partir do XSD da mensagem.
ValidatedSharedMode - Método para validação do nível de compartilhamento da entidade no sistema integrado com relação ao do RM.
ExecuteReceive - Método responsável pelo processamento da mensagem, a partir dos dados fornecidos no BusinessContent.
GetReturnContent - Método responsável por retornar ao EAI o ReturnContent a ser devolvido ao sistema que originou a integraçãoProcessResponseMessage - Método responsável por processar os dados retornados pelo aplicativo integrado, como atualizar algum campo de controle ou transformar o dado em caso de consultas, como esta mensagem.
Decorar a classe do adapter com o atributo "AdapterAttr".
O atributo deve receber as informações obrigatórias, como nome da mensagem, versão, descrição e tipo (event/request).
Implementar as classes de modelo referentes ao BusinessContent e ao ReturnContent da Mensagem Padronizada TOTVS, que serão utilizadas na serialização e deserialização das mensagens.
- As classes de modelo devem ser decoradas com o atributo "MessageContentTypeAttr" informando os atributos, descritos abaixo.
- TransactionName - Nome da transação referente a este modelo.
- MajorVersion - Versão cheia da mensagem.
- Exemplo: Versão 1.003 possui MajorVersion 1.
- Exemplo 2: Versão 3.023 possui MajorVersion 3.
- MessageType - Tipo da transação a ter seu conteúdo de negócio serializado/deserializado utilizando esta classe (BusinessMessage ou ResponseMessage).
Código Fonte
Deck of Cards | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Implementações de produto
Os times dos segmentos tiveram iniciativa de desenvolver classes base e auxiliares para executar ações comuns e assim aumentar a produtividade no desenvolvimento de adapters. Estas classes estão disponíveis no projeto "RM.EAI.TotvsMessage.Adapter", que mesmo estando na solution do EAI é de domínio e manutenção dos times de produto.
A forma de uso destas classes foi documentada pelo produto no link a seguir: Desenvolvimento - AdapterEAI 2.
04. Assuntos Relacionados
- Entidades Relacionadas ao EAI 2.0
- 1. Entidades relacionadasdo EAI
- Documento técnico da criação do Conversor para EAI 2.0
- Desenvolvimento de Adapters com as classes base dos segmentos.
- Desenvolvimento - AdapterEAI 2