Cómo probar un servicio web HL7 con SoapUI en 5 pasos

Mostramos de forma práctica cómo crear una baterías de tests para probar un servicio web SOAP que contiene mensajes HL7 utilizando SoapUI.

En el primer ejercicio del tutorial de NextGen (Mirth) Connect hemos utilizado SoapUI para comprobar el funcionamiento de nuestros servicios web, pero sin entrar en el campo del testeo de este tipo de aplicaciones.

Material utilizado

Para probar un servicio web que contenga mensajes HL7 con SoapUI, lo primero que necesitamos es desplegar un servicio web de estas características.

El ejercicio 2 del tutorial de NextGen (Mirth) Connect explicamos como desplegar un servicio web SOAP desarrollado para la validación de mensajes HL7. Si tienes interés en NextGen (Mirth) Connect puede ser recomendable hacer hacer ese ejercicio antes de este tutorial.

En cualquier caso, es posible descargar el material para seguir el artículo:

En la página de SoapUI puedes:

• Descargar la versión más reciente de SoaupUI Open Source.
• Descargar versiones anteriores de SoapUI Open Source.

Para este tutorial se ha usado SoapUI Open Source 5.0.0.

Si quieres saber más sobre HL7, puedes visitar nuestro artículo sobre el estándar HL7.

¿Cómo probamos un servicio web HL7 con SoapUI?

Vamos a configurar una batería de pruebas sencilla para el servicio web de validación de la mensajería HL7 utilizando SoapUI.

Para ello, partiremos del proyecto en SoapUI soapui-project.xml, que ya contiene dos peticiones con mensajes HL7, uno que cumple el proceso de validación y otro que no lo cumple:

Mensaje HL7 que cumple la validación:

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28-ok|T|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Mensaje HL7 que no cumple la validación:

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28-no-ok|K|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

La batería de pruebas de SoapUI tendrá los asertos adecuados para comprobar que los mensaje HL7 que deben pasar la validación, la pasan, y que los mensajes que no deben pasar la validación, fallan.

Finalmente, realizaremos un cambio en el servicio web para que se comporte de forma diferente y la batería de pruebas falle.

Creación de la batería de tests para el servicio web HL7 con SoapUI

Una batería de pruebas (TestSuite) es una estructura jerárquica. Un TestSuite se divide en diferentes TestCase, que, a su vez, agrupan un conjunto de pruebas unitarias llamadas TestStep.

Todos estos elementos se podrán ejecutar de forma independiente, por lo que es conveniente estructurar muy bien todas nuestras pruebas.

1. Configuración de la batería de pruebas

Para crear una nueva batería de pruebas, hacemos clic con el botón derecho del ratón sobre el proyecto y elegimos la opción New TestSuite:

Posteriormente, debemos elegir el nombre del TestSuite:

Entonces nos aparecerá en el árbol del proyecto.

2. Creación de TestCases

Para crear un nuevo TestCase, podemos hacer clic sobre el botón derecho del ratón sobre el TestSuite recién creado y elegir la opción New TestCase:

De nuevo, especificamos el nombre para el nuevo elemento. En este caso, es recomendable especificar un nombre representativo del tipo de pruebas unitarias que contendrá. Ponemos «Validación de la mensajería HL7» en la ventana new TestCase de SoapUI.

3. Creación de los TestSteps

Finalmente, debemos crear los TestStep. El procedimiento es similar a los anteriores, podemos hacer clic con el botón derecho del ratón sobre el TestCase, y elegir la opción “Add Step → Test Request”:

De nuevo, debemos especificar el nombre del elemento:

Y en este caso, el tipo de operación que queremos probar:

Finalmente, es posible incorporar algunas validaciones más si queremos:

4. Especificación de asertos

Ya tenemos nuestro primer TestCase para probar el servicio web de HL7 creado en SoapUI. Tras copiar en el área de texto el mensaje que queremos enviar (mismo contenido que tenemos en el Request1), debemos especificar los asertos.

Por defecto, y tal como se muestra en la última configuración del TestCase, ya nos incorpora una validación para comprobar que la respuesta obtenida cumple con el protocolo SOAP:

Hacemos clic sobre el icono “+” para incorporar un nuevo aserto de tipo Contains, que validará que la respuesta del servicio web contiene cierta información que se espera:

Como esta prueba contiene un mensaje HL7 válido, el contenido del campo HL7 MSA.1 de la respuesta debe tener el valor AA. Eso mismo indicamos en el contenido a validar en el aserto:

En este punto, ya tenemos completamente configurado nuestro primer TestCase.

De la misma forma, podemos crear un nuevo TestCase llamado Mensaje Inválido donde vamos a copiar el contenido del Request2 con un mensaje que no debe pasar la validación del servicio web. Para no sobrecargar demasiado más el artículo, omitiremos las capturas de pantalla de este proceso.

Para este TestCase también debemos añadir nuestros propios asertos. En primer lugar, para comprobar que el mensaje HL7 no es válido:

Y luego para validar por qué no:

5. Ejecutar el TestCase

En este punto, y con el servicio web de validación de mensajería HL7 desplegado a través de NextGen (Mirth) Connect, ya podemos lanzar nuestro TestCase en SoaupUI, haciendo clic sobre el icono del “play verde”.

El resultado nos muestra que el servicio web se ha comportado como esperábamos:

Si realizamos un cambio en el servicio web que hace que uno de los asertos falle (por ejemplo, omitiendo el segmento HL7 ERR con la especificación del error en la validación), al ejecutar de nuevo el TestCase en SoapUI, obtendremos un resultado no válido:

Conclusiones

Aquí concluye este artículo en el que hemos configurado una pequeña batería de pruebas para un servicio web de validación de mensajería HL7 utilizando SoapUI.

Esto puede darnos una idea de la facilidad de uso, flexibilidad y potencia de SoapUI, que por algo es una de las más utilizadas en el testeo y validación de servicios web.