Histórico da Página
01. Apresentação
Este documento tem por objetivo apresentar as responsabilidades dos adapters de envio , juntamente com os requisitos de software e boas práticas necessárias para o correto desenvolvimentode Mensagens Padronizadas TOTVS.
02. Responsabilidades
O adapter Os Adapters de envio de mensagens é responsável por executar, dentre outras funções acessórias, as funções e os padrões listados abaixo.
Padrões de integração (EAI Patterns)
Os padrões de desenvolvimento de integração listados abaixo são os principais para este contexto. É aconselhável o estudo dos demais padrões, sendo melhor descritos no site Enterprise Integration Patterns, SOA Patterns e outras referências bibliográficas.
- Message Translator
- Transformação de modelos de dados, mesmo que sem alteração de conteúdo.
- Ex.: Converter os campos do DataSet para os nomes da Mensagem Padronizada, como a tag "NomeFantasia" para "Name", mantendo o valor original.
- Content Enricher
- Enriquecimento dos dados originais.
- Ex.: A mensagem padronizada trafega somente o InternalId da ForeignKey, sendo necessário obter a coligada e código referentes a este registro.
- Ex 2.: Caso no dado original não tenham relacionamentos necessários, como o responsável financeiro de um aluno, o adapter deve ser responsável enriquecer o dado com esta informação.
- Content Filter
- Padrão que descreve a situação contrária ao Content Enricher, sendo responsável por reduzir a quantidade de informações.
- Ex.: O DataSet original de Movimentos possui inúmeras tabelas e colunas, mas para a mensagem de deleção de Pedidos de Compra somente a chave do registro deve ser trafegado.
Funções principais
- As funções listadas abaixo são executadas utilizando os padrões de desenvolvimento necessários.
De forma superficial podemos analisar os adapters de envio como responsáveis, dentre outras tarefas acessórias, pela transformação do dado original e o pela transformação.
Os adapters de envio são responsáveis por fazer a transformação do dado original para o formato de Mensagem Padronizada TOTVS definido.
02.01. Análise de compatibilidade
A análise de compatibilidade do cliente com o EAI 2.0 deve ser realizada pelo consultor de implantação ou analista de suporte, que deve considerar as características:
- Todos os pacotes de integração utilizados pelo cliente devem estar disponíveis no EAI 2.0
- Caso haja planejamento de implantação de novos pacotes de integração, deve-se garantir que estes estejam disponíveis no EAI 2.0 até o prazo da implantação pois a conversão da base de dados é irreversível
- Verificar se o cliente possui customizações em suas Transformações XSLT ou nos SourceCodes
- Todas as customizações de integração do EAI 1.0 deverão ser re-codificadas pois o modelo de customização do EAI 2.0 não é retro-compatível.
02.02. Script de liberação
Caso após a análise acima seja constatado que o cliente é compatível com o EAI 2.0, deve-se solicitar ao suporte o script de liberação de acesso ao conversor. Sem a execução deste script o menu de acesso não é invisível ao cliente.
02.03. Caminho do menu
O processo de conversão está disponível no contexto de integrações, na árvore de menus de Mensagem Única.
são responsáveis por preparar os dados a serem enviados, gerando uma BusinessMessage no padrão definido para esta, e processar a ResponseMessage retornada pelo sistema integrado, utilizando para isso os corretos padrões de desenvolvimento.
O diagrama abaixo apresenta de forma macro a série de eventos que ocorrem durante o processamento de uma mensagem de envio, exemplificando com a origem em DataServer mas esta pode ocorrer nos Subscribers, Process ou qualquer outro objeto de negócio.
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Principais funções do adapter de envio
- Gerar o conteúdo de negócio da mensagem a enviar (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.
- 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.
- Caso a mensagem trafegada demande algum processamento de responsabilidade da camada de integração, este deve ser implementado no método correspondente do 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 envio
Para que uma classe seja um adapter de envio, deve-se atender aos pré-requisitos listados abaixo e realizar as funções de integração listadas anteriormente.
Pré-requisitos
Implementar a interface IAdapterSend, 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.
ProcessResponseMessage - 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 - EAI 2.
04
06. 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.