T2.3: Applies Configuration Settings

Resumen

Todos los componentes de producción en InterSystems HealthConnect comparten un conjunto común de configuraciones que controlan el comportamiento operacional fundamental.

Configuración Enabled

• Determina si el componente está activo (On) o inactivo (Off)
• Deshabilitar un componente lo detiene de procesar cualquier mensaje
• Útil durante mantenimiento o solución de problemas sin remover el componente

Pool Size

Una configuración crítica que controla instancias concurrentes:

• Pool Size de 1: Solo un mensaje procesado a la vez, asegurando procesamiento secuencial estricto
• Valores de Pool Size más altos: Permiten procesamiento paralelo, mejorando throughput pero pueden afectar el orden de mensajes
• Interactúa con gestión de colas y requisitos FIFO

Configuración Schedule

Proporciona control basado en tiempo sobre activación de componente:

• Configurar componente para estar habilitado solo durante horas o días específicos
• Útil para ventanas de procesamiento batch, horarios de mantenimiento, o integraciones de horario de negocio
• Usa sintaxis flexible permitiendo rangos de tiempo diarios, semanales y personalizados

Alert on Error

• Genera automáticamente un mensaje de alerta cuando el componente encuentra un error
• Alertas enviadas al componente especial Ens.Alert en la producción
• Pueden reenviarse a administradores vía email u otros mecanismos de notificación
• Esencial para monitoreo proactivo y respuesta rápida

Log Trace Events

Controla verbosidad de logging:

• Cuando está habilitado, información detallada de eventos se escribe al Event Log
• Invaluable para solución de problemas
• Puede impactar rendimiento y almacenamiento en entornos de alto volumen
• Habilitar durante desarrollo y solución de problemas; considerar cuidadosamente para uso en producción

Resumen

Message Schema Category es posiblemente la configuración de Business Service más crítica para integraciones HL7. Frecuentemente pasada por alto, haciéndola una trampa frecuente de examen.

Qué Hace

Define qué schema HL7 (versión y definiciones de estructura) usa el Business Service:

• El valor es típicamente una versión HL7 como "2.3.1", "2.5", o "2.7"
• También puede ser una categoría de schema personalizada si ha definido estructuras de mensaje personalizadas

Cuatro Funciones Esenciales

1. Definición de DocType

• El sistema usa el schema para determinar estructura exacta de mensaje
• Determina tipos como ADT_A01 o ORU_R01 basado en contenido de segmento MSH

2. Parsing y Visualización Apropiados

• Muestra todos los campos en azul en los detalles de trace de mensaje
• Hace la estructura de mensaje navegable en el visualizador

3. Validación de Mensaje en Message Router

• Router valida mensajes entrantes contra el schema
• Sin esta configuración, la validación falla aunque el Business Service parezca procesar exitosamente
• Crea escenario confuso de solución de problemas donde el error aparece en Message Router pero la causa raíz está en Business Service

4. Acceso a Propiedades HL7 en Reglas de Enrutamiento

• Habilita acceso a propiedades de mensaje HL7 en condiciones de reglas de enrutamiento
• Al usar sintaxis HL7.{}, el motor de reglas depende de docCategory de esta configuración
• Sin ella, las reglas de enrutamiento no pueden acceder contenido de mensaje
• Causa fallos de enrutamiento o fuerza uso de alternativas menos elegantes

Resumen

El orden de mensajes FIFO (First In, First Out) es esencial para muchas integraciones de salud donde los mensajes deben procesarse en el orden exacto en que fueron generados.

Por Qué FIFO Importa

• Ejemplo: Sistema de gestión de camas requiere mensaje de admisión de paciente antes de mensaje de transferencia a nueva habitación
• Si los mensajes llegan fuera de orden, el sistema podría rechazar la transferencia
• Paciente no reconocido como admitido aún

Requisitos de Configuración FIFO

Requiere que cada componente en la cadena de procesamiento de mensajes procese solo un mensaje a la vez:

Business Services y Business Operations

• Establecer Pool Size = 1
• Asegura que solo una instancia del componente pueda ejecutarse a la vez
• Procesa mensajes secuencialmente de la cola en orden de llegada

Business Processes

• Usar Actor Pool Size en lugar de Pool Size
• Establecer Actor Pool Size = 1 para procesamiento secuencial
• Controla cuántas instancias concurrentes del Business Process pueden estar activas
• Con Actor Pool Size = 1, solo un mensaje procesado a la vez

Trampa de Pool Size = 0

Un escenario complejo involucrando Pool Size = 0:

• NO significa que el proceso no se ejecuta
• Significa que el proceso usa instancias de la configuración de Actor Pool Size a nivel de producción
• Si Actor Pool Size a nivel de producción > 1, esto puede inadvertidamente romper el orden FIFO
• Múltiples instancias pueden procesar mensajes en paralelo
• Para FIFO estricto: Asegurar que Business Process tenga Actor Pool Size = 1 explícito

Resumen

La configuración Failure Timeout en Business Operations controla cuánto tiempo el componente continúa intentando entregar un mensaje cuando el sistema destino no está disponible o rechaza mensajes.

Failure Timeout = -1 (Reintento Indefinido)

• Valor predeterminado para muchas Business Operations TCP HL7
• El componente reintentará indefinidamente hasta que el mensaje sea entregado o suspendido manualmente
• Comportamiento FIFO: Mantiene orden FIFO estricto porque nunca se rinde en un mensaje
• Si mensaje 1 no puede entregarse, sigue reintentando indefinidamente
• Mensajes 2, 3, 4 se encolan detrás de mensaje 1 y esperan
• Riesgo: Puede causar acumulación de cola si el sistema destino permanece no disponible

Failure Timeout Positivo

Establecer a un valor positivo (como 10 o 60 segundos):

• Cuando se alcanza el timeout, Business Operation falla el mensaje actual
• Continúa procesando el siguiente mensaje en la cola
• Mejora responsividad del sistema y previene acumulación indefinida de cola
• Impacto FIFO: Rompe orden FIFO
• Mensaje 1 podría fallar y suspenderse mientras mensajes 2, 3, 4 son entregados
• Sistema destino recibe mensajes fuera de orden

El Trade-off

Trade-off fundamental en diseño de integración:

• Requisitos FIFO estrictos: Típicamente demandan Failure Timeout = -1
• Aceptar el riesgo de acumulación de cola si los sistemas destino se vuelven no disponibles
• Sistemas tolerando mensajes fuera de orden: Pueden usar valores de timeout positivos
• Mejora throughput general y responsividad del sistema

InterSystems HealthConnect proporciona capacidades comprehensivas de alertas para habilitar monitoreo proactivo de salud de producción y respuesta rápida a problemas de integración. Cada producción incluye un componente especial llamado Ens.Alert (el nombre es fijo y no puede cambiarse) que recibe automáticamente todas las alertas generadas por componentes de producción. Este receptor central de alertas puede luego reenviar alertas a administradores vía email, a sistemas de monitoreo, o a otros mecanismos de notificación.

Alert on Error es la configuración de alerta más comúnmente usada, disponible en todos los Business Services, Business Processes y Business Operations. Cuando está habilitada, esta configuración automáticamente genera una alerta cuando el componente encuentra un error durante procesamiento de mensaje. Estas alertas incluyen información sobre el tipo de error, el mensaje que disparó el error, y contexto relevante para ayudar a administradores a identificar rápidamente y responder a problemas.

Queue Count Alert proporciona una perspectiva diferente de monitoreo alertando cuando demasiados mensajes están encolados esperando procesamiento por un componente. Configura un umbral (como 100 mensajes), y cuando la cola excede esta longitud, se genera una alerta. Esto es útil para detectar problemas de capacidad del sistema, ralentizaciones del sistema destino, o picos de volumen de mensaje inesperados que podrían llevar a retrasos de procesamiento incluso si no están ocurriendo errores reales.

Queue Wait Alert monitorea latencia de mensaje en lugar de profundidad de cola. Esta configuración alerta cuando los mensajes esperan en cola más tiempo que una duración especificada (como 30 minutos o 1 hora). Esto puede detectar problemas diferentes que Queue Count Alert - podría tener solo 2 mensajes en cola, pero si han estado esperando 2 horas porque el sistema destino no está respondiendo, Queue Wait Alert se disparará incluso aunque Queue Count Alert no lo haría.

Alert Retry Grace Period es una configuración más sofisticada que previene tormentas de alertas durante escenarios de reintento de mensaje. Cuando una Business Operation está reintentando una entrega de mensaje, podría fallar múltiples veces antes de tener éxito o alcanzar el Failure Timeout. Sin Alert Retry Grace Period, cada fallo podría generar una alerta separada, abrumando a administradores con notificaciones sobre el mismo problema. Establecer un período de gracia (como 5 minutos) pospone la generación de alertas mientras los reintentos están ocurriendo, enviando una alerta solo si el problema persiste más allá del período de gracia.

