Linha Logix

Páginas filhas
  • LGX - EAI2
3 mais filhas

Versões comparadas

Versão antiga 29

changes.mady.by.user Ieda Ferreira Alves Flock

Gravado em

comparado com

Nova versão 30

changes.mady.by.user Ieda Ferreira Alves Flock

Gravado em

Chave

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






O que é o EAI


Expandir
titleEAI..
Informações
iconfalse
Section
Column
width40%




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.

Column
width60%



Objetivo


Expandir
titleObjetivo...
Informações
iconfalse

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


Tipos de Mensagens

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


Informações
iconfalse
Expandir
titleBusinessMessage...
Informações

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



Informações
iconfalse
Expandir
titleResponseMessage e ReceiptMessage...
Informações
iconfalse

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.





Informações
iconfalse

ReceiptMessage

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

Diferente da ResponseMessage, a ReceiptMessage

 não

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.