...

O objetivo deste guia é habilitar e configurar o console EAI para a utilização nas integrações com TOTVS Vitae e TOTVS Educacional.

Visão Geral

A TOTVS estabeleceu um conjunto de técnicas e padrões para a integração dos seus produtos que ficou conhecido como “Mensagem Única TOTVS”. Este conjunto de definições estabelece como os produtos TOTVS devem se comunicar e engloba questões como:

• Como definir uma mensagem de integração
• Como as mensagens são identificadas
• Como é feita a troca de mensagens
• Como as mensagens são rastreadas

...

O componente EAI 2.0 (Java), fornecido pela equipe de Framework do Produto Datasul encapsula estas definições e permite que os produtos possam se integrar no novo modelo com um esforço menor para a sua incorporação. Ele define um conjunto de interfaces que devem ser implementadas pelo produto hospedeiro (host application) que tratam, basicamente, da persistência das informações que circulam pelo EAI em banco de dados. Além disso, o EAI também espera que o aplicativo hospedeiro disponibilize um web service que será a porta de entrada para as mensagens enviadas pelos outros aplicativos.

Em contrapartida, o EAI 2.0 fornece toda a lógica de identificação, processamento e rastreabilidade de mensagens além de uma interface web para o gerenciamento da instância.

Definição de Mensagem Única TotvsMessage

Durante o processo de consolidação de marcas, iniciado pela TOTVS, várias empresas diferentes foram adquiridas e com elas vários produtos passaram a compor o portfólio de ofertas disponível aos clientes. Esta expansão de ofertas permitiu que clientes de uma marca, antes limitados pelas opções com aquela “etiqueta”, pudesse agora compor o seu ambiente de TI utilizando produtos de origens diferentes (Ex.: TOTVS Educacional + fluig).

Esta mesma iniciativa já era uma prática comum nos clientes, porém todo o custo envolvido na integração entre estes aplicativos era visto pelo cliente como parte da escolha de utilizar-se de produtos de diferentes fornecedores. Uma vez que estes produtos passam a fazer parte de uma mesma oferta, os clientes TOTVS passam a demandar que estes produtos sejam naturalmente integrados. Isto significa que se antes o cliente arcava com o custo e o risco envolvido em uma integração, ele agora entende que a TOTVS deve prover soluções já integradas, independente da origem dos produtos oferecidos.

Com o objetivo de padronizar a integrações com os produtos TOTVS, foi definida uma nova diretriz para os projetos de integração: A de que todos os produtos TOTVS devam trabalhar com uma mensagem XML únicos evitando, desta forma, o processo de transformação de mensagens. Neste cenário, teríamos o seguinte quadro:

Image Added

Neste cenário, qualquer produto TOTVS trabalhará com o mesmo XML para uma mesma entidade, ou seja, supondo que tenhamos um XML correspondente à mensagem de CLIENTES, ela poderá ser enviada para qualquer um dos produtos que suporte o recebimento desta entidade.

Uma vez que os vários produtos TOTVS terão um “idioma” comum (o XML Único), as integrações entre estes produtos não exigirão mais que as mensagens sejam transformadas de um formato para outro. Com isto, será possível conectar diretamente dois produtos, como no diagrama abaixo:

Image Added

Além de questões referentes ao formato das mensagens, a mensagem única também torna uniforme o tratamento destas mensagens XML pelos aplicativos, principalmente no que diz respeito à capacidade de rastreamento.

Todos os processos devem respeitar o fluxo normal de troca de mensagens no padrão de Mensagem Única TOTVS. O fluxo de mensagens poderá ocorrer nos seguintes sentidos:

• Educacional à fluig: Os dados serão trafegados pelo fluxo normal até a fila de Integração TBC, onde o mesmo irá consumir o WebService do EAI do fluig para envio da(s) mensagem(s). Após a resposta do fluig o RM atualizará o registro, com o status de processamento e demais dados, no Monitor da Fila de Mensagem Única.

• fluig à Educacional: O fluig irá consumir o WebService da linha RM para recebimento de mensagens únicas. O mesmo também será responsável por encaminhar as mensagens para o EAI RM, que processará a mesma (englobando todas as especificidades requeridas) e encaminhará o retorno de acordo com o tipo de comunicação definida (síncrona ou assíncrona).

Para mais informações sobre o fluxo dos dados internamente ao TBC vide documentação do EAI RM.

Assim como definido no protocolo de comunicação de mensagens únicas, a comunicação pode ser efetuada de duas formas:

• Síncrona: O sistema de origem gera uma mensagem de integração na sua fila e envia ao WebService de destino. O processo na origem aguarda o processamento da mensagem no destino e ao receber o retorno atualiza o status do processamento na fila de integração. (Mensagens síncronas não podem ser processadas/reprocessadas no monitor da fila de integração.)

• Assíncrona: O sistema de origem gera uma mensagem de integração na sua fila, envia ao WebService de destino e aguarda somente a confirmação de recebimento da mensagem. O processo na origem não fica parado aguardando o processamento da mensagem no destino.
  
  

Ao término do processamento da mensagem por parte do sistema de destino o mesmo envia outra mensagem de retorno ao sistema de origem com o status do processamento.

As mensagens assíncronas podem ser processadas (status pendente) ou reprocessadas (status erro) manualmente através do monitor da fila de integração.

Nota: Cada linha irá programar a fila de integração a sua maneira, respeitando o protocolo definido para mensagem padrão e guardando o log de processamento de todas as mensagens recebidas ou enviadas.

EAI vs Arquitetura Multi-

...

Empresa

Um ponto relevante para a incorporação do EAI 2.0 no fluig é a sua característica de Multi-TenantEmpresa. Esta arquitetura permite que várias tenants empresas utilizem a mesma instalação do produto de forma independente e transparente, gerando a percepção de que cada um possui uma instância própria do produto.

...