La gestión segura de credenciales es esencial para integraciones empresariales donde Business Operations se conectan a sistemas externos que requieren autenticación. InterSystems HealthConnect proporciona un sistema centralizado de gestión de credenciales que almacena nombres de usuario y contraseñas de forma segura y permite que múltiples componentes referencien la misma definición de credencial. Este enfoque es muy superior a codificar duro credenciales en código o configuraciones.

Las credenciales se gestionan a través del menú Interoperability, navegando a Configure → Credentials. Esta interfaz permite crear definiciones de credenciales, cada una con un identificador único (el nombre de credencial), un nombre de usuario, y una contraseña. La contraseña se encripta cuando se almacena, protegiéndola de visualización casual en la base de datos o exportaciones de configuración. Puede crear tantas definiciones de credenciales como sea necesario para diferentes sistemas o diferentes niveles de autenticación.

Al configurar Business Operations que requieren autenticación (como conexiones HTTP, conexiones de base de datos, servidores FTP, o servicios SOAP), referencia la credencial por su identificador en lugar de ingresar el nombre de usuario y contraseña directamente. La configuración de Business Operation típicamente se llama "Credentials" y usa un dropdown para seleccionar de credenciales definidas. En tiempo de ejecución, la Business Operation recupera el nombre de usuario y contraseña de la definición de credencial y los usa para autenticación.

La capacidad de reutilización es particularmente valiosa en producciones grandes. Si tiene múltiples Business Operations conectándose al mismo sistema externo con la misma autenticación, todas pueden referenciar la misma definición de credencial. Cuando la contraseña necesita cambiarse (como parte de rotación de seguridad regular), la actualiza una vez en la definición de credencial, y todas las Business Operations automáticamente usan la nueva contraseña sin requerir cambios de configuración de componente individuales.

Default Site Settings (también llamadas System Default Settings) proporcionan un mecanismo poderoso para gestionar configuración específica de entorno fuera de la definición de producción misma. Esta capacidad es esencial para mantener código de producción consistente a través de entornos de Desarrollo, Prueba y Producción mientras permite que cada entorno use conexiones de recursos apropiadas como diferentes servidores de base de datos, servidores SMTP, rutas de archivo, o direcciones IP.

El comportamiento clave de Default Site Settings es que anulan valores importados durante despliegue de producción. Cuando exporta una producción desde Desarrollo e la importa en Producción, todas las configuraciones vienen con sus valores de Desarrollo. Sin embargo, si una Default Site Setting está configurada en el entorno de Producción para un componente particular y configuración, ese valor predeterminado toma precedencia sobre el valor importado. La producción usa el predeterminado específico de entorno en lugar del valor de Desarrollo importado.

Default Site Settings soportan notación de comodín usando el carácter asterisco (*). Por ejemplo, podría definir una configuración de ruta de archivo que aplique a todos los Business Services usando adaptadores de archivo, o una configuración de pool size que aplique a todas las Business Operations. El comodín puede usarse en la porción de nombre de componente de la definición de configuración, permitiendo que una sola configuración predeterminada controle configuración a través de múltiples componentes. Esto es particularmente útil para aplicar políticas consistentes a nivel de entorno.

En el portal de configuración de producción, las configuraciones que están controladas por Default Site Settings se muestran en azul en lugar del texto negro estándar. Este indicador visual ayuda a administradores a identificar rápidamente qué configuraciones están siendo controladas por predeterminados versus cuáles están usando valores de la definición de producción. Al solucionar problemas de configuración, verificar configuraciones coloreadas en azul puede revelar si una Default Site Setting está anulando inesperadamente la definición de producción.

Una característica importante de Default Site Settings es que no están incluidas en exportaciones de producción. Permanecen específicas de entorno y sobreviven despliegues de producción. Esto es realmente el comportamiento deseado - asegura que las configuraciones predeterminadas del entorno de Producción continúen controlando configuración específica de Producción incluso después de desplegar nuevas versiones de la producción desde Desarrollo. Sin embargo, significa que debe configurar Default Site Settings por separado en cada entorno; no se propagan automáticamente durante despliegue.

