Serviço de Mensageria — visão geral

Introdução

O Serviço de Mensageria envia notificações multicanal (e-mail, SMS, WhatsApp, push) a partir de eventos do ecossistema MobileMed — em especial o Portal PACS.

Características principais:

• Desacoplamento: qualquer sistema pode publicar eventos na fila de entrada do orquestrador.
• Processamento assíncrono: duas filas SQS (entrada do orquestrador → saída para o worker).
• Multicanal: e-mail (SES), SMS e WhatsApp (AWS End User Messaging), push (FCM).
• Configuração por empresa: regras e destinatários no MySQL do portal; templates no Postgres do serviço de notificações.
• Auditoria: logs no MongoDB (portal), erros em tb_message_error (orquestrador) e tb_erros_notifications (worker).

:::info Interface web externa A aplicação mm-core-notification-frontend (gestão avançada de templates e relatórios) existe no repositório, mas não está disponível no produto por enquanto. A configuração operacional é feita no Portal (módulo Integração com Mensageria). Esta documentação não cobre essa interface. :::

---

Arquitetura

Fluxo resumido

1. Portal API monta envelope SQS (empresa_id, notifications[], MessageAttributes.type_notification) e publica na fila inbound do orquestrador (SQS_QUEUE_URL no .env do portal).
2. Orchestrator valida empresa/tipo, resolve templates, monta destinatários × canais e publica uma mensagem na fila do worker.
3. Worker consome a fila, persiste estado e dispara cada canal via adaptadores (SES, EUM, FCM).

Diagramas legados (podem ser atualizados visualmente):

• Fluxo geral
• Fluxo backend

---

Bancos de dados

Base	Uso
MySQL (portal)	tb_message_settings, tb_message_type, listas de e-mail/telefone, grupos, tb_usuarios, tb_message_error
Postgres (notificações)	tb_templates, tb_template_channel, notificações enviadas, dedup, erros do worker
MongoDB (portal)	MessageLog — auditoria de eventos enfileirados

---

Canais (código no payload)

Código	Canal
0	E-mail
1	WhatsApp
2	SMS
3	Push (FCM)

---

Funcionalidades do worker

• Consumo contínuo de SQS_QUEUE_URL (long polling).
• POST /notifications/send — envio síncrono (testes).
• POST /notifications/process-job — processamento de job por canal.
• CRUD de templates, métricas, relatórios de erros (API REST documentada em Notification Worker e Notification Orchestrator na API Reference).
• Retry via SQS; DLQ configurada na AWS (redrive policy).

---

Integração sem orquestrador (SDK)

Sistemas que já enviam o payload no formato do worker podem publicar diretamente na fila do worker, sem passar pelo portal. Ver Notification_service/mm-core-notification-worker/docs/MESSAGE_CONTRACT.md e docs/SDK_USAGE_EXAMPLES.md no repositório do serviço.

---

Documentação relacionada neste site

Página	Conteúdo
Guia do utilizador — Portal	Como ligar o módulo e configurar regras
Regras e eventos	Catálogo completo de eventos e condições
Integração técnica — Portal	Rotas API, fila SQS, payload
Notification Orchestrator API	POST /notifications/preprocess, health (~3210)
Notification Worker API	Envio, templates, métricas, erros (~3200)
Contrato da fila do worker	Payload SQS / process-job

---

Auditoria e erros

• Orquestrador (tb_message_error): empresa desabilitada, tipo desabilitado, canal ativo sem template, erros de “notificar paciente” (exame/e-mail ausente).
• Worker (tb_erros_notifications): falha de envio por canal após montagem.
• DLQ SQS: mensagens que excedem maxReceiveCount na fila.

---

Referências no código-fonte

• Notification_service/mm-core-notification-worker/docs/FLUXOS_SISTEMA.md
• Notification_service/mm-core-notification-worker/docs/ORCHESTRATOR_REGRAS_NEGOCIO.md
• Portal_mobilemed/mm-pacs-portal-api/docs/mensageria-fluxo.md