Propósito
O objetivo desse Grooming foi o de alinhar como deve ser o relacionamento entre "transação/mensagem" e adapters.
O principal problema apontado já está sendo encontrado pelos segmentos, que é o seguinte:
No recebimento da resposta da mensagem assíncrona, pode ser que seja ativado um fonte diferente daquele que era o desejado.
Isso está ocorrendo porque estão cadastrando fontes diferentes com o mesmo nome, e a resposta atualmente usa esse nome como chave para definir por qual caminho deve seguir.
Ata
Foi apontado que o mais complicado não é o envio, e sim o recebimento. Como saber qual dos adapters vinculados à mensagem disparar?
Cliente e fornecedor atualmente funcionam bem dividindo a mesma mensagem porque são mantidos pela mesma equipe, e assim conseguem se organizar.
O problema começa quando uma mesma mensagem é compartilhada entre diversos módulos, inclusive de parceiros.
O projeto do EAI 2.0 no RM resolveu problemas similares com a unificação de pontos em comum.
Conclusões
Uma mensagem única deve ter um único ponto de entrada, e não vários. Ou seja, o relacionamento entre mensagem e adapter é de 1..1.
Ela é similar à um serviço, onde cada endpoint é um nome único. O que é feito internamente não é visível a quem está o consumindo.
Dessa forma, é possível gerar um adapter seletor/orquestrador (nome a definir).
Ele é a única entrada, e fica responsável por definir, com base nos dados no corpo da mensagem, por qual caminho / método / rotina toda a informação deve ser tratada.
Ações
- Documentar o padrão acordado
- Encerrar a issue DEAI1-2092 com link para a documentação produzida
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas