ER_PCREQ_9740_Implementar_monitor

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Implementar as apis e alterações na camada do EAI para uso com o novo monitor único de integrações. 

Definição da Regra de Negócio

Alteração no comportamento da fila do EAI.

Para comportar o novo monitor único de integrações TOTVS, as seguintes alterações devem ser realizadas na camada de EAI:

• Toda mensagem recebida no EAI, independentemente de estar em  um formato correto ou não, deverá ser gravada na fila de integrações. Hoje somente mensagens em formato válido e que atendam aos requisitos abaixo são gravadas na fila (no contexto Protheus):
  • A empresa e filial contidas no cabeçalho da mensagem única sejam válidas no contexto Protheus;
  • Seja possível atribuir o usuário 'admin' para o processamento da mensagem.

A priorização do retorno dos erros na mensagem deverá ser através da responsemessage da mensagem única. Alguns casos ainda poderão retornar via SoapFault (uma mensagem que não possa ser reconhecida em nenhum protocolo retornará por SoapFault, por compatibilidade do legado, por exemplo). 

Criação de novos Status para as mensagens na fila de Integrações

Novos status deverão ser criados para apresentação no monitor único. São Eles:

• Received: É o estado inicial de uma mensagem. Apenas chegou no destino, mas não foi sequer identificada como uma mensagem TOTVS. 
• Recognized: Quando a mensagem foi “parseada” e reconhecida como uma mensagem TOTVS. 
• Validated: Quando a mensagem foi validada e aceita para seguir o processamento. Algumas validações que colocam a mensagem neste estado são: unicidade do UUID da mensagem e aplicativo de origem da mensagem X mensagens anônimas habilitadas. 
• Delivering: Indica que a mensagem foi encaminhada pra entrega. Geralmente é o status que indica que a mensagem está na fila. 
• Delivered: Indica que a mensagem foi enviada para o destino. Não significa que ela foi processada com sucesso. No caso de mensagens assíncronas, o status mudaria para Delivered ao receber a ReceiptMessage do destino.
• Processed: Indica que a mensagem de negócio (BusinessMessage) foi processada sem erros.  Este status será opcional para mensagens do tipo ResponseMessage e ReceiptMessage.
• Processing: Indica que a mensagem de negócio (BusinessMessage) está em processamento. Esse status somente ocorrerá nas mensagens de recebimento.
• Refused: Quando, durante o processo de validação, a mensagem não atende aos critérios. Exemplos: mensagem com UUID existente, mensagem recebida de aplicativo não cadastrado. 
• Malformed: Quando, na tentativa de “parsear” a mensagem, ela não se apresenta no formato de mensagem TOTVS. 
• NotDelivered: Quando a mensagem não é enviada ao destino. Os motivos estão relacionados a queda na conexão, erro na transmissão, entre outros. Neste estado, a resposta (ou recibo, no caso de envio assíncrono) não foi gerada pelo destinatário.
• BusinessError: a mensagem foi enviada e a resposta contém erros.

Apesar de alguns dos status não existirem no sistema ou não existirem de maneira física, somente lógica (Delivering correspondendo a 'aguardando execução') a resposta à api deverá retornar algum status válido.

 FASE DE INCLUSÃO DA MENSAGEM NA FILA/REPOSITÓRIO

Status de monitor não implementado no recebimento das mensagens:

FASE DE EXECUÇÃO DA MENSAGEM NA FILA/REPOSITÓRIO

Status de monitor não  implementado no envio das mensagens:

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

Fluxo do Processo

Não se aplica

Dicionário de Dados

 Não se aplica

Grupo de Perguntas

Não se aplica

Consulta Padrão

Não se aplica

Estrutura de Menu

 Não se aplica

Cadastro de Papéis

Não se aplica