Este documento tem por objetivo apresentar as principais entidades do EAI 2.0 da linha RM, juntamente com as tabelas em que são armazenadas, e fazer o paralelo com as entidades equivalentes no EAI 1.0.
01.01. Diagrama
O cadastro de aplicativos é o coração de uma integração, sendo responsável por representar os sistemas integrados e armazenar as informações de conectividade com o mesmo.
Um aplicativo de destino se refere a uma instância de um sistema integrado, como por exemplo um ambiente com o Protheus instalado e de SourceApplication "P12Manutencao".
A partir deste cadastro são feitos todos os relacionamentos que descreverão a integração com os dois sistemas (RM e aplicativo externo), como por exemplo a definição das rotas de integração.
O cadastro de integrações no EAI 1.0 é migrado para os cadastros de Aplicativos e de Pacotes Instalados durante a conversão. Cada integração no EAI 1.0 é considerado como um pacote de integração, podendo assim ter mais de um pacote para o mesmo aplicativo de destino.
A imagem abaixo representa a forma como as Integrações do EAI 1.0 são migradas para as duas entidades do EAI 2.0. Em resumo, as integrações são agrupadas considerando cada par "Sistema Integrado" e "SourceApplication" como um aplicativo, e cada integração passam a ser consideradas como Pacotes Instalados.
O cadastros de Transações e Versões apresentam quais Mensagens Únicas TOTVS possuem Adapters disponíveis na linha RM para a versão instalada e a configuração destas transações, como os parâmetros se o tipo de entrega será sincrono/assíncrono e se grava log na fila.
Este cadastro é atualizado automaticamente, mas pode ser solicitada o reprocessamento através do processo "Atualizar Transações do Ambiente" que está disponível na visão de Transações.
A implementação de adapters no EAI 1.0 e no 2.0 são distintas, sendo que no primeiro os fontes do adapter são armazenados em tabelas do banco de dados e no segundo são internos às DLLs do RM.Assim sendo, no EAI 2.0 as tabelas de Transação e Versão armazenam somente a lista de adapters diponíveis, facilitando visualização e configuração.
O cadastro de rotas é responsável por definir quais as transações trafegadas com cada aplicativo integrado, informando também a versão da mensagem e outras informações.
As rotas são equivalentes ao cadastro de "Mapa de Integração" do EAI 1.0, com a adição de funcionalidades solicitadas como a parametrização do sentido da mensagem (envio/recebimento), se inclui a mensagem original na resposta e outras.
O EAI permite o armazenamento das mensagens trafegadas em sua fila de mensagens, sendo este comportamento obrigatório no tráfego assíncrono. Estas tabelas são expostas pelas APIs de monitoramento e podem ser visualizadas a partir do Monitor de Integrações.
Tabela responsável por armazenar as mensagens originais.
No recebimento o conteúdo desta tabela será a TotvsMessage recebida e no envio esta tabela armazenará o dado original enviado pela trigger.
Tabela de armazenamento dos IDs dos Jobs agendados para processamento de mensagens assíncronas. A partir destes IDs é possível verificar os dados do Job, como data e hora agendamento, status do processamento e outros.
Tabela responsável por armazenar as informações da mensagem pra cada rota parametrizada.
Exemplificando o uso desta tabela, caso existam duas rotas para uma transação recebida existirão assim duas "Rota/Mensagem" para uma única Mensagem.
Esta tabela armazena as informações de execução da "Rota/Mensagem", como o status, mensagem transformada, mensagem de execução, contexto de negócio e outros.
Tabela responsável por armazenar os logs de execução.
A rotina de configuração está disponível na arvore de menus do EAI 2.0.
05. ASSUNTOS RELACIONADOS