Informática Sana: el blog de Caduceus

Solución caso práctico 1.3: la gestión de errores con múltiples sistemas

Sin comentarios

En el artículo anterior planteamos el problema de la gestión de errores en un escenario con múltiples sistemas.

En este artículo desarrollamos con detalle una posible solución a este problema, basada en Mirth Connect.


Este artículo es parte de la serie del Caso Práctico 1.


Para ello, utilizaremos las siguientes versiones para estándares, tecnologías y herramientas:

Material utilizado

De nuevo, para poder seguir mejor el artículo y probar los ejemplos, publicamos el material necesario:

Material caso práctico “La gestión de errores con múltiples sistemas”:

El material contiene las siguientes carpetas y ficheros:

  • 1.in-log:
    • log: fichero de log utilizado para probar el funcionamiento del caso práctico.
  • 2.mirth-connect:
    • INFORMATICA_SANA_1_3_1.xml: exportación del canal desarrollado para rastrear el fichero log, procesarlo y enviar los errores al servicio web de notificación de errores (para su importación en Mirth Connect).
    • INFORMATICA_SANA_1_3_2.xml: exportación del canal desarrollado para simular el servicio web de notificación de errores (para su importación en Mirth Connect).

Descargar “Material caso práctico 1.3 - La gestión de errores con múltiples sistemas” material-caso-practico-1.3.zip – Descargado 89 veces – 5 KB

Fichero de log

En primer lugar, vamos a ubicar el fichero de entrada log en la ruta C:\tmp\informaticasana\1\1.3, para poder leerlo desde Mirth Connect.

El contenido del fichero es el siguiente:

W,"2014-09-22 12:16:22",warning-1
W,"2014-09-22 12:16:23",warning-1
E,"2014-09-22 12:16:24",error-2
I,"2014-09-22 12:16:25",info-3
F,"2014-09-22 12:16:26",error-fatal-1

Destacamos dos errores que debemos mapear con los del catálogo y comunicar a NewModernHIS:

  1. error-2 de tipo ‘E’ (Error)
  2. error-fatal-1 de tipo ‘F’ (Fatal Error).

Implementación del canal que rastrea el fichero de log en Mirth Connect

Vamos a configurar el canal que lee el fichero de log, lo procesa, mapea los errores con los del catálogo, y realiza las llamadas correspondientes al servicio web.

Configuración global

La configuración del canal es la habitual que venimos usando para los canales polling (ver artículo sobre consejos útiles y buenas prácticas).

Vamos a utilizar el tipo de datos Delimited Text para el conector fuente, conforme al formato del fichero de log que queremos leer:

Mirth Connect: Configuración global del canal para la lectura del archivo de log

Mirth Connect: Configuración global del canal para la lectura del archivo de log

Conector Fuente

Para leer el fichero log, es necesario:

  1. Elegir un tipo de conector File Reader.
  2. Indicar el directorio donde se encuentra el fichero.
  3. Establecer la frecuencia de rastreo en Polling Type / Polling Frecuency (ms).

Para indicar que el fichero ya ha sido leído y no procesarlo de nuevo podemos renombrarlo y situarlo en un directorio old de ‘ficheros leídos’. Esto se puede llevar a cabo mediante las configuraciones Move-to Directory y Move-to File Name para moverlo y renombrarlo. El momento de la lectura se puede obtener mediante el uso de ${SYSTIME}:

Mirth Connect: Configuración del conector fuente para la lectura del archivo de log

Mirth Connect: Configuración del conector fuente para la lectura del archivo de log

Conector Destino

Para comunicarnos con el nuevo servicio web se puede definir un conector de tipo Web Service Sender, al igual que se hizo en el caso práctico anterior para la validación de la mensajería.

De nuevo, es posible cargar la mayor parte de la configuración automáticamente, indicando la URL del WSDL, y a través de los botones Get Operations y Generate Envelope.

Como contenido del mensaje SOAP, le indicamos la salida del propio conector a través de ${message.encodedData} dentro de <arg0>:

Mirth Connect: Configuración del conector destino comunicarse con un servicio web

Mirth Connect: Configuración del conector destino comunicarse con un servicio web

Transformador

Aquí se lleva a cabo el trabajo principal del canal: construir el XML con la información de los errores mapeados a partir de la información del fichero de log.

