Connecting eHealth blog

Solución ejercicio 3: la gestión de errores con múltiples sistemas

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 tutorial de Mirth Connect.


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 149 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.

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 (149 descargas)

Francisco J. CarrascoSolución ejercicio 3: la gestión de errores con múltiples sistemas

Deja un comentario

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

Resumen de la Política de Privacidad

Responsable: Caduceus Software S.L.
Finalidad: Atender tu solicitud de publicar un comentario en este artículo. Además, si marcas "Recibir nuevos artículos por correo electrónico", suscribirte a nuestra lista de correo, .
Legitimación: Para poder publicar el comentario a tu nombre necesitamos tu nombre, email, web (opcional). Para evitar spam, tus datos personales y otra información técnica pueden ser enviados a un sistema automático de reconocimiento de spam (Akismet). Para suscribirte a nuestra lista de correo necesitamos tu correo electrónico.
Destinatarios: Tus datos para el comentario no se compartirán ni se cederán a terceros. Si marcas "Recibir nuevos artículos por correo electrónico", añadiremos tu dirección de correo y tu nombre a nuestra lista en MailChimp, una compañía estadounidense que cumple y respeta la privacidad de datos. Podrás darte de baja en cualquier momento.
Derechos: Puedes ejercer tus derechos escribiendo a info@caduceus.es o en nuestro formulario de contacto (https://www.caduceus.es/contacto/).

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.