Más allá de las configuraciones comunes compartidas por todos los componentes, cada tipo de adaptador tiene configuraciones específicas que controlan cómo se conecta a sistemas externos y procesa mensajes. Comprender estas configuraciones específicas de adaptador es esencial para configurar integraciones funcionales y solucionar problemas de conectividad.

Los adaptadores de archivo, usados para leer mensajes HL7 de archivos o escribir mensajes a archivos, tienen una configuración crítica llamada FilePath. A pesar del nombre sugiriendo una ruta de archivo, esta configuración realmente especifica una ruta de directorio. Para adaptadores de archivo entrantes (en Business Services), FilePath especifica el directorio donde el adaptador busca archivos para leer. Para adaptadores de archivo salientes (en Business Operations), FilePath especifica el directorio donde el adaptador escribe archivos. Note que en el examen, esta configuración podría llamarse incorrectamente "FileDirectory" - esté consciente de que el nombre de configuración correcto es "FilePath" aunque contiene una ruta de directorio.

Los adaptadores TCP se usan para mensajería HL7 en tiempo real, orientada a conexión. La configuración Port es crítica - especifica qué puerto TCP el adaptador escucha (para adaptadores entrantes en Business Services) o se conecta (para adaptadores salientes en Business Operations). Los adaptadores TCP también tienen configuraciones para timeout de conexión, timeout de lectura, y si mantener conexiones persistentes versus conectar para cada mensaje. Comprender estas configuraciones es importante para configurar interfaces HL7 confiables basadas en TCP.

Los adaptadores FTP habilitan transferencia de archivos remota para mensajes HL7. Las configuraciones clave incluyen la dirección del servidor FTP, credenciales para autenticación (frecuentemente referenciando una definición de credencial), la ruta de directorio en el servidor remoto, y parámetros de conexión como timeout y modo pasivo. Los adaptadores FTP pueden tanto recuperar archivos de servidores remotos (entrante) como enviar archivos a servidores remotos (saliente), con variaciones de configuración dependiendo de la dirección.

Los adaptadores HTTP y SOAP para integraciones de servicios web tienen sus propias configuraciones específicas incluyendo el endpoint URL, configuración SSL/TLS para conexiones seguras, credenciales para autenticación HTTP, y configuraciones de timeout para ciclos de solicitud/respuesta. Estos adaptadores son cada vez más comunes en integraciones de salud modernas a medida que los sistemas se mueven hacia APIs de servicios web en lugar de mensajería HL7 tradicional basada en archivos o TCP.

Los Business Services tienen varias configuraciones críticas más allá de las configuraciones comunes de componente y configuraciones de adaptador. TargetConfigNames especifica dónde el Business Service envía mensajes después de recibirlos. Esta configuración contiene el nombre de configuración de un Business Process o Business Operation en la producción. Sin esta configuración configurada, el Business Service recibe mensajes pero no los envía a ninguna parte, resultando en mensajes que parecen procesarse pero nunca alcanzan su destino.

Call Interval es una configuración específica de Business Service que controla frecuencia de polling. Especifica el número de segundos que el Business Service espera entre verificaciones de nuevos mensajes. Para adaptadores de archivo, esto es qué tan frecuentemente el adaptador escanea el directorio para nuevos archivos. Para adaptadores FTP, es qué tan frecuentemente el adaptador se conecta al servidor remoto para verificar archivos. Valores más bajos significan polling más frecuente y procesamiento de mensaje más rápido, pero mayor overhead del sistema. Valores más altos reducen carga del sistema pero aumentan latencia. Valores típicos van de 5 segundos a 60 segundos dependiendo de urgencia y volumen de mensaje.

Reply Code Actions, también encontrado en Business Operations y Business Processes, controla cómo el componente maneja diferentes tipos de respuestas de acknowledgment. Para Business Services que pueden retornar acknowledgments (como Business Services TCP, HTTP y SOAP), esta configuración determina qué tipo de ACK enviar y qué hacer al recibir diferentes tipos de respuestas. Esto se cubre en más detalle en el tema de funcionalidad ACK/NACK pero es importante reconocer como una configuración de Business Service.

Estas configuraciones de Business Service trabajan juntas para controlar flujo de mensaje a través de la producción. TargetConfigNames determina el destino, Call Interval controla el timing de recepción de mensaje, Message Schema Category habilita interpretación apropiada de mensaje y enrutamiento, y Reply Code Actions controla comportamiento de acknowledgment. Configuraciones de Business Service faltantes o mal configuradas son causas comunes de fallos de integración y temas frecuentes de examen.