Páginas filhas
  • 3.1 Adapters de Envio

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Tempo aproximado para leitura: 00 min

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 desenvolvimento.

02. Responsabilidades

O adapter 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
  1. Realizar a transformação dos dados no formato original para o formato da Mensagem Padronizada.
    1. O adapter é responsável por implementar os padrões apresentados anteriormente, transformando o formato do dado, enriquecendo ou empobrecendo o mesmo, além de realizar as validações necessárias.
    2. 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.
  2. Transformar e/ou processar as informações de resposta.
    1. 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.
      1. Ex.: Mensagens de consulta de informações devem transformar o dado recebido antes de encaminhar para o módulo de consulta.
    2. Caso a mensagem trafegada demande algum processamento de responsabilidade da camada de integração, este deve ser implementado no método correspondente do adapter.
      1. Ex.: Mensagens de cadastro devem ter o De-Para armazenado na base de dados.
      2. Ex2.: Mensagens assíncronas que devam desbloquear o registro no momento do retorno de sucesso.

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:

    1. Todos os pacotes de integração utilizados pelo cliente devem estar disponíveis no EAI 2.0
    2. 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
    3. Verificar se o cliente possui customizações em suas Transformações XSLT ou nos SourceCodes
      1. 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.

 

06. Assuntos Relacionados