Skip to main content

Historia de Usuario: Servicio de Notificación y Registro

Versión: 1.0
Fecha: 2025-06-03
Autor: Arquitecto de Tecnologías

🎯 Historia de Usuario​

Como Sistema de Integración EDI
Quiero un servicio de notificación centralizado y un mecanismo para registrar las notificaciones enviadas
Para que pueda alertar a los administradores o equipos de soporte sobre eventos críticos (ej. fallos terminales en procesamiento de líneas) y mantener un registro auditable de estas comunicaciones.

✅ Criterios de Aceptación​

  • Se debe implementar un componente/servicio de Spring (NotificationService).
  • NotificationService debe tener un método para enviar notificaciones (ej. sendNotification(recipient, subject, message, typeId, fileId, lineId)).
  • Inicialmente debe soportar envío por correo electrónico. El/los destinatarios y el servidor SMTP deben ser configurables.
  • Cada intento de envío debe registrarse en la tabla notification_logs con:
    • file_id, line_id (si aplican)
    • notification_type_id (FK a cat_notification_types, ej. MAX_RETRY_FAILURE_ORACLE_CREATION)
    • recipient
    • message (contenido)
    • sent_at (timestamp)
    • notification_log_status_id (FK a cat_notification_log_statuses, ej. SENT, FAILED_TO_SEND)
    • error_message (si falla el envío)
  • La acción S_ORACLE_CREATION_FAILED_TERMINAL en la SM debe invocar al NotificationService con los detalles.
  • El mensaje debe incluir file_id, line_id, y el error relevante.

🧪 Definition of Done (DoD)​

  • NotificationService implementado.
  • Capacidad de envío de correo configurada.
  • Registros en notification_logs creados por cada intento.
  • Invocación desde la SM implementada.
  • Formato de mensajes definido.
  • Configuración externalizada.

📦 Consideraciones Técnicas​

  • Usar JavaMailSender de Spring Boot.
  • Definir catálogos: cat_notification_types, cat_notification_log_statuses.
  • Manejar errores de envío y registrar estado fallido si aplica.

🛠️ Consideraciones para Producción​

🔐 Seguridad​

  • Evitar incluir información sensible en correos no cifrados.
  • Proteger credenciales SMTP.

🧠 Eficiencia e Idempotencia​

  • Envío asíncrono (@Async) para no bloquear la SM.
  • Mecanismo de reintento o registro manual si falla.

🧪 Observabilidad y Logging​

  • Logs detallados por intento.
  • Métricas: notificadas vs. fallidas.
  • Alertas por alta tasa de fallos.

Historia de Usuario: Creación y Configuración del Esquema de Base de Datos

Versión: 1.0
Fecha: 2025-06-03
Autor: Arquitecto de Tecnologías

🎯 Historia de Usuario​

Como Desarrollador / Administrador de Base de Datos
Quiero tener el esquema completo de la base de datos PostgreSQL creado y configurado según el HLD
Para que todos los componentes del sistema puedan persistir y consultar datos de forma confiable y estructurada.

✅ Criterios de Aceptación​

  • Crear todas las tablas del HLD (Secciones 5 y 5.1):
    • cat_file_sources
    • cat_generic_processing_statuses
    • cat_file_overall_statuses
    • cat_line_validation_statuses (si aplica)
    • cat_line_oracle_creation_statuses (si aplica)
    • cat_notification_types
    • cat_notification_log_statuses
    • processed_files
    • file_lines (incluir sm_state, eliminar o ajustar validation_status_id, oracle_creation_status_id)
    • notification_logs
  • Definir correctamente tipos de datos, restricciones, PKs/FKs.
  • Insertar valores iniciales en tablas de catálogo (cat_*).
  • Crear índices en columnas clave (file_id, sm_state, file_name, etc.).
  • Si se usan triggers (ej. last_updated_at), implementarlos y probarlos.
  • Scripts DDL/DML deben estar versionados en el repositorio.
  • Usar herramienta de migración (Flyway o Liquibase) para aplicar el esquema.

🧪 Definition of Done (DoD)​

  • Esquema creado en entorno de desarrollo.
  • Todas las tablas y columnas coinciden con el HLD.
  • Restricciones y relaciones implementadas.
  • Catálogos con datos iniciales.
  • Índices clave creados.
  • Scripts DDL/DML versionados.
  • Herramienta de migración configurada y funcionando.

📦 Consideraciones Técnicas​

  • Base de datos: PostgreSQL.
  • Flyway o Liquibase como herramienta de migración.
  • Indexar columnas comúnmente consultadas.

🛠️ Consideraciones para Producción​

🔐 Seguridad​

  • Usuarios con privilegios mínimos necesarios.
  • Cifrado en tránsito/reposo si hay datos sensibles.

🧠 Eficiencia e Idempotencia​

  • Monitorear rendimiento, ajustar índices.
  • Mantenimiento regular: VACUUM, ANALYZE, backups.

🧪 Observabilidad y Logging​

  • Habilitar logging de queries lentas.
  • Monitorear conexiones, uso de CPU, rendimiento de índices.