manual de usuario del arquetipo webservice

ATLAS
MANUAL DE USUARIO DEL
ARQUETIPO WEBSERVICE
Versión 1.10
Área de Aplicaciones Especiales y Arquitectura de
Software
Framework Atlas
Arquetipo WebService
Hoja de Control
Título
Manual de usuario del Arquetipo WebService
Documento de Referencia
NORMATIVA ATLAS
Responsable
Área de Aplicaciones Especiales y Arquitectura de Software
Versión
1.10
Fecha Versión
30/04/2014
Registro de Cambios
Versión
Causa del Cambio
1.0
Versión inicial del documento
Responsable del Cambio
Área de Integración y Arquitectura de
Aplicaciones
Fecha del Cambio
25/05/2010
- Nueva configuración de Arquetipo
Web Service
1.1
- Incluida creación previa del arquetipo
de proyecto
Área de Integración y Arquitectura de
Aplicaciones
16/09/2010
- Nueva nomenclatura de paquetes
1.2
- Modificaciones para versión 1.1.0 de
Área de Integración y Arquitectura de
ATLAS
Aplicaciones
16/02/2011
- Las preguntas frecuentes se
1.3
consultarán en el portal de
Área de Aplicaciones Especiales y
arquitectura.
Arquitectura de Software
05/07/2011
Se modificad el nombre del área
- Nueva arquitectura modular de
1.4
1.5
arquetipo de servicio web
Área de Aplicaciones Especiales y
Arquitectura de Software
- Nuevo módulo test con proyectos de
Área de Aplicaciones Especiales y
SoapUI 4.0.1
Arquitectura de Software
18/10/2011
21/11/2011
- Se añaden las clases BaseService y
BaseServiceImpl, así como los
1.6
servicios y DAOs para EstadoCivil
Área de Aplicaciones Especiales y
- Se añade a la estructura del módulo
Arquitectura de Software
web la carpeta “generador”.
- Se añaden las clases de test
2 de 41
24/02/2012
Framework Atlas
Arquetipo WebService
Versión
Causa del Cambio
Responsable del Cambio
Fecha del Cambio
agrupadas por servicio
Se elimina las clases para la fachada
ya que en los servicios web no tiene
1.7
sentido. Internamente se ha modificado Área de Aplicaciones Especiales y
la versión de axis por lo tanto esta
Arquitectura de Software
29/10/2012
versión del arquetipo utilizada esta
nueva versión.
Revisión completa del documento por
1.8
nueva estructura de arquetipo en
ATLAS 1.2.3
Se actualiza el apartado 3 para quitar
1.9
referencias a la herramienta de
validación
1.10
Área de Aplicaciones Especiales y
Arquitectura de Software
Área de Aplicaciones Especiales y
Arquitectura de Software
- Se modifica jetty por tomcat7 como
Área de Aplicaciones Especiales y
servidor de aplicaciones
Arquitectura de Software
3 de 41
27/02/2013
12/03/2014
18/07/2014
Framework Atlas
Arquetipo WebService
Índice
1
2
INTRODUCCIÓN ................................................................................................................................................................ 6
1.1
AUDIENCIA OBJETIVO .............................................................................................................................................. 6
1.2
CONOCIMIENTOS PREVIOS ...................................................................................................................................... 6
INFORMACIÓN SOBRE EL ARQUETIPO ..................................................................................................................... 8
2.1
CREACIÓN DE UNA APLICACIÓN PARTIENDO DEL ARQUETIPO .......................................................................................... 8
2.2
ESTRUCTURA DEL ARQUETIPO ....................................................................................................................................... 12
2.3
ESTRUCTURA DE DIRECTORIOS Y ARCHIVOS .................................................................................................................. 12
2.3.1
ESTRUCTURA DEL MÓDULO WEB ............................................................................................................................... 13
2.3.2
ESTRUCTURA DEL MÓDULO LIB ................................................................................................................................. 16
2.3.3
ESTRUCTURA DEL MÓDULO TEST .............................................................................................................................. 18
2.4
3.
CONFIGURACIÓN DEL DESCRIPTOR DE SERVICIOS SERVICES.XML .................................................................................. 19
1.2.1.
Configuración básica ............................................................................................................................................ 20
1.2.2.
Configuración para seguridad .............................................................................................................................. 20
2.5
DESPLIEGUE Y EJECUCIÓN DE LA APLICACIÓN ............................................................................................................... 21
2.6
EJECUCION TEST ...................................................................................................................................................... 22
2.6.1
EJECUCIÓN DE TEST UNITARIOS ................................................................................................................................. 22
2.6.2
EJECUCIÓN DE LOS TESTS DE SOAPUI ........................................................................................................................ 22
PRUEBAS FUNCIONALES CON SOAPUI. ................................................................................................................... 26
3.2.
GLOSARIO DE TÉRMINOS. ............................................................................................................................................... 26
3.3.
PANEL DE NAVEGACIÓN. ............................................................................................................................................... 26
3.4.
TESTCASES. ................................................................................................................................................................... 26
3.4.1.
Acciones de los TestCases. .................................................................................................................................... 26
3.4.2.
Crear un TestCase desde una Petición. ................................................................................................................ 27
3.4.3.
Ejecutar TestCase. ................................................................................................................................................ 30
3.5.
ASERCIONES. ................................................................................................................................................................. 30
3.5.1.
Gestión de Aserciones. .......................................................................................................................................... 31
3.5.2.
Categorías de aserción. ........................................................................................................................................ 32
3.5.3.
Aserciones comunes. ............................................................................................................................................. 34
3.5.4.
Añadir Aserciones en TestCase. ............................................................................................................................ 34
3.5.5.
Aserciones con XPath Match. ............................................................................................................................... 35
3.5.6.
Ejemplos de Aserciones XPath Match: ................................................................................................................. 35
3.6.
TEST SUITE. ................................................................................................................................................................... 37
3.6.1.
Acciones del TestSuite. .......................................................................................................................................... 37
3.6.2.
Crear TestSuite. .................................................................................................................................................... 37
4 de 41
Framework Atlas
Arquetipo WebService
3.6.3.
Ejecutar TestSuite. ................................................................................................................................................ 39
4
PREGUNTAS MAS FRECUENTES ................................................................................................................................ 40
5
ENLACES RELACIONADOS .......................................................................................................................................... 40
5 de 41
Framework Atlas
Arquetipo WebService
1
INTRODUCCIÓN
Los arquetipos son las plantillas para la generación de los distintos proyectos dentro del Framework Atlas. Estos
arquetipos utilizan el plugin archetype de maven para generar la estructura de ficheros y directorios necesarios
para nuestro proyecto, gestionando las librerías que le indiquemos así como las dependencias. Todas las librerías
serán incluidas durante el empaquetado del proyecto, por lo que para generar y compilar un arquetipo debe estar
conectado al repositorio de artefactos de la Comunidad de Madrid (Artifactory). El framework Atlas consta de los
siguientes arquetipos:
-
Arquetipo para inicio de proyecto
-
Arquetipo para módulos de tipo web
-
Arquetipo para módulos de tipo jar.
-
Arquetipo para módulos de tipo webservice o servicios web
-
Arquetipo para módulos de tipo batch
-
Arquetipo para módulos de gestión documental (documentum)
El Arquetipo WebService genera un proyecto modular con un módulo maven de tipo war para el servicio web listo
para ser desplegado, y un módulo de tipo jar para el cliente de dicho servicio. Está preparado para publicar un
servicio de Spring a través de Axis2 sin generación de código intermedio. El proyecto viene preconfigurado para
acceder a base de datos a través de Hibernate y publica como webservices una serie de servicios de ejemplo.
Se incluye un ejemplo de servicio sin seguridad, otro seguro a nivel de transporte y otro securizado con webservice
security. Para más información sobre estos tipos de seguridad consultar el manual ATLAS_MUS_Servicios_Web.
1.1
AUDIENCIA OBJETIVO
Este documento está dirigido a desarrolladores de proyectos java para ICM en los que se desee crear una
aplicación que publique un Servicio Web utilizando el framework de desarrollo Atlas.
1.2
CONOCIMIENTOS PREVIOS
Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes
tecnologías:
-
Java
-
Eclipse
-
Maven
-
Spring Framework.
-
Axis2 y SoapUI
6 de 41
Framework Atlas
Arquetipo WebService
Además, es necesario haber leído y seguido los pasos del manual
ATLAS_MUS_Preparacion_Entorno_Desarrollo para tener el entorno de desarrollo preparado.
7 de 41
Framework Atlas
Arquetipo WebService
2
2.1
INFORMACIÓN SOBRE EL ARQUETIPO
Creación de una aplicación partiendo del arquetipo
NOTA IMPORTANTE
Antes de generar un arquetipo es IMPRESCINDIBLE haber generado un arquetipo para
albergar el proyecto (consultar “ATLAS_MUS_Preparacion_Entorno_Desarrollo” para ver
cómo crear un arquetipo de proyecto). Cualquier arquetipo posterior será incluido como un
módulo de éste.
Crear un proyecto de Servicios Web a partir de un arquetipo es similar a la creación de un proyecto Web,
modificando el nombre del arquetipo a utilizar.
Para crear un proyecto a partir de un arquetipo maven puede consultar la guía paso a paso que se indica en el
documento ATLAS_MUS_Preparacion_Entorno_Desarrollo, según se indica en el apartado “Creación de una
aplicación Web desde cero”, sustituyendo “atlas-arquetipos-generador-web” por “atlas-arquetiposgenerador-servicioweb”.
8 de 41
Framework Atlas
Arquetipo WebService
A continuación se nos mostrará una pantalla para indicar cuáles son los parámetros con los que vamos a crear
nuestro proyecto.
9 de 41
Framework Atlas
Arquetipo WebService
ATENCION – NOMENCLATURA
Es muy importante utilizar en esta
pantalla los valores que cumplan la
normativa de Atlas:
groupId:
Nombre
del
proyecto.
Normalmente es de 4 caracteres y es
un código que se le da a un proyecto.
Todos los módulos de un proyecto
tendrán
el
mismo
corresponderá
con
groupId
el
y
se
nombre
del
proyecto.
artifactId: Nombre del módulo. (En el
caso de servicios web el nombre del
módulo
será:
xxxx_ws_yyyy
donde
xxxx se corresponde con el groupId
indicado y yyyy el texto que identifique
a este modulo y lo diferencie de otros:
Ejemplo: ejpl_ws_acceso.
El carácter de separación a utilizar
debe ser el guión bajo.
Version: La primera versión será 1.0.0
package: El nombre del paquete java
será el groupId, seguido de un punto y
el nombre del bloque funcional dentro
de la aplicación (para aplicaciones
grandes se crearán varios bloques
funcionales).
Todos
los
minúsculas.
Al pulsar Finish se crea el nuevo proyecto.
10 de 41
nombres
deben
ir
en
Framework Atlas
Arquetipo WebService
ATENCION
Las clases que se incluyen de ejemplo son simplemente eso y deben ser
eliminadas del proyecto cuando no se necesiten.
Antes de comenzar a visualizar la estructura del nuevo proyecto generado, debemos realizar un ajuste en el fichero
pom.xml del nuevo proyecto creado. Para ello, debemos abrir el fichero “web\pom.xml”, “lib\pom.xml” y
“test\pom.xml”, eliminar la sección <parent> existente y descomentar la sección <parent> que aparece
comentada.
Antes de eliminar:
Después de eliminar:
11 de 41
Framework Atlas
Arquetipo WebService
Una vez configurado el proyecto general y el subproyecto (módulo de tipo aplicación servicioweb), ya podemos
seguir viendo la estructura del subproyecto para la aplicación que acabamos de generar.
2.2
Estructura del arquetipo
Este arquetipo genera un proyecto maven multimodular con un proyecto padre cuyo pom llevará la configuración
general del resto de subproyectos. El proyecto consta de tres módulos:
Lib: Módulo de tipo jar donde se implementa el cliente del servicio web. Aquí se crearán las
interfaces de servicio y los objetos de datos de intercambio. Es además, una dependencia del
proyecto Web ya que el webservice implementado tendrá necesariamente que hacer uso de los
objetos definidos en este módulo.
Web: Módulo de tipo war, configurado para utilizar Spring, Hibernate, Axis2 y seguridad, y
preparado para desplegar el servicio web en un servidor de aplicaciones. Aquí se creará la
implementación del servicio web.
Test: Módulo con proyectos de SoapUI preparados para realizar pruebas de llamada sobre el
servicio web. Contiene un proyecto SoapUI para cada uno de los ejemplos de servicio incluidos.
Este módulo no generará ningún producto empaquetado como los otros dos módulos (paquete war
el módulo web y paquete jar el módulo lib).
2.3
Estructura de directorios y archivos
12 de 41
Framework Atlas
Arquetipo WebService
Una vez generado el proyecto se generan una serie de directorios a estilo maven, donde ubicaremos los fuentes y
recursos de las partes de java, test y aplicación.
A continuación se describe la estructura de cada uno de los dos módulos del proyecto.
2.3.1
Estructura del Módulo web
El módulo web tiene la siguiente estructura de directorios y ficheros:
Fichero de configuración de Maven del proyecto
De esta ruta cuelga la estructura de paquetes con el código fuente del
proyecto. El paquete raíz va a llamarse igual que el nombre del módulo que
se está desarrollando.
Inicialmente el paquete raíz se llamará con el código de proyecto
(equivalente al groupId).
Adicionalmente, en el subpaquete „services‟ residirán las implementaciones
de los servicios web a publicar.
En los ejemplos inferiores se ha tomado como paquete raíz „ejpl‟.
Implementación del servicio web.
Las interfaces del servicio web
deben crearse en el módulo lib.
Ruta donde se generarán los recursos del proyecto, normalmente son
ficheros de configuración y ficheros de propiedades. En nuestro caso
contiene los siguientes ficheros:
Fichero de propiedades que contiene
todas las variables de configuración
cuyo valor puede ser diferente en
distintos entornos de ejecución
(local, desarrollo, producción, etc.).
Antes de desplegar un proyecto en los
entornos de ICM, este fichero será
sustituido
por
su
homólogo
correspondiente al entorno en el que
13 de 41
Framework Atlas
Arquetipo WebService
se vaya a desplegar.
Fichero de configuración de log4j;
lleva además configuración de los
módulos de trazas y monitorización.
Fichero de propiedades que contiene
mediante clave y valor todos los
valores particulares de la aplicación
que no son susceptibles de ser
modificados
o
configurados
entre
diferentes entornos de ejecución.
Fichero de configuración de Spring
para la carga en el contexto de Spring
de todos los DAOs (clases de acceso
a datos).
Fichero de configuración de Spring
que
lleva
dataSource,
la
configuración
sessionManager
transactionManager
que
del
y
integra
Hibernate con Spring. Inicialmente el
datasource
será
configurado
mediante las propiedades ubicadas en
el fichero conf/jdbc.properties (se
generan de forma automática con
maven) aunque para
el paso a
integración
configurarse
deben
localizando por jndi al datasource del
servidor de aplicaciones.
Fichero de configuración de Spring
para la carga de las propiedades
ubicadas en application.properties y
resto de archivos de propiedades
necesarios.
Fichero de configuración de Spring
para la carga de todas las clases de
14 de 41
Framework Atlas
Arquetipo WebService
Servicios.
Ruta donde se generarán el código fuente para los test de nuestro proyecto.
Este código nunca deberá estar incluido en el jar final.
Paquete
para
los
tests
unitarios. En el módulo web no
hay tests implementados por
defecto.
Ruta donde se generarán los recursos para realizar las pruebas de test,
normalmente son ficheros de configuración y ficheros de propiedades. En
nuestro caso contiene los siguientes ficheros:
Ficheros de configuración por si
se desea acceder a la aplicación
por ssl
Lleva
la
configuración
del
dataSource, sessionManager y
transactionManager que integra
Hibernate
con
Spring.
Este
fichero es un espejo del fichero
conf/applicationContextdatabase.xml excepto que en
ningún caso debe localizar el
datasource por JNDI del servidor
de aplicaciones, puesto que en
la fase de test no tenemos
acceso a dicho servidor.
Ruta donde se generarán los recursos necesarios para la parte web de la
aplicación.
Fichero de acceso principal que redirige al
listado de servicios del web service.
Página de entrada que muestra un listado
de
servicios
y
documentos WSDL.
15 de 41
un
enlace
a
sus
Framework Atlas
Arquetipo WebService
Descriptor de despliegue
de servicios de Axis2.
Descriptor
web
de
la
aplicación
Descriptor adicional para
el servidor de aplicaciones Weblogic.
Descriptores
adicionales
para
el
servidor
de
aplicaciones Jetty.
OBSOLETO: A partir de Atlas 1.2.7 se
ejecuta tomcat7 en local
Ficheros de configuración de tomcat7
para su ejecución en local y en los
tomcats de ICM
Directorio para herramienta de generación
automática de código.
2.3.2
Estructura del Módulo lib
El módulo lib tiene la siguiente estructura de directorios y ficheros:
Fichero de configuración de maven
del módulo lib. Normalmente las
dependencias no se incluyen en este
fichero, sino en el fichero pom.xml
del proyecto padre.
De esta ruta cuelga la estructura de paquetes con el código fuente del proyecto
cliente. El paquete raíz va a llamarse igual que el nombre del módulo que se está
desarrollando.
Inicialmente el paquete raíz se llamará con el código de proyecto (equivalente al
groupId).
16 de 41
Framework Atlas
Arquetipo WebService
Adicionalmente, para cada bloque funcional de nuestra aplicación debe crearse
un subpaquete.
Entidades de entrada/salida del API
del webservice
Interfaces de los servicios web que
serán publicados.
Implementaciones de cliente de las
interfaces de los servicios web.
Ruta donde se generarán los recursos del proyecto, normalmente son ficheros de
configuración y ficheros de propiedades. En nuestro caso contiene los siguientes
ficheros:
Fichero de configuración de los
servicios de cliente publicados.
Ficheros de política de seguridad
a aplicar si el servicio web es
seguro
Ruta donde se generarán el código fuente para los test de nuestro proyecto. Este
código nunca deberá estar incluido en el jar final.
Tests unitarios para comprobar la
correcta implementación de los
clientes del servicio web.
Ruta donde se generarán los recursos para realizar las pruebas de test,
normalmente son ficheros de configuración y ficheros de propiedades. En nuestro
caso contiene los siguientes ficheros:
Fichero
de
propiedades
que
contiene mediante clave y valor
17 de 41
Framework Atlas
Arquetipo WebService
todos los valores susceptibles de
ser
modificados
entre
diferentes
o
configurados
entornos
de
ejecución. Este fichero solamente
es para la ejecución de los test.
Fichero de configuración de log4j;
lleva además configuración de los
módulos de trazas y monitorización.
Contiene la configuración básica de
un bean de Spring de ejemplo para
ejecutar el test de JUnit que viene
preconfigurado.
Fichero
de
propiedades
que
contiene mediante clave y valor
todos los valores particulares de la
aplicación que no son susceptibles
de ser modificados o configurados
entre
diferentes
entornos
de
ejecución.
Directorios de uso interno de ICM
para
la
configuración
de
la
aplicación en los distintos entornos.
Los ficheros environment.properties
de estos directorios solamente se
utilizan para la ejecución de los test
(la librería es independiente del
entorno).
Si se incluye una nueva variable en
src/main/resources/environment.pro
perties se ha de incluir también en
todos estos.
2.3.3
Estructura del Módulo test
18 de 41
Framework Atlas
Arquetipo WebService
El módulo test tiene la siguiente estructura de directorios y ficheros:
Fichero de configuración de maven
del módulo test. Normalmente las
dependencias no se incluyen en este
fichero, sino en el fichero pom.xml
del proyecto padre.
De esta ruta cuelga la estructura de paquetes con el código fuente. En este
módulo no se incluye código fuente.
.
Ruta donde se generarán los recursos del proyecto. En nuestro caso contiene los
siguientes ficheros:
Proyectos
SoapUI
para
los
servicios de ejemplo.
Almacenes de certificados para
las pruebas con SoapUI.
Descriptores del ejemplo de
servicio web.
Ruta donde se generarán el código fuente para los test de nuestro proyecto. Este
módulo no tiene código java de tests unitarios.
Ruta donde se generarán los recursos para realizar las pruebas de test,
normalmente son ficheros de configuración y ficheros de propiedades. Este
módulo no tiene recursos para los tests java:
2.4
Configuración del descriptor de servicios services.xml
Toda la configuración que se muestra a continuación se realiza según marca la documentación de Axis2, por lo que
para cualquier consulta adicional puede consultarlo en la web
http://axis.apache.org/axis2/java/core/docs/axis2config.html.
19 de 41
Framework Atlas
Arquetipo WebService
1.2.1.
Configuración básica
El arquetipo genera el fichero services.xml en el módulo web con una configuración válida que despliega un bean
del contexto de Spring como WebService. Si necesitamos editar dicho fichero lo podremos hacer de la siguiente
manera:
service: etiqueta que especifica un servicio, podemos publicar tantos servicios como deseemos siempre
que tengan un nombre diferente (parámetro name). Inicialmente se pone como nombre de servicio el
nombre de la aplicación.
ServiceObjectSupplier: especifica que clase nos proporciona los objetos que vamos a publicar, en
nuestro caso Spring. Este parámetro no se debe modificar.
SpringBeanName: Nombre del bean que vamos a publicar ubicado en el contexto de Spring
(applicationContext-services.xml).
ServiceClass: Interfaz de la clase que se va a publicar. Se debe especificar la interfaz del servicio que
queremos publicar para que Axis2 sepa como generar el WSDL correspondiente, de lo contrario podemos
tener problemas por que las clases estén interceptadas por Spring-AOP y esto falsee su interfaz en
ejecución. Esta clase debe crearse en el módulo cliente lib aunque se referencie en este módulo.
A continuación se muestra un ejemplo de configuración del fichero services.xml del módulo web que publica un
servicio.
Services.xml
<?xml version="1.0" encoding="UTF-8"?>
<serviceGroup>
<service name="EjemploService">
<parameter name="ServiceObjectSupplier">
org.apache.axis2.[...].SpringServletContextObjectSupplier</parameter>
<parameter name="SpringBeanName">EjemploService</parameter>
<parameter name="ServiceClass">ejpl.webservice.services.EjemploService</parameter>
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver" />
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver" />
</messageReceivers>
</service>
<!-- añadir aquí mas servicios si se desea <service name="nuevoServicio"> ... </service> -->
</serviceGroup>
1.2.2.
Configuración para seguridad
20 de 41
Framework Atlas
Arquetipo WebService
Para obtener información más detallada de la aplicación de seguridad en el servicio web, así como del contenido y
operativa de los módulos, debe consultarse el documento ATLAS_MUS_Servicios_Web.doc.
2.5
Despliegue y Ejecución de la aplicación
El arquetipo WebService es una aplicación web preparada para la publicación de alguno de sus servicios
mapeados en Spring como servicio web Axis2.
Para construir el proyecto debe ejecutarse el siguiente comando desde el POM padre del proyecto generado:
mvn clean install
Por defecto, al ejecutar Maven con los parámetros “clean install” se genera el paquete jar correspondiente al
cliente del servicio web y el war correspondiente a la aplicación web que contiene este. Para desplegar el war en
nuestro servidor de aplicaciones podemos coger el fichero de la carpeta en la que se ha generado
(web/target/nombreFichero.war), o podemos utilizar un servidor Tomcat7 local que viene preconfigurado en el
arquetipo. Para ejecutar directamente un servidor tomcat7 con nuestro proyecto desplegado, debemos ejecutar la
siguiente línea de comandos desde el directorio web de nuestro proyecto la siguiente línea de comandos:
mvn tomcat7:run
Esto arranca un servidor tomcat7 en el puerto 9080 de nuestra máquina, en el que se encuentra desplegado el war
de nuestra aplicación. Introduciendo la siguiente URL en un navegador se podrá ver un listado de los servicios
desplegados. Esta URL solo es válida para el servidor Tomcat7 local.
http://localhost:9080/services/listServices
En el caso de los ejemplos securidados el acceso es por
https://localhost:9443/services/listServices
Para la ejecución de los tests JMeter, desde el módulo test:
mvn clean install –Pjmeter
Para la generación y despliegue de los artefactos adicionales con los javadocs y el código fuente del proyecto:
mvn clean install –Dadditional_artifacts=true
21 de 41
Framework Atlas
Arquetipo WebService
Para probar la ejecución de este arquetipo puede comprobar en la URL donde se listan los servicios desplegados y
sus documentos WSDL:
http://<host>:<puerto>/<contexto>/services/listServices
2.6
2.6.1
EJECUCION TEST
Ejecución de test unitarios
Los test unitarios se encuentran en el módulo lib en la carpeta src/test/java/xxxx/client. Antes de ejecutarlos es
necesario editarlos y quitar o comentar la anotación @Ignore ya que de lo contrario no se van a ejecutar. Esta
etiqueta se ha incluido por que si se compila ejecutando los test y no está levantado el servidor de aplicaciones con
el servicio web lo test no van a funcionar.
Para comprobar la correcta implementación de la comunicación entre cliente y servidor, con el servidor del servicio
web arrancado, se deberá ejecutar la siguiente sentencia desde el directorio lib del proyecto:
mvn test
También se pueden ejecutar cada test de Junit desde el propio Eclipse como se ejecuta cualquier clase de tipo
Junit.
2.6.2
Ejecución de los tests de SoapUI
SoapUI es una aplicación para realizar llamadas a servicios web. Esta aplicación es utilizada normalmente para
comprobar la correcta ejecución de los servicios web. Los proyectos de prueba incluidos en el módulo de test se
han generado con la versión 4.0.1 de SoapUI. Esta aplicación puede ser descargada desde el siguiente enlace:
http://sourceforge.net/projects/soapui/files/soapui/4.0.1/
Para realizar una prueba de llamada al servicio web, primero debe levantarse el servidor tomcat7 tal y como se
especifica en el apartado anterior. A continuación ejecutar SoapUI.
22 de 41
Framework Atlas
Arquetipo WebService
Pulsar en el segundo icono y cargar el fichero del módulo test EjemploService-soapui-project.xml.
Una vez cargado el proyecto, desplegar el elemento EjemploServiceSoap12Binding (también puede probarse el
Soap11Binding) y el método alterar. Hacer doble click en Request 1. Con esto tendremos desplegado un XML de
petición al servicio web.
23 de 41
Framework Atlas
Arquetipo WebService
Para ejecutar esta petición hay que pulsar el icono
. Con esto se enviará la petición al servicio y se presentará
la respuesta.
24 de 41
Framework Atlas
Arquetipo WebService
Para comprobar cualquier otro método de este proyecto o del proyecto de cliente seguro debe seguirse el mismo
procedimiento.
25 de 41
Framework Atlas
Arquetipo WebService
3. Pruebas Funcionales con SoapUI.
En SoapUI, las pruebas funcionales se pueden usar para validar requisitos funcionales, tanto para invocar los
Servicios Web propios (“Pruebas unitarias”) como para una secuencia de peticiones (“pruebas de integración”),
Además, es posible añadir lógica a las pruebas mediante scripts de Groovy, lo que permite, por ejemplo,
interactuar con una base de datos o realizar un flujo de pruebas complejo.
3.2.
Glosario de términos.
TestCase: Caso de prueba funcional de Servicio Web.
TestSuite: Contenedor de casos de pruebas (TestCases).
TestStep: Paso que puede definirse en un “caso de uso”, pueden ser, peticiones http, peticiones Soap o
Script de groovy.
Aserciones: Condiciones que se evalúan tras obtener la respuesta de un petición.
3.3.
Panel de Navegación.
El panel de navegación está conformado por los siguientes componentes: (Ver imagen)
1 Panel de Navegación
ATENCION
Antes de realizar los siguiente pasos, se debe tener previamente importado los proyectos SoapUI
que se encuentran en {proyecto}/test/src/main/java/resources/soapui/
3.4.
TestCases.
Un TestCase en SoapUI, permite realizar pruebas funcionales de Servicios Web suministrando un numero de
pasos (Prueba de Casos de Usos) que pueden ser ejecutados en secuencia.
3.4.1.
Acciones de los TestCases.
Las siguientes acciones están Disponibles desde el menú que aparece al hacer clic derecho en el nodo del
TestCase.
26 de 41
Framework Atlas
Arquetipo WebService
2 Acciones de TestCase
Show TestCase Editor: Abre el editor del TestCase.
Disable/Enable TestCase: Opción que deshabilita/habilita el TestCase.
Options: Muestra la ventana de opciones del TestCase.
Add Step: añade un TestStep al TestCase.
New LoadTest: Opción que abre una ventana para crear una nueva prueba de carga para el TestCase.
Clone TestCase: Opción que permite clonar todo el TestCase, opcionalmente en otro TestSuite.
Clear: Muestra una ventana para eliminar todos los TestSteps del TestCase.
Rename: Opción que permite renombrar el TestCase.
Remove: Opción que permite eliminar el TestCase de su TestSuite.
Launch Runner: Opción que abre cuadro de diálogo para el lanzador del TestCase.
Move TestCase Up: Opción que mueve el actual TestCase hacia arriba en la lista de los TestCase.
Move TestCase Down: Opción que mueve el actual TestCase hacia abajo en la lista de los TestCase.
Online Help: Opción que abre la página de ayuda online en el navegador.
3.4.2.
Crear un TestCase desde una Petición.
Una vez tengamos algunas peticiones configuradas, podremos realizar un Caso de Prueba que verifique su
comportamiento.
Sobre una petición, presione el botón derecho del ratón y seleccione la opción “Add to TestCase”
27 de 41
Framework Atlas
Arquetipo WebService
3 Agregar Caso de Prueba
Aparecerá el listado de Casos de Pruebas previamente creados.
4 Listado de Casos de Pruebas
Seleccione el Caso de Prueba al cual desea agregar el nuevo Caso de Prueba y presione el botón
“Aceptar“.
Si no hay ningún Grupo de Prueba/Caso de Prueba en el proyecto, soapUI abrirá una ventana para pedir
los nombres del TestSuite y TestCase.
5 Create TestSuite
6 Create TestCase
28 de 41
Framework Atlas
Arquetipo WebService
SoapUI abrirá una ventana para introducir el nombre y especificar aserciones comunes en la petición de
prueba. Las aserciones a seleccionar son las siguientes:
o
Adds Validation that response is a SOAP message. (Valida que la respuesta recibida es un
mensaje Soap)
o
Adds Validation that response is not a SOAP Fault. (Valida que la respuesta recibida sea un
mensaje Soap no fallido, si la prueba válida si se produces un error, no se debe seleccionar esta
opción).
7 Agregar TestCase
Los correspondientes TestSuite/TestCase se crearán y la petición se añadirá como TestCase, la cuál es
una copia de la petición original (de esta manera, puedes seguir utilizándolo sin modificar la petición de
prueba)
Un editor de peticiones de prueba casi idéntico al estándar se abre con el nuevo TestCase.
29 de 41
Framework Atlas
Arquetipo WebService
8 Editor de peticiones de prueba
3.4.3.
Ejecutar TestCase.
En el panel de Navegación, haga doble clic en el caso de prueba que contiene aserciones. Seguidamente SoapUI
abrirá la ventana correspondiente. Haga clic en el botón de reproducción, el caso de prueba se ejecutara,
evaluando las aserciones contenidas en los pasos “TestStep”.
3.5.
Aserciones.
30 de 41
Framework Atlas
Arquetipo WebService
Las aserciones se utilizan para validar el mensaje recibido por un “TestStep” durante la ejecución, por lo general
mediante la comparación de las partes del mensaje (o todo el mensaje) a algún valor esperado. Se pueden añadir
cualquier numero de aserciones a un “TestStep”.
Después de una ejecución, todas las aserciones son aplicadas a la respuesta recibida, si alguna de esta
validaciones falla, el “TestStep” se marca como fallido en la vista del caso de prueba y se muestra la
correspondiente entrada en el registro de la ejecución de pruebas.
3.5.1.
Gestión de Aserciones.
Las aserciones siempre se muestran en la pestaña inferior del TestSpet que lo contiene.
31 de 41
Framework Atlas
Arquetipo WebService
En la imagen anterior se ven tres aserciones añadidas en el mensaje Soap del TestStep. Las dos primeras fueron
OK, pero la última fue fallida.
La barra de herramientas
localizada en la parte superior del listado de aserciones, permite
agregar, configurar, eliminar, mover y clonar aserciones y presionando el botón derecho del ratón, aparecerá un
menú emergente que contiene acciones similares.
Al hacer doble clic en una aserción nos lleva a su ventana de configuración si está disponible.
3.5.2.
Categorías de aserción.
Todas las categorías que contienen aserciones se enumeran a continuación:
Property Content
Contains: Busca la existencia de una cadena en los valores de
(Propiedades de Contenido)
las propiedades. Soporta expresiones regulares. Es aplicable a
cualquier propiedad.
Not Constains: Busca la inexistencia de una cadena en los
valores de las propiedades. Soporta expresiones regulares. Es
aplicable a cualquier propiedad.
XPath Macht: Usos de es una expresión XPath para seleccionar
el contenido de la propiedad de destino y compara el resultado
con un valor esperado. Aplicable a cualquier propiedad que
contiene XML.
XQuery Match: Permite el uso de una expresión XQuery para
seleccionar el contenido de la propiedad de destino y compara el
resultado con un valor esperado. Aplicable a cualquier propiedad
que contiene XML.
Message Content Assertion: Permite la validación de contenido
32 de 41
Framework Atlas
Arquetipo WebService
complejo de mensajes XML. Aplicable a cualquier propiedad que
contenga XML.
Compliance, Status and
HTTP Download all resource: Descarga todos los recursos que
Standards
se encuentran referenciados en un documento HTML (imágenes,
(Cumplimientoc, Estado y
scripts, etc) y valida que todos ellos estén disponibles. Aplicable a
Normas)
cualquier propiedad que contiene HTML.
Invalid HTTP Status Codes: Valida que el mensaje de respuesta
recibido contiene un estado de código HTTP no valido en la lista
definida. (Aplicable a cualquier TestStep que reciba mensajes
HTTP).
Not SOAP Fault: Valida que el mensaje de respuesta recibido no
sea un error de Soap.
Schema Compliance: Valida que el mensaje de respuesta
recibido sea compatible con el WSDL asociado o la definición de
esquema WADL. (Aplicable a SOAP y REST TestStep)
SOAP Fault: Valida que el mensaje de respuesta recibido sea un
error de Soap. (Aplicable solo a MockResponse y TestSteps
Soap).
SOAP Response: Valida que la respuesta recibida sea un
mensaje Soap valido. (Aplicable solo a TestRequest y TestSteps
Soap).
Valid HTTP Status Codes: Valida que el mensaje de respuesta
recibido contenga un estado de código HTTP valido en la lista
definida. (Aplicable a cualquier TestStep que reciba mensajes
HTTP).
WS-Addressing Request: Valida que la solicitud recibida
contenga encabezados de WS-Addressing válidos. (Aplicable
solo a MockResponse y TestSteps Soap).
WS-Addressing Response: Valida que la respuesta recibida
contenga encabezados de WS-Addressing válidos. (Aplicable
solo a TestRequest y TestSteps Soap).
WS-Security Status: Valida que el mensaje recibido contenga
cabeceras WS-Security validos. (Aplicable solo a TestSteps
Soap).
Script
Script Assertion: Ejecuta un script personalizado para realizar
validaciones arbitrarias. (Aplicable solo a TestSteps)
SLA
Response SLA: Valida que la ultima respuesta recibida fue
dentro de los limites definidos. (Aplicable a Script, TestSteps y
TestSteps que envían peticiones y reciben respuesta)
33 de 41
Framework Atlas
Arquetipo WebService
JMS
JMS Status: Valida que la solicitud JMS sea ejecutada con éxito.
(Aplicable a TestSteps con JMS endpoint)
JMS Timeout: Valida que la declaración JMS no tome más
tiempo que la duración especificada. (Aplicable a TestSteps con
JMS endpoint)
JBDC
JDBC Status: Valida que la declaración JDBC sea ejecutada con
éxito. (Aplicable solo a JDBC TestSteps)
JDBC Timeout: Valida que la declaración JDBC no tome más
tiempo que la duración especificada. (Aplicable solo a JDBC
TestSteps)
Security
Sensitive Information Exposure: Comprueba que el mensaje
recibido no expone información sensible sobre el sistema de
destino. (Aplicable a REST, SOAP y http TestSteps)
3.5.3.
Aserciones comunes.
Las aserciones disponibles para todos tipos de TestSteps son:
Contains - comprueba la existencia de una cadena especificada
Not Contains - comprueba la inexistencia de una cadena especificada.
Reponse SLA - comprobar el tiempo de respuesta frente a un valor especificado.
XPath Match - compara el resultado de una expresión XPath para un valor esperado.
XQuery match - compara el resultado de una expresión XQuery a un valor esperado
Script - Ejecuta una secuencia de comandos arbitraria que se puede utilizar para validar el mensaje
recibido si lo desea.
3.5.4.
Añadir Aserciones en TestCase.
Seleccionar el “TestStep” y presione la tecla “enter”, SoapUI abrirá un editor de peticiones de prueba.
En la barra de herramientas ubicada en la parte superior del editor de peticiones de prueba, seleccionar el
segundo botón.
34 de 41
Framework Atlas
Arquetipo WebService
9 Botón para Agregar Aserción
SoapUI abrirá la ventana de dialogo que permitirá elegir el tipo de aserción.
10 Ventana para agregar Aserciones
Presione el botón “Add” para agregar la aserción seleccionada.
3.5.5.
Aserciones con XPath Match.
La aserción “XPath Match” permite la especificación de una expresión XPath para ser evaluada en relación a un
mensaje de respuesta recibido y comparar su resultado con un valor predefinido. Las expresiones pueden
eleccionar todo, desde valores de atributos, hacer evaluaciones booleanas o seleccionar la respuesta de todo el
cuerpo (XmlUnit se usa internamente para comparar los elementos XML, jerarquías o nodos). Internamente,
soapUI usa el motor Saxon 8.8 XPath que tiene soporte para XPath 1,0 y 2,0 XPath.
La ventana de diálogo de configuración para la aserción XPath Match se divide en 2 zonas, la de la parte superior
que contiene la expresión XPath deseada y la de la parte inferior que contiene el resultado esperado.
3.5.6.
Ejemplos de Aserciones XPath Match:
35 de 41
Framework Atlas
Arquetipo WebService
Los siguientes ejemplos son realizados sobre el proyecto EjemploService-soapui-project.xml en el TestStep
“Alterar”
Valida si existe una etiqueta xml en el mensaje de respuesta:
XPath Expression:
declare namespace ax23='http://datos.ejpl_ws/xsd';
exists(//ax23:cadenaSalida)
Expected Result:
true
Valida que el valor de la etiqueta idLlamada sea numérico.
XPath Expression:
declare namespace ax23='http://datos.ejpl_ws/xsd';
matches(//ax23:idLlamada/text(),'\d')
Expected Result:
true
Valida que el valor de la etiqueta idLlamada sea mayor que 0.
XPath Expression:
declare namespace ax23='http://datos.ejpl_ws/xsd';
//ax23:idLlamada/text()>0
Expected Result:
true
Valida que el valor de la etiqueta cadenaSalida contenga el valor “cadena”.
XPath Expression:
declare namespace ax23='http://datos.ejpl_ws/xsd';
//ax23:cadenaSalida/contains(text(),'cadena')
36 de 41
Framework Atlas
Arquetipo WebService
Expected Result:
true
Ver el siguiente enlace http://www.w3.org/TR/xpath/#section-Expressions para ver todas todas las funciones
predefinidas con XPath.
3.6.
Test Suite.
Una TestSuite sirve como contenedor para un numero arbitrario de Casos de Pruebas (“TestCases”). Cuando se
ejecuta un TestSuite, los Casos de Pruebas (“TestCases”) incluidos se pueden ejecutar tanto en secuencia como
en paralelo.
3.6.1.
Acciones del TestSuite.
Las siguientes acciones están disponibles desde el menú que aparece al realizar clic derecho sobre el nodo del
“TestSuite”.
Show TestSuite Editor: Opción que permite abrir el lanzador de TestSuite.
Disable TestSuite: Opción que permite habilita/deshabilita el TestSuite
New TestCase: Opción que permite crear un nuevo caso de prueba en el TestSuite
Clone TestSuite: Opción que permite clonar una TestSuite, incluyendo todos los Casos de Pruebas
(“TestCases”) y TestSpteps.
Launch TestRunner: Opción que abre un cuadro de dialogo para ejecutar el TestSuite desde línea de
comandos.
Rename: Opción que permite renombrar el TestSuite.
Remove: Opción que permite eliminar el TestSuite del proyecto SoapUI.
Online Help: Abre la pagina de ayuda online en el navegador.
3.6.2.
Crear TestSuite.
Presionar botón derecho del ratón sobre la interfaz y seleccionar la opción “Generate TestSuite”.
37 de 41
Framework Atlas
Arquetipo WebService
11 Generate TestSuite
SoapUI abrirá un cuadro de dialogo para generar un “TestSuite” completo para la interfaz seleccionada.
12 Opciones de generación del TestSuite
El cuadro de dialogo contiene las siguientes opciones:
o
TestSuite: Combobox que permite seleccionar crear una TestSuite sobre una existente o una
nuevo.
o
Style: Existen dos Tipos de estilos:

One TestCase for each Operation: Permite crear TestSuite con casos de pruebas para
cada operación.

Single TestCase with one Request for each Operation: Permite crear TestSuite con casos
de pruebas únicos con una sola solicitud por cada operación.
o
Request Content: Permite definir el contenido de la solicitud para los casos de prueba. Existe dos
opciones.

Use existing Request in Interface: Crea Casos de Pruebas con los mensajes de solicitud
existentes en la interfaz.
38 de 41
Framework Atlas
Arquetipo WebService

Create new empty requests: Crea Casos de Pruebas con mensajes de solicitud vacios.
o
Operations: Permite seleccionar las operaciones a las cuales desea generar Casos de Pruebas.
o
Generate LoadTest: Permite crear una prueba de carga por defecto para cada Caso de Prueba
generado.
Seleccione las opciones que usted cree oportunas para sus pruebas y por ultimo presione el botón “OK”.
Si en el cuadro de dialogo anterior ha seleccionado en la opción “TestSuite” el valor por defecto “<create>”,
aparece la siguiente ventana, que permite especificar el nombre de la “TestSuite”:
13 Name of TestSuite
Digite en nombre de la “TestSuite” y presione el botón “Aceptar”.
Si ha seleccionado la opción “One TestCase for each Operation” en el cuadro de dialogo de creación de
“TestSuite” y en el caso de que una operación tenga más de un mensaje de solicitud, aparecerá una
ventana informando que el nombre del paso debe ser único y debe ser especificado.
14 Name of TestName
Digite en nombre de la “TestStep” y presione el botón “Aceptar”.
3.6.3.
Ejecutar TestSuite.
Haciendo doble clic sobre un TestSuite, SoapUI abre el lanzador de TestSuite que contiene la lista de los Casos de
Pruebas (TestCases). Cada Caso de Prueba tiene una barra de progreso que está determinada por la cantidad de
pasos (TestStep) y por defecto no está activa. Haga clic en el botón de reproducción, los casos de pruebas se
ejecutaran, evaluando las aserciones contenidas en los pasos TestStep, la barra de progreso puede tomar color
rojo o verde según el resultado de cada TestStep (Rojo si el TestStep fue fallido, verde si fue correcto) y muestra
un texto indicando del resultado final de cada prueba.
39 de 41
Framework Atlas
Arquetipo WebService
15 Lanzador de TestSuite sin Ejecutar
16 Lanzador de TestSuite Ejecutado
4
PREGUNTAS MAS FRECUENTES
La lista de preguntas frecuentes se encuentra en el portal de arquitectura.
5
ENLACES RELACIONADOS
Producto
URL
40 de 41
Framework Atlas
Arquetipo WebService
Axis2
http://ws.apache.org/axis2/
Configuración
http://axis.apache.org/axis2/java/core/docs/axis2config.html
Services.xml
Apache Maven
http://maven.apache.org/
Log4J
http://logging.apache.org/log4j/
SoapUI
http://www.soapui.org/
http://www.soapui.org/Test-Automation/maven-2x.html
http://www.soapui.org/Functional-Testing/testcase-execution.html
XPath
http://www.w3.org/TR/xpath/#section-Expressions
41 de 41