Para ello, se indicará:

  • El formato del fichero de log que leemos en el Inbound Message Template.
  • El XML que enviaremos al servicio web de notificación de errores en el Outbound Message Template.

Las transformaciones necesarias se pueden realizar en un único transformador de tipo Javascript. Sin entrar en detalles, en el código podemos observar cómo iteramos sobre las líneas del fichero y, para los casos que nos interesa notificar (‘E’ y ‘F’), se realiza una correspondencia con los errores del catálogo de NewModernHIS para añadirlos a la salida del conector:

Mirth Connect: Transformador para construir el XML con la información de los errores

Mirth Connect: Transformador para construir el XML con la información de los errores

Implementación del canal que simula el servicio web de notificación de errores en Mirth Connect

En el caso práctico anterior ya vimos cómo configurar un canal en Mirth Connect para simular un servicio web, por tanto en esta ocasión, no entraremos en los detalles.

Configuración global

Configuración habitual para el caso práctico:

Mirth Connect: Configuración global para el canal que simula el servicio web de notificación de errores

Mirth Connect: Configuración global para el canal que simula el servicio web de notificación de errores

Conector Fuente

Conector de tipo Web Service Listener, donde indicamos el nombre del servicio InformaticaSanaErrores. De nuevo, configuramos una respuesta propia custom_ack para el servicio web en Respond from:

Mirth Connect: Configuración del conector fuente de tipo Web Service Listener

Mirth Connect: Configuración del conector fuente de tipo Web Service Listener

Conector Destino

Conector de tipo Javascript Writer, donde construimos el XML de respuesta con el mensaje Error notificado correctamente, y lo almacenamos en custom_ack tal y como vimos en la configuración del conector fuente:

Mirth Connect: Configuración del conector destino de tipo Javascript Writer

Mirth Connect: Configuración del conector destino de tipo Javascript Writer

Despliegue de los canales

En este punto, nos encontramos en condiciones de habilitar los canales y desplegarlos a través de la opción Redeploy All:

Mirth Connect: Despliegue de los canales

Mirth Connect: Despliegue de los canales

Si todo ha ido bien hasta el momento, será posible ver los canales desplegados sin errores en el Dashboard:

Mirth Connect: Dashboard con los canales desplegados

Mirth Connect: Dashboard con los canales desplegados

Pruebas de funcionamiento de los canales en Mirth Connect

Dashboard

Para comenzar con las pruebas, iniciamos el canal de rastreo e, inmediatamente después, comprobamos que ambos canales reciben un único mensaje y lo envían correctamente:

Mirth Connect: Dashboard después de procesar el mensaje

Mirth Connect: Dashboard después de procesar el mensaje

Comprobación de la salida

Accediendo al directorio de ‘ficheros leídos’ C:\tmp\informaticasana\1\1.3\old, podemos comprobar que el fichero original ha sido movido y renombrado correctamente:

Mirth Connect: Fichero log procesado y renombrado

Mirth Connect: Fichero log procesado y renombrado

Traza de los conectores

Por último, realizamos algunas observaciones sobre las salidas generadas en los dos canales utilizados.

Canal que rastrea el fichero de log

En el Transformed Message del conector destino, podemos acceder a la salida del conector y comprobar el XML que se envía al servicio web de notificación de errores:

Mirth Connect: Canal que rastrea el fichero de log

Mirth Connect: Canal que rastrea el fichero de log

Canal que simula el servicio web de mensajería

En los Mappings del conector destino, por ejemplo, podemos acceder a la información del XML generado como respuesta del canal, y almacenado en la variable custom_ack:

Mirth Connect: Canal que simula el servicio web de mensajería

Mirth Connect: Canal que simula el servicio web de mensajería

Y con esto ponemos el punto final a nuestro primer caso práctico con Mirth Connect, una serie de 6 artículos en los que hemos abordado problemas típicos en las integraciones sanitarias como la validación de la mensajería o la gestión de errores. Todo ello tras la implantación de un nuevo HIS, y desde el punto de vista de una aplicación integrada en un sistema hospitalario.

En un futuro publicaremos más casos prácticos sobre Mirth Connect, ya sobre la nueva versión 3.x.

Recordamos que el material necesario para este caso puede descargarse desde aquí:  Material caso práctico 1.3 - La gestión de errores con múltiples sistemas (89 descargas)

Francisco J. CarrascoSolución caso práctico 1.3: la gestión de errores con múltiples sistemas

Entradas Relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *