Diferencia entre revisiones de «Mock de un web service con SoapUI»

De Dos Ideas.
Saltar a: navegación, buscar
 
(No se muestran 22 ediciones intermedias de 5 usuarios)
Línea 16: Línea 16:
 
6. Guardar el proyecto, esto genera un xml con la información necesaria para volver a generar el proyecto.
 
6. Guardar el proyecto, esto genera un xml con la información necesaria para volver a generar el proyecto.
  
Un detalle importante es que con SOAP UI 2.5, si se necesita incovar desde el exterior al WSDL publicado por nuestro Mock, este queda conformado con una dirección de localhost en <SOAP:address location="localhost:port/path"/>. Entonces, si por ejemplo se utiliza el servicio simulado desde alguna herramienta de automatización como [http://www.dosideas.com/wiki/Selenium Selenium], invocará al WS en el localhost y no en la dirección del servidor.
+
Un detalle importante es que con SOAP UI 2.5, si se necesita invocar desde el exterior al WSDL publicado por nuestro Mock, este queda conformado con una dirección de localhost en <SOAP:address location="localhost:port/path"/>. Entonces, si por ejemplo se utiliza el servicio simulado desde alguna herramienta de automatización como [http://www.dosideas.com/wiki/Selenium Selenium], invocará al WS en el localhost y no en la dirección del servidor.
  
 
Con la versión 3.0 esto no sucede, y es la que usamos. Necesita Java 6.
 
Con la versión 3.0 esto no sucede, y es la que usamos. Necesita Java 6.
Línea 56: Línea 56:
 
==Iniciar el Mock Service en Unix==
 
==Iniciar el Mock Service en Unix==
  
El Mock Service se inicia con una línea de comando. Se necesita el xml generado al guardar el proyecto (ej: Mi-soapui-project.xml). Ver apartado Mock Service paso a paso.
+
El Mock Service se inicia con una línea de comando que involucra al archivo que viene en la instalación llamado "mockservicerunner.sh". Se necesita el xml generado al guardar el proyecto (ej: Mi-soapui-project.xml). Ver apartado Mock Service paso a paso.
 +
 
 
Ej para Solaris:
 
Ej para Solaris:
Se instala SOAPUI descomprimiendo el archivo soapui-3.0.1-linux-bin.zip, en el directorio deseado y la única modificación que hubo que hacer para poder ejecutar el  mockservicerunner.sh, es editarlo cambiando el intérprete que lo ejecuta a ksh (#!/bin/ksh), originalmente viene con “sh” y no funciona en: SunOS 5.10 Generic_125100-10 sun4u sparc SUNW,Sun-Fire-V890.
+
Se instala SOAPUI descomprimiendo el archivo soapui-3.0.1-linux-bin.zip, en el directorio deseado y la única modificación que hubo que hacer para poder ejecutar el  mockservicerunner.sh, es editarlo cambiando el intérprete que lo ejecuta por Ej: ksh (#!/bin/ksh), en caso que no se cuente con  el "sh" que viene originalmente en el script.
  
 
La línea de comando para levantar el servicio en segundo plano es:
 
La línea de comando para levantar el servicio en segundo plano es:
Línea 64: Línea 65:
 
nohup mockservicerunner.sh -m"Nombre-MockService" "/path/Mi-soapui-project.xml" &
 
nohup mockservicerunner.sh -m"Nombre-MockService" "/path/Mi-soapui-project.xml" &
 
</code>
 
</code>
Es conveniente crear un directorio por cada Servicio que se quiera implementar, donde quedará el archivo del proyecto  Mi-soapui-project.xml, un scritp para iniciarlo, y donde quedarán los log de funcionamiento y error que genera SOAPUI.
+
Es conveniente crear un directorio por cada Servicio que se quiera implementar, donde quedará el archivo del proyecto  Mi-soapui-project.xml, un script para iniciarlo, y donde quedarán los log de funcionamiento y error que genera SOAPUI.
  
 
==Devolver un valor desde una petición (request)==
 
==Devolver un valor desde una petición (request)==
Línea 102: Línea 103:
  
 
Y así es como, dependiendo del valor ingresado, dinámicamente podremos devolver valores diferentes.
 
Y así es como, dependiendo del valor ingresado, dinámicamente podremos devolver valores diferentes.
 +
 +
Hey, keillr job on that one you guys!
 +
 +
==Obtener el valor de un nodo en un request con name space==
 +
 +
Si tenemos definido un name space en nuestro request vamos a tener que declarar el name space en nuestro holder para poder obtener los valores de los nodos.
 +
 +
'''Request con name space'''
 +
 +
<code html4strict>
 +
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 +
xmlns:xsd="http://chopera.metrochopp/xsd">
 +
  <soapenv:Header/>
 +
  <soapenv:Body>
 +
      <xsd:getTamaño>
 +
        <xsd:metros>1,5</xsd:metros>
 +
      </xsd:getTamaño>
 +
  </soapenv:Body>
 +
</soapenv:Envelope>
 +
</code>
 +
 +
Para leer el valor del nodo "<xsd:metros>" declaramos el name space en el holder de la siguiente manera:
 +
 +
<code html4strict>
 +
holder.declareNamespace('xsd', 'http://chopera.metrochopp/xsd')
 +
//obtenemos el valor del nodo
 +
def metros = holder.getNodeValue("//xsd:metros")
 +
</code>
 +
 +
==Log del script==
 +
 +
Para logear desde el script de groovy tenemos que poner:
 +
 +
<code html4strict>
 +
log.info "Mensaje"
 +
</code>
 +
 +
Los logs saldran por la consola dentro de soapUI en la solapa que dice "script log".
  
 
==Ver también==
 
==Ver también==
Línea 109: Línea 148:
 
* [http://www.dosideas.com/foros/5-ascensor-a-ningun-lugar/658-web-service-minimo-para-pruebas-de-desarrollo.html Foro con la comparación entre Jetty y SoapUI]
 
* [http://www.dosideas.com/foros/5-ascensor-a-ningun-lugar/658-web-service-minimo-para-pruebas-de-desarrollo.html Foro con la comparación entre Jetty y SoapUI]
 
* [http://www.soapui.org/userguide/functional/groovystep.html Ayuda con Groovy]
 
* [http://www.soapui.org/userguide/functional/groovystep.html Ayuda con Groovy]
 +
* [http://www.soapui.org/apidocs/com/eviware/soapui/support/XmlHolder.html Documentación de XmlHolder]
  
 
[[Category:Web Service]]
 
[[Category:Web Service]]
 
[[Category:ATDD]]
 
[[Category:ATDD]]

Revisión actual del 12:35 15 sep 2011

Partiendo del WSDL, se puede crear automáticamente un servicio web con una demo de invocación y respuesta para cada operación declarada en el contrato del servicio (WSDL).

Mock Service paso a paso

1. Generar nuevo proyecto, con el WSDL inicial y activar "create requests" y "create Ws Simulation of the imported WSDL".

2. Cuando presenta la pantalla para Generar el mock Service, colocar el path y puerto y seleccionar "Adds the Mock Services endpoint to the mocked interface" si se quiere usar luego una dirección diferente a la indicada en el WSDL.

3. Dar el nombre al Mock service

4. Verificar cada respuesta para las operaciones generadas y editarlas con el contenido que se necesite par el servicio.

5. Iniciar el Mock service que quedará atendiendo en el puerto y path indicados.

6. Guardar el proyecto, esto genera un xml con la información necesaria para volver a generar el proyecto.

Un detalle importante es que con SOAP UI 2.5, si se necesita invocar desde el exterior al WSDL publicado por nuestro Mock, este queda conformado con una dirección de localhost en <SOAP:address location="localhost:port/path"/>. Entonces, si por ejemplo se utiliza el servicio simulado desde alguna herramienta de automatización como Selenium, invocará al WS en el localhost y no en la dirección del servidor.

Con la versión 3.0 esto no sucede, y es la que usamos. Necesita Java 6.

Iniciar el Mock Service en Windows

El Mock Service se inicia con una línea de comando. Se necesita el xml generado al guardar el proyecto (ej: Mi-soapui-project.xml). Ver apartado Mock Service paso a paso.

Para Windows se puede hacer un .bat de esta manera (p.e. mockservicerunner.bat):

@echo off

set SOAPUI_HOME=%~dp0

set JAVA_HOME=C:\Archivos de programa\Java\jre6 set JAVA=%JAVA_HOME%\bin\java

set CLASSPATH=%SOAPUI_HOME%soapui-3.0.1.jar;%SOAPUI_HOME%..\lib\*;

rem JVM parameters, modify as appropriate set JAVA_OPTS=-Xms128m -Xmx384m -Dsoapui.properties=soapui.properties "-Dsoapui.home=%SOAPUI_HOME%\"

if "%SOAPUI_HOME%\" == "" goto START

   set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.ext.libraries="%SOAPUI_HOME%ext"
   set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.ext.listeners="%SOAPUI_HOME%listeners"
   set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.ext.actions="%SOAPUI_HOME%actions"
START

rem ********* run soapui testcase runner ***********

"%JAVA%" %JAVA_OPTS% -cp "%CLASSPATH%" com.eviware.soapui.tools.SoapUIMockServiceRunner %*

Entonces, la línea de comando sería: mockservicerunner.bat -m "Nombre-MockService" "Mi-soapui-project.xml". Con esto se puede hacer un acceso directo y ubicarlo en el Inicio. De esta manera, cada vez que se inicia la PC servidor, estaría disponible el servicio.


Iniciar el Mock Service en Unix

El Mock Service se inicia con una línea de comando que involucra al archivo que viene en la instalación llamado "mockservicerunner.sh". Se necesita el xml generado al guardar el proyecto (ej: Mi-soapui-project.xml). Ver apartado Mock Service paso a paso.

Ej para Solaris: Se instala SOAPUI descomprimiendo el archivo soapui-3.0.1-linux-bin.zip, en el directorio deseado y la única modificación que hubo que hacer para poder ejecutar el mockservicerunner.sh, es editarlo cambiando el intérprete que lo ejecuta por Ej: ksh (#!/bin/ksh), en caso que no se cuente con el "sh" que viene originalmente en el script.

La línea de comando para levantar el servicio en segundo plano es: nohup mockservicerunner.sh -m"Nombre-MockService" "/path/Mi-soapui-project.xml" & Es conveniente crear un directorio por cada Servicio que se quiera implementar, donde quedará el archivo del proyecto Mi-soapui-project.xml, un script para iniciarlo, y donde quedarán los log de funcionamiento y error que genera SOAPUI.

Devolver un valor desde una petición (request)

SoapUI permite simular un servicio. En caso de necesitar que el servicio simulado, tome un valor y responda dependiendo de ese valor ingresado, es necesario utilizar Groovy.

Con la siguiente secuencia:

1. Seleccionar el Mock Service en SoapUI

2. Seleccionar la operación

3. Seleccionar la respuesta que se quiere codificar

4. Parados sobre la respuesta de la operación, hacer click en pestaña "Script"

5. Escribir el siguiente código en el panel de edición, substituyendo por los valores que correspondan:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context) def holder = groovyUtils.getXmlHolder(mockRequest.requestContent) // para trabajar con el valor ingresado en el nodo "id" de la operacion def idRequest = ( holder["//id"] ) context.id = idRequest //si ingresa valores mayores 1, la salida será Si if (idRequest > "1") { context.salida = "Si" } //si ingresa valores menores o iguales a 1, la salida será No else { context.salida = "No" }

Y así es como, dependiendo del valor ingresado, dinámicamente podremos devolver valores diferentes.

Hey, keillr job on that one you guys!

Obtener el valor de un nodo en un request con name space

Si tenemos definido un name space en nuestro request vamos a tener que declarar el name space en nuestro holder para poder obtener los valores de los nodos.

Request con name space

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://chopera.metrochopp/xsd">
  <soapenv:Header/>
  <soapenv:Body>
     <xsd:getTamaño>
        <xsd:metros>1,5</xsd:metros>
     </xsd:getTamaño>
  </soapenv:Body>

</soapenv:Envelope>

Para leer el valor del nodo "<xsd:metros>" declaramos el name space en el holder de la siguiente manera:

holder.declareNamespace('xsd', 'http://chopera.metrochopp/xsd') //obtenemos el valor del nodo def metros = holder.getNodeValue("//xsd:metros")

Log del script

Para logear desde el script de groovy tenemos que poner:

log.info "Mensaje"

Los logs saldran por la consola dentro de soapUI en la solapa que dice "script log".

Ver también