T2.7: Manages Messages

Descripción General

La purga manual de mensajes proporciona a los administradores control directo sobre la eliminación de mensajes antiguos de la base de datos de InterSystems HealthConnect. A medida que las productions procesan miles o millones de mensajes con el tiempo, el historial de mensajes se acumula y puede consumir espacio significativo en la base de datos. La purga regular es esencial para el mantenimiento y el rendimiento de la base de datos. La interfaz de purga manual se accede a través del menú Production, navegando al Message Viewer y seleccionando la opción Purge.

Purga Basada en Sesión

La operación de purga está organizada alrededor de sesiones de mensajes en lugar de mensajes individuales. Una sesión representa el procesamiento completo de un mensaje a través de la production, incluyendo el mensaje original recibido por un Business Service, cualquier enrutamiento a través de Business Processes, envío a través de Business Operations, y todos los acknowledgments y respuestas. Purgar una sesión elimina todos los mensajes y datos relacionados asociados con ese flujo de mensaje completo.

Aislamiento de Namespace

Las operaciones de purga son específicas de namespace. Cuando realiza una purga manual, solo afecta mensajes en el namespace actual donde se ejecuta la production. Si tiene múltiples productions en diferentes namespaces, debe purgar cada namespace por separado. Este aislamiento de namespace previene la purga accidental de mensajes de productions no relacionadas y proporciona control granular sobre la retención de mensajes por production.

Opciones de Configuración

La interfaz de purga manual proporciona varias opciones de configuración para controlar qué se purga y cómo. Entender estas opciones es esencial para una purga de mensajes segura y efectiva. Las tres opciones principales - Include Message Bodies, Purge Only Completed Sessions y configuraciones de período de retención - cada una afecta el comportamiento de purga de maneras importantes cubiertas en las siguientes secciones.

Propósito de la Configuración

La opción Include Message Bodies es una de las configuraciones de purga más importantes y casi siempre debe establecerse en On. Esta configuración controla si la operación de purga elimina solo los registros de encabezado de mensaje o tanto encabezados como contenido del cuerpo de mensaje. Los encabezados de mensaje contienen metadatos como timestamps, componentes de origen y destino, IDs de sesión y estado de mensaje, mientras que los cuerpos de mensaje contienen el contenido real del mensaje HL7.

Estableciendo a On (Recomendado)

Cuando Include Message Bodies está establecido en On, la operación de purga elimina tanto registros de encabezado como registros de cuerpo, eliminando completamente todos los rastros de los mensajes purgados de la base de datos. Esta es la configuración correcta para operaciones de purga normales porque asegura limpieza completa y libera el máximo espacio de base de datos. Los metadatos del mensaje se eliminan junto con el contenido del mensaje, y el almacenamiento de base de datos se recupera.

Estableciendo a Off (Precaución)

Si Include Message Bodies está establecido en Off, la operación de purga elimina solo registros de encabezado mientras deja registros de cuerpo de mensaje en la base de datos. Esto crea registros huérfanos - cuerpos de mensaje que ya no tienen encabezados correspondientes y no pueden ser accedidos o visualizados a través del message trace. Estos registros huérfanos consumen espacio de base de datos pero no proporcionan valor ya que no pueden correlacionarse con flujo de mensajes. Esta configuración debería estar en Off solo en escenarios especializados raros donde el contenido del mensaje debe retenerse por razones de cumplimiento incluso después de purgar metadatos de flujo de mensajes.

Importancia para el Examen

La configuración Include Message Bodies es lo suficientemente crítica que se prueba frecuentemente en el examen de certificación. Recuerde que la configuración correcta para operaciones de purga normales es On. Los registros de cuerpo de mensaje huérfanos son un problema común de mantenimiento de base de datos causado por configuración incorrecta de purga, y entender el propósito y la configuración recomendada de Include Message Bodies ayuda a prevenir este problema.

Propósito de la Configuración

La opción Purge Only Completed Sessions controla si la operación de purga incluye validación adicional para asegurar que solo se purgan sesiones de mensajes completadas. Esta configuración involucra una compensación entre seguridad absoluta y rendimiento de purga. Entender cuándo usar cada configuración es importante para el mantenimiento efectivo de la base de datos.

Estableciendo a On (Modo Seguro)

Cuando Purge Only Completed Sessions está establecido en On, la operación de purga realiza chequeos adicionales para verificar que cada sesión de mensaje esté completamente terminada antes de purgarla. Una sesión se considera completada cuando todos los mensajes en la sesión han alcanzado estados terminales (completados, con error o descartados) y ningún mensaje está todavía en progreso o esperando respuestas. Esta configuración proporciona seguridad garantizada - nunca purgará accidentalmente un mensaje que todavía se está procesando o esperando un acknowledgment.

Compensación de Rendimiento

La seguridad de Purge Only Completed Sessions = On tiene un costo: aumento del uso de CPU y rendimiento de purga más lento. La validación adicional requiere examinar todos los mensajes en cada sesión para verificar el estado de completado, lo que involucra más consultas de base de datos y procesamiento. Para grandes operaciones de purga que afectan millones de sesiones de mensajes, esta sobrecarga de validación puede ser significativa, causando que la purga tarde horas más de lo que tardaría sin este chequeo.

Estableciendo a Off (Modo Rápido)

Cuando Purge Only Completed Sessions está establecido en Off, la operación de purga omite la validación de completado y purga todas las sesiones que cumplen con los criterios de edad, independientemente de si están completadas. Esto es mucho más rápido porque evita la sobrecarga de validación. Sin embargo, conlleva un pequeño riesgo - si una sesión de mensaje está todavía en progreso a pesar de ser lo suficientemente antigua para cumplir con los criterios de purga, podría ser purgada mientras todavía está activa.

Recomendaciones Prácticas

La recomendación práctica es usar Purge Only Completed Sessions = On al purgar mensajes recientes (quizás mensajes de la última semana o mes) para asegurar que no se purgan inadvertidamente sesiones activas. Use Purge Only Completed Sessions = Off al purgar mensajes muy antiguos (quizás mensajes de más de 90 días) donde puede estar seguro de que no hay sesiones todavía activas. La mejora de velocidad para purgas históricas grandes justifica el riesgo mínimo.

Configuración del Período de Retención

La configuración del período de retención de mensajes controla cuán atrás en el tiempo irá la operación de purga, protegiendo mensajes recientes de ser purgados. Esto se configura usando el parámetro "Do not purge most recent N days" en la interfaz de purga manual. Cualquier mensaje más nuevo que N días se excluye automáticamente de la purga, independientemente de otras configuraciones. Solo los mensajes más antiguos que el período de retención son elegibles para purga.

Consideraciones de Cumplimiento

Determinar el período de retención apropiado involucra equilibrar varios factores. Las organizaciones de salud frecuentemente tienen requisitos de cumplimiento que requieren períodos mínimos de retención de mensajes. Por ejemplo, las regulaciones podrían requerir retener mensajes por 90 días, 6 meses o incluso años dependiendo del tipo de mensaje y jurisdicción. El período de retención debe satisfacer estos requisitos de cumplimiento para asegurar que la organización no purgue mensajes que deben retenerse por razones legales o regulatorias.

Necesidades Operacionales

Las necesidades operacionales también influyen en las decisiones del período de retención. Los mensajes de los últimos varios días o semanas se necesitan frecuentemente para resolver problemas de integración, investigar discrepancias entre sistemas o responder preguntas sobre cuándo se enviaron mensajes específicos. Un período de retención demasiado corto crea problemas operacionales al purgar mensajes mientras todavía son valiosos para operaciones y soporte. La mayoría de los entornos de producción retienen al menos 30 días de mensajes para propósitos operacionales.

Balance de Almacenamiento y Rendimiento

La capacidad de almacenamiento y las consideraciones de rendimiento de la base de datos afectan el otro extremo de la ecuación. Mayor retención significa más mensajes en la base de datos, consumiendo más almacenamiento y potencialmente afectando el rendimiento de consultas en el message viewer. Las productions de muy alto volumen podrían encontrar que retener un año de mensajes crea desafíos de tamaño de base de datos y rendimiento. El período de retención debe equilibrar las necesidades de cumplimiento y operacionales contra las restricciones de almacenamiento y rendimiento.

Valores Típicos de Retención

Los períodos de retención típicos varían por entorno y volumen de mensajes. Los entornos de desarrollo y prueba frecuentemente usan retención corta (7-30 días) ya que los mensajes históricos tienen valor limitado. Los entornos de producción típicamente usan 30-90 días para retención de mensajes activos, suficiente para la mayoría de las necesidades operacionales sin almacenamiento excesivo. Algunas organizaciones implementan retención por niveles, manteniendo mensajes recientes en la base de datos operacional y archivando mensajes más antiguos en almacenamiento separado para retención de cumplimiento a largo plazo.

Beneficios de la Purga Automática

Mientras la purga manual es útil para limpieza ad-hoc o resolución de problemas, los entornos de producción deberían implementar purga automática usando el Task Manager para asegurar limpieza de mensajes regular y consistente sin intervención manual. El Task Manager en InterSystems IRIS le permite programar tareas recurrentes, incluyendo tareas de purga de mensajes, que se ejecutan automáticamente según una programación definida.

Creando Tareas de Purga

Las tareas de purga automática se crean a través del System Management Portal, navegando a System Operation, luego Task Manager, luego New Task. Al crear una tarea de purga, la configuración crítica es especificar el nombre de clase de tarea: Ens.Util.Task.Purge. Este nombre de clase es importante conocerlo para el examen de certificación - las preguntas pueden pedirle que identifique la clase correcta para purga automática o solucione problemas de una tarea de purga que está usando la clase incorrecta.

Opciones de Configuración de Tarea

La configuración de tarea de purga incluye todas las mismas opciones disponibles en purga manual - Include Message Bodies, Purge Only Completed Sessions, período de retención y tipo de datos a purgar (cubierto en la siguiente sección). Estos parámetros se establecen en la definición de tarea y se aplican cada vez que se ejecuta la tarea. Esto asegura comportamiento de purga consistente - el mismo período de retención y configuraciones se aplican automáticamente en la programación definida.

Opciones de Programación

La programación de tareas proporciona flexibilidad para cuándo se ejecutan las operaciones de purga. La mayoría de los entornos de producción programan tareas de purga para ejecutarse diariamente durante horas de baja actividad, típicamente tarde en la noche o temprano en la mañana cuando el volumen de mensajes es bajo y los recursos del sistema están disponibles. La purga semanal es apropiada para entornos de menor volumen o cuando períodos de retención más largos significan que hay menos urgencia para limpieza frecuente. La programación puede configurarse usando varios patrones - días específicos de la semana, días específicos del mes o programaciones complejas usando sintaxis similar a cron.

Consideraciones de Namespace

Un punto crítico para entender es que las tareas de purga son específicas de namespace. Cada tarea se ejecuta en un namespace específico y solo purga mensajes en ese namespace. Si su instancia de IRIS aloja múltiples productions en diferentes namespaces, debe crear tareas de purga separadas para cada namespace. Las preguntas de examen a veces prueban si reconoce que una sola tarea de purga no purgará mensajes en todos los namespaces - necesita una tarea por namespace de production.

Descripción General de Tipos de Datos

El parámetro TypesToPurge en tareas de purga (tanto manual como automática) controla qué categorías de datos se incluyen en la operación de purga. InterSystems HealthConnect almacena varios tipos de datos relacionados con production más allá de solo mensajes, incluyendo registros de eventos, registros de ejecución de reglas de negocio, registros de I/O y alertas gestionadas. La configuración TypesToPurge determina cuáles de estos tipos de datos se purgan.

Opción All Types

"All Types" es la configuración más completa, purgando todas las categorías de datos de production que cumplen con los criterios de edad. Esto incluye sesiones de mensajes (los datos primarios de flujo de mensajes), entradas de registro de eventos (registro detallado de actividades de production), registros de reglas de negocio (historial de ejecución de reglas de enrutamiento), registros de I/O (registros de entrada/salida de bajo nivel), alertas gestionadas (registros históricos de alertas) y otros datos relacionados con production. All Types proporciona la limpieza más completa y libera el máximo espacio de base de datos.

Opción Messages

"Messages" es una configuración más selectiva que purga solo datos de sesión de mensajes - los mensajes mismos, sus encabezados, cuerpos y metadatos directamente relacionados. Esta configuración preserva otros datos de production como registros de eventos y registros de reglas de negocio mientras limpia los datos primarios de mensajes. Messages es apropiado cuando desea eliminar contenido de mensaje antiguo para gestión de espacio mientras retiene registros operacionales para resolución de problemas o auditoría.

Otras Opciones Selectivas

Otras opciones específicas de TypesToPurge permiten control aún más granular. Puede purgar solo registros de eventos, o solo registros de reglas de negocio, o solo registros de I/O, mientras preserva mensajes. Estas opciones selectivas se usan menos comúnmente pero pueden ser valiosas en escenarios específicos - por ejemplo, purgar registros de eventos verbosos que están consumiendo espacio mientras retiene historial de mensajes para cumplimiento.

Importancia para el Examen

Para el examen de certificación, es importante saber que "All Types" y "Messages" son los valores de TypesToPurge más comunes. Las preguntas de examen sobre tareas de purga frecuentemente especifican qué tipos deberían purgarse, y necesita reconocer la configuración correcta. Una pregunta podría mostrar una tarea de purga configurada con TypesToPurge = "Events" y preguntar por qué no se están purgando mensajes - la respuesta es que Events solo purga registros de eventos, no mensajes.

Importancia de la Verificación

Incluso después de configurar tareas de purga automática, es esencial verificar que se estén ejecutando correctamente y realmente purgando mensajes según lo previsto. Varios errores de configuración pueden causar que las tareas de purga fallen silenciosamente o purguen los datos incorrectos, y entender cómo verificar la configuración correcta de tareas es una habilidad importante probada en el examen de certificación.

Verificación de Namespace

El chequeo más crítico es verificar la configuración de namespace. Cada tarea de purga debe configurarse para ejecutarse en el namespace correcto donde existe la production. Un escenario común de examen muestra una tarea de purga ejecutándose en el namespace ENSEMBLE cuando la production está realmente en el namespace HEALTHCONNECT. La tarea se ejecuta sin errores pero no purga ningún mensaje porque está buscando en el namespace incorrecto. Al solucionar problemas de purga, siempre verifique que el namespace de la tarea coincida con el namespace de la production.

Verificación del Nombre de Clase

El nombre de clase de tarea debe ser exactamente correcto: Ens.Util.Task.Purge. Las preguntas de examen a veces muestran tareas configuradas con nombres de clase incorrectos como Ens.Task.Purge, Ens.Util.Purge o InterSystems.Task.Purge. Estos nombres de clase incorrectos causan que la tarea falle completamente en ejecutarse. Al revisar la configuración de tareas de purga, verifique el nombre de clase exacto incluyendo capitalización y puntuación correctas.

Verificación de TypesToPurge

El parámetro TypesToPurge debe coincidir con lo que realmente desea purgar. Si el requisito es purgar mensajes y la tarea está configurada con TypesToPurge = "Events", los mensajes no se purgarán incluso aunque la tarea se ejecute exitosamente. De manera similar, verifique que los períodos de retención estén configurados correctamente - una tarea configurada para purgar mensajes de más de 365 días no ayudará si la base de datos está llena y necesita purgar mensajes de más de 90 días.

Verificación de Estado de Tarea

Verifique que la tarea no esté suspendida. Las tareas pueden suspenderse manualmente por administradores o automáticamente si fallan repetidamente. Una tarea suspendida no se ejecutará según su programación. La interfaz del task manager muestra el estado de la tarea, y las tareas suspendidas están claramente marcadas. Si una tarea de purga no se está ejecutando, verifique que esté en estado activo en lugar de suspendida.

Verificación de Programación

Finalmente, verifique la programación de la tarea y la próxima fecha de ejecución. La programación debería ser apropiada para el entorno - típicamente diaria para entornos de producción. La próxima fecha de ejecución debería ser razonable - si hoy es 15 de enero y la próxima ejecución está programada para 28 de febrero, algo está mal con la configuración de programación. Verifique que la programación esté configurada según lo previsto y que la próxima ejecución ocurrirá cuando se espera.

Accediendo al Historial de Ejecución

El Task Manager proporciona historial de ejecución para todas las tareas programadas, incluyendo tareas de purga. Este historial es invaluable para verificar que las tareas de purga se están ejecutando según lo previsto y para solucionar problemas cuando las operaciones de purga fallan o no logran resultados esperados. Entender cómo acceder e interpretar el historial de ejecución de tareas es importante para soporte de producción y escenarios de examen.

Interpretando Éxito y Falla

El historial de ejecución de tareas muestra cada vez que se ejecutó la tarea, incluyendo el tiempo de inicio, tiempo de finalización y estado de completado (completada exitosamente, fallida, todavía ejecutándose). Para tareas de purga, completado exitoso indica que la operación de purga terminó sin errores, pero no necesariamente significa que se purgaron mensajes - si ningún mensaje cumplió con los criterios de purga (todos los mensajes están dentro del período de retención), la tarea se completa exitosamente pero no purga nada.

Diagnosticando Fallas

Cuando una tarea de purga falla, el historial de ejecución incluye mensajes de error o stack traces indicando qué salió mal. Las causas comunes de falla incluyen configuración incorrecta de namespace (la tarea no puede encontrar la production), nombre de clase incorrecto (la clase de tarea no existe o no puede instanciarse), conflictos de bloqueo de base de datos (la purga no puede adquirir los bloqueos necesarios para eliminar registros) o restricciones de recursos (memoria insuficiente o espacio de base de datos para completar la purga).

Monitoreo de Rendimiento

El historial de ejecución también puede mostrar tendencias de rendimiento. Si las tareas de purga que normalmente se completan en 10 minutos repentinamente comienzan a tardar horas, esto podría indicar fragmentación de base de datos, volumen excesivo de mensajes u otros problemas de rendimiento que requieren atención. Monitorear la duración de tareas de purga a lo largo del tiempo ayuda a identificar estas tendencias antes de que se conviertan en problemas críticos.

Relevancia para el Examen

Para el examen de certificación, entienda que el historial de ejecución de tareas es la herramienta principal para verificar que las tareas de purga están funcionando correctamente. Si una pregunta de examen pregunta cómo determinar si una tarea de purga ha estado ejecutándose, la respuesta involucra verificar el historial de ejecución de tareas. Si una pregunta pregunta cómo solucionar problemas de una tarea de purga fallida, revisar el historial de ejecución para mensajes de error es el primer paso correcto.