Linha Logix

Páginas filhas
  • LGX - EAI2
3 mais filhas

EAI2 LOGIX



Objetivo

O EAI tem como objetivo: 

  • Gerenciar a troca de mensagens entre ERPs, como: registrar mensagens enviadas e recebidas, rastrear a execução da mensagem dentro do ERP e gerenciar filas de execução de mensagens.
  • Configurar a troca de mensagens, como: habilitar determinadas transações, configurar os vários canais de comunicação e configurar os destinos dos outros ERPs.

Os dados são trafegados em formato XML (para atender multi-plataformas).

O que é o EAI

EAI (do inglês Enterprise Application Integration) é uma referência aos meios computacionais e aos princípios de arquitetura de sistemas utilizados no processo de Integração de Aplicações Corporativas. Os procedimentos e ferramentas de EAI viabilizam a interação entre sistemas corporativos heterogêneos por meio da utilização de serviços.


Acesse abaixo o conteúdo completo das documentações do EAI2

1. Instalação e configuração do EAI Logix

2. Exportação e Importação de Configurações do EAI

3. Desenvolvimento de Adapters EAI Logix

4. Para Desenvolvedores

5. Para Atendimento e Implantação

6. Padrão para criação de Mensagem Única



COCEITOS EAI2


Aplicativo


Aplicativo é todo o produto instalado em uma determinada máquina que possua os programas de EAI e que consiga realizar a comunicação com qualquer outro Aplicativo. Na denominação, usa-se Aplicativo Interno para o próprio produto e Aplicativo Externo para os quais ele deseja se comunicar.


TOTVSMessage


Mensagem única TOTVS é o modelo de dados em que todos os produtos da TOTVS devem trabalhar durante troca de informações. Seu objetivo é evitar o processo de transformação de mensagens, fazendo assim com que a mensagem, após definida, torne-se padrão independente de produtos.

Uma vez que os produtos TOTVS terão um “idioma” comum para troca de informações, será possível conectar diretamente com vários produtos ao mesmo tempo, trocando informações, sem a necessidade do TOTVS ESB.

Com o modelo de mensagem apresentado, também se torna uniforme seu tratamento pelos produtos, principalmente no que diz respeito à capacidade de rastreamento, pois em seu conteúdo é possível identificar a origem e o tipo.

Além disso, a mensagem única estabelece alguns padrões que devem ser seguidos por todos os produtos que participam de integrações. Esses padrões, por exemplo, definem tipos de mensagens suportadas e informações obrigatórias que farão parte do conteúdo de cada mensagem.  Porém, a composição dessas mensagens será definida em conjunto com especialistas de negócio e não faz parte do escopo deste documento.


Tipos de Mensagens

O padrão de mensagem TOTVS estabelece três tipos de mensagens: BusinessMessage, ResponseMessage e ReceiptMessage.


BusinessMessage

BusinessMessage são mensagens que iniciam qualquer processo de troca de mensagens entre os aplicativos. Sempre que um aplicativo enviar ou solicitar informações de outro aplicativo, enviará uma mensagem do tipo BusinessMessage que será processada pelo destinatário.

Existem dois tipos de BusinessMessage:

  • Event:  as mensagens de evento são aquelas cujo objetivo é notificar outros aplicativos sobre a ocorrência de um evento. Estas mensagens são normalmente utilizadas para fins de replicação de dados, quando um dos aplicativos – considerado o principal (cadastro master) – envia notificações sobre a inclusão, alteração ou eliminação de um registro para os demais (slaves).

  • Request: as mensagens de solicitação são utilizadas quando um aplicativo necessita de informações de outro aplicativo, sejam estas consultas ou processamento de determinadas informações. Entende-se que o destinatário utiliza seus recursos para processar informações enviadas pela origem e retornar apenas o resultado do processo. Essas mensagens são normalmente enviadas por aplicativos clientes a aplicativos servidores, como por exemplo, a consulta do saldo de um item onde o cliente envia apenas o item do qual deseja o saldo, o servidor faz o processamento e retorna o saldo.

Pode-se dividir a mensagem de evento em dois tipos:

  1. Upsert: o conteúdo da mensagem de evento é tratado pelo destino como uma inclusão ou modificação.

  2. Delete: o conteúdo da mensagem de evento é tratado pelo destino como uma exclusão. Normalmente a origem envia somente os campos pertencentes à chave primária.

A tabela a seguir apresenta um comparativo entre mensagens de evento e de solicitação:

 

Event

Request

Objetivo

Replicação de dados

Centralização de lógica

Origem

Um aplicativo (principal ou master)

Vários aplicativos (clientes)

Destino

Vários aplicativos (para repasse de cadastros)

Um aplicativo (detentor da lógica)

Tipo de entrega

assíncrona (não necessita de resposta ou resposta imediata).

síncrona (envia e aguarda o retorno para continuar o processo).

ResponseMessage

ResponseMessage são mensagens de retorno que possuem um conteúdo definido pelo aplicativo destinatário. Esse conteúdo representa o resultado do processamento feito a partir da mensagem BusinessMessage do aplicativo origem.

Importante ressaltar que esse tipo de mensagem só será acionado a partir de uma mensagem de negócio, ou seja, a origem e o destino da ResponseMessage são o inverso da BusinessMessage.

A mensagem de resposta, junto com seu conteúdo, é adicionada aos registros de histórico e associada à mensagem de negócio (BussinessMessage) de origem, como forma de rastrear todo o processo da troca de mensagem.





ReceiptMessage

ReceiptMessage representa a confirmação de recebimento de uma BusinessMessage pelo aplicativo destino.

Diferente da ResponseMessage, a ReceiptMessage não possui conteúdo descrito ou que possa ser modificado por programas de negócio.

O objetivo da mensagem desse tipo é verificar se o destino recebeu a mensagem, independente de processá-la ou não durante aquele período. É utilizada no tipo de entrega assíncrono.

Posteriormente, quando a mensagem for processada pelo aplicativo destino, uma mensagem de resposta – ResponseMessage – é gerada e encaminhada ao aplicativo que originou a BusinessMessage.






Tipos de Entrega (Delivery Type)

Delivery Type é a denominação pela qual é referenciado o tipo de comunicação entre os aplicativos. Em determinados modelos de dados, o programa necessita de uma resposta imediata do aplicativo externo. Já em outras vezes, o modelo não necessita de uma resposta ou não naquele determinado momento, economizando o tempo que o programa aguarda durante troca de mensagens.

Com isso, foram criados dois tipos de entrega:


Síncrono (Sync)

O processamento da mensagem do tipo síncrono acontece no momento da execução, ou seja, o aplicativo interno aguarda a resposta do aplicativo externo para continuar a execução. Normalmente, mas não necessariamente, utiliza-se essa funcionalidade quando são necessárias mais informações no retorno, como dados complementares aos enviados. Exemplificando, seria como se ator A estivesse realizando uma ligação para o Ator B, está ligação é realizada de forma direta, como acontece na imagem abaixo.




Assíncrono (Async)

 Quando enviada uma mensagem do tipo assíncrono, o aplicativo interno não aguarda uma resposta do aplicativo externo para continuar a execução. O destino recebe a mensagem e coloca em uma fila junto com outras mensagens assíncronas. Posteriormente, o processamento delas é efetuado na ordem em que chegaram. Ou seja, caso a origem necessite de retorno, será feito em um momento futuro e não durante a execução do programa. É comum o uso dessas mensagens para replicação de cadastros simples, onde não envolve processamento complexo. Exemplificando, seria como se ator A estivesse realizando uma ligação para o ator B, e não obtivesse exito deixando várias mensagens na secretária eletrônica, isso geraria uma fila de mensagens que seria entregue ao ator B, quando o mesmo verificasse essas mensagens na secretária eletrônica, como acontece na imagem abaixo.