Esse documento tem como objetivo descrever as alterações necessárias no modelo atual de mensagem única, procurando atender a definição de que “o vertical deve ser o dono da integração”.
...
Essas alterações não têm como objetivo substituir o modelo anterior de mensageria única e sim agregar novas funcionalidades e recursos ao mesmo.
Para fins de adequação, mudaremos o nome de “Mensagem Única” para “Mensageria TOTVS”.
1) Expor os objetos de negócio para recuperação de seus Schemas
As equipes responsáveis pelos produtos Totvs deverão desenvolver serviços (webServices) para expor as estruturas (schemas) de seus objetos de negócios, afim de que possam ser chamados externamente. Esses schemas deverão estar no formato de xsd;
Isso permitirá com que os produtos possam enviar dados, no formato de xml (BusinessContent), contendo informações já no formato nativo dos objetos de negócio (sem necessidade de transformação).
Objetos de negócio que serão chamados via mensagem de “Request” deverão expor serviços a fim de que possam retornar schemas contendo a definição dos seus parâmetros de entrada. Esses schemas, também, deverão também estar no formato de xsd.
...
...
...
<ResponseMessage> <ReceivedMessage> <SentBy>client</SentBy> <UUID>94551485144878487457857454</UUID> <MessageContent><![CDATA[ <TOTVSMessage>...</TOTVSMessage> ]]> </MessageContent> </ReceivedMessage> <ProcessingInformation> <ProcessedOn>2001-12-31T12:00:03</ProcessedOn> <Status>OK</Status> <ListOfMessages> <Message type="WARNING" code="c1">msg1</Message> <Message type="ERROR" code="c2">msg2.</Message> </ListOfMessages> </ProcessingInformation> <ReturnContent> <XMLContent> ... </XMLContent> </ReturnContent> </ResponseMessage> |
|
Informações |
---|
Em mensagens de exclusão, as informações excluídas também deverão ser retornadas nessa tag para recuperação correta do De/Para nos aplicativos verticais. |
Informações |
Na tag “MessageContent” das mensagens de resposta (ResponseMessage) não deve ser enviado nenhum valor devido a limitação no tamanho das mensagens em alguns ERPs. |
Informações |
---|
Objetos de negócio nos aplicativos verticais deverão “emparelhar” com seus respectivos objetos de negócios no ERP. Exemplo: Atualmente no RM existem 4 objetos de negócios diferentes responsáveis pela inclusão dos dados bancários (banco, agencia, conta e conta caixa). No Protheus existe apenas um único objeto de negócio para inclusão dessas informações. Sendo assim, deve ser criado pela equipe de segmentos do RM um único objeto de negócio capaz de receber todas as informações bancárias de uma única vez. Esse novo objeto de negócio a ser criado pelo RM “orquestrará” as chamadas aos objetos de negócio nativos do segmento;objetos de negócio nativos do segmento; |
Informações |
---|
O originador da mensagem deve observar o conteúdo da tag "ReceivedMessage\MessageContent" para a montagem do "DE-PARA" no retorno da mensagem. Não consideramos prudente buscar o valor diretamente da fila pelo fato de ser impossível garantir a existência da mensagem em entregas do tipo assíncronas. |
3) Direção das mensagens
3.1 - Origem –> ERP / Destino -> Vertical
...
Retorno para o EAI(vertical) um xml contendo os dados atuais após a execução do objeto de negócio;
Informações |
---|
A partir de agora, os EAI’s não serão mais responsáveis em transformar mensagens e controlar informações de De/para. Esses serviços serão de responsabilidade dos diversos seguimentos. |
Informações |
---|
Serviços genéricos poderão ser disponibilizados no EAI para facilitar o trabalho dos segmentos. |
3.2 - Origem –> Vertical / Destino -> ERP
3.2 - Origem –> Vertical / Destino -> ERP e outro Vertical
Mensagem de negócio - BusinessMessage/Event
...
...