WSO2 redmine-connector: Exponiendo los servicios de nuestro Redmine Corporativo a través del WSO2 ESB

Acá les dejo el enlace a un nuevo post que acabo de publicar en mi blog que puntualmente los temas que toca son:

• Compilar y empaquetar el redmine-connector
• Desplegar y activar un conector en el WSO2 ESB
• Como importar un conector para el Developer Studio
• Como implementar un Servicio Proxy en este caso usando el redmine-connector haciendo uso del DS
• Como construir y desplegar un Composite Application Project desde el DS en el WSO2 ESB
• Como realizar un test de un servicio Rest en nuestro caso haciendo uso del plugins RestClient del Mozilla Firefox y desde el SoapUI

Nos les adelanto nada más solo sigan este enlace:  http://wp.me/p5DCiP-10

Saludos

Read More [...]

Posted in axis2, ESB, interoperabilidad, maven, REST, servicio proxy, servicios web, soa, SOAPUI, WSO2, WSO2 Developer Studio, xml

WSO2 DS: Exponiendo nuestra BD Oracle usando REST.

En otras entradas hemos visto lo fácil que es crear un servicio de datos usando la suite de WSO2, bien sea a través del WSO2 AS o el WSO2 DSS. También hemos visto como exponer estos datos usando REST con solo unos pocos pasos adicionales y como consumir estos servicios expuestos usando REST.

En esta entrada veremos como combinarlo todo implementando un escenario que nos ha pedido un cliente hace poco: Exponer sus datos almacenados en una BD Oracle tanto por SOAP como por REST de una manera altamente configurable y rápida de implementar.
Veamos una pequeña PoC que le preparamos:


Paso 1: Crear la BD.

Nos conectamos al SGBD y creamos un usuario “appserver” con contraseña “appserver”.



Volvemos a conectar pero esta vez usando las credenciales del usuario recién creado y en la BD que usamos en una entrada anterior DBMB.

Una vez autenticados creamos una tabla “cliente” e insertamos alguna data que luego será consultada.




Por último creamos un procedimiento almacenado para hacer una inserción en la tabla:






Paso 2: Crear el servicio de datos.

Haciendo uso del conocimiento que ya tenemos de entradas anteriores, procedemos a crear un servicio de datos. En la parte de configuración del DataSource quedaría de la siguiente manera:



Se puede apreciar que se ha dado clic en “Test Connection” y se ha conectado exitosamente a la BD. Previamente debemos haber añadido el jar ojdbc6.jar a [HOME_AS]\repository\components\lib\

La primera query que agregamos es la de consumir el procedimiento almacenado anteriormente creado:




Y la segunda query es para consultar la información de la tabla:





Una vez terminada estas configuraciones en las querys procedemos a crear las operaciones que no tienen nada de complicación, guardamos nuestro servicio y procedemos a consumirlo.





Paso 3: Incluir funcionalidad REST.

La implementación consiste en agregar dos recursos tal y como se muestra a continuación. Uno que se llama “clientes” para obtener el listado de clientes y otro que se llama “insertarCliente” para insertar los datos de un cliente en la BD.



Sus configuraciones son realmente sencillas. La de clientes es:




Y la de insertarCiente es:




Paso 4: Probar por REST.

Una vez guardado el servicio se procede a probarlo usando el plugin para REST de firefox:



También lo podemos probar desde el SOAPUI:

 

Y ahora veremos como llamar a la operacion de insertarCliente primero por el SOAPUI:



Y luego por el cliente REST de firefox:



Vean que se insertaron Cliente7 y Cliente8.

Para finalizar una consulta a través del recurso “clientes” nos confirma el éxito de ambas llamadas.

 

Eso es todo, de una manera muy fácil hemos expuesto nuestros datos tanto por SOAP como por REST.

Esperamos les sea de utilidad.

Read More [...]

Posted in Oracle, REST, servicio de datos, SOAPUI, WSO2

SOAPUI para la creación de servicios falsos. II

En la primera entrada vimos cómo crear un servicio web falso usando el SOAPUI. En esta segunda entrada veremos cómo realizar lo mismo pero para servicios REST, tanto POX como JSON. Para ello nos apoyaremos en esta entrada

Prerrequisitos:

1. Tener un fichero response.xml con el XML que se desea retornar.
2. Tener un fichero jsonresponse.json con el JSON que se desea retornar.

Paso 1: creamos un servicio mock tal y como vimos en la primera entrada.

Paso 2: creamos un script en Groovy que lee de un fichero y devuelve su contenido como una respuesta.

Paso 3:  arrancamos el binding SOAP12, que usaremos para POX, y lanzamos el request para SOAP12, al invocarlo ya podemos ver el resultado en XML.

Si queremos ver el Raw cambiamos de pestaña y podemos ver el tipo de contenido text/xml y la respuesta XML.

Paso 4: realizamos lo mismo pero ahora queremos que la respuesta no sea POX si no JSON.

Abrimos el binding SOAP11 y agregamos el script siguiente:

Vean como creamos un Stream con la información del fichero cargado, y al objeto response le seteamos varias propiedades para al final pasarle el flujo de información del fichero cargado.

Paso 5:  arrancamos el biding soap11 e invocamos a la operación. En este caso vemos que la respuesta es un JSON.

Si queremos ver el Raw cambiamos de pestaña y listo.

Otra manera de probarlo es usando el plugin RESTClient  del Firefox como pueden ver en la imágenes siguientes:

Espero les sea de utilidad.

Read More [...]

Posted in mock, REST, SOAPUI

SOAPUI para la creación de servicios falsos. I

Cuando se trabaja en un proyecto de mediana o gran envergadura es normal tener trabajando diferentes equipos en diferentes aspectos de un mismo sistema, diferentes componentes o módulos para poner un ejemplo. También es normal que estos componentes interactúen de alguna manera brindando o consumiendo información de otros componentes. En dependencia del grado de complejidad de cada tarea los  equipos de trabajo no tienen por qué ir trabajando al mismo ritmo y es entonces donde aparece la complicación de cómo hacer que un equipo A que requiere una funcionalidad que debe ser implementada por un equipo B pueda avanzar, si el equipo B aun no la ha implementado.

La respuesta vendría siendo  la siguiente:

1. Como primer paso se debe establecer algún tipo de contrato que defina qué información brindará la funcionalidad y cómo está será accedida.
2. Luego el equipo B debe implementar un componente falso, o sea algo que aunque no implementa la funcionalidad real actúa como si lo hiciera, lo más creíblemente posible. La idea es que este tipo de componente se implementa rápidamente, casi sin esfuerzo o con mucho menos esfuerzo que el componente real.
3. Para finalizar el equipo A usaría el componente falso para comprobar que se cumple con el contrato del punto 1. Y de esta manera avanzar en su implementación.

Logrado esto, cuando el equipo B implemente la funcionalidad real, será cosa de quitar el componente falso y poner el real, y el equipo A ni tendrá que enterarse del cambio. Claro que debe ser notificado.

Bajo el supuesto de que la comunicación será vía servicios web usando SOAP o a través de APIs con servicios REST, la herramienta SOAPUI es la respuesta para implementar una solución rápida del punto 2.

Ya hemos visto algo de SOAPUI en [1] y en [2] así que para aquellos que consulten el blog no es una herramienta nueva. En esta primera entrada veremos cómo crear rápidamente un servicio web falso, mock, usando SOAPUI y en una segunda entrada veremos cómo hacer lo mismo pero para un servicio REST.

Comencemos.

Paso 1: Tener el WSDL del servicio que deseamos implementar.

Paso 2:  Creamos un proyecto en SOAPUI marcando la opción “Create MockService”.

Luego de realizada esta acción se nos muestra la siguiente ventana.

Ahí podemos seleccionar las operaciones que queremos exponer, la ruta y el puerto por el cual el SOAPUI estará escuchando. Además nos permite definir si queremos que el servicio sea iniciado inmediatamente.

Bastante fácil verdad?

La estructura es la siguiente:

Se puede apreciar el proyecto creado, una interface EchoSOAP12 que contiene un request de la operación y otra interface EchoSOAP12 MockService que es el servicio falso creado, que contiene una respuesta.

Paso 3: ajustar  el servicio falso creado.

Ya este paso es un poco más enfocado a cómo queremos que funcione el servicio. Por defecto puede venir con una respuesta generada por la misma herramienta como pueden ver a continuación.

Pero ustedes pueden crear tantas respuestas como quieran, y a través de scripts puede decidir cuál mostrar en función del mensaje request que sea enviado.

Para detener el servicio pueden pulsar sobre el botón rojo, con forma de cuadrado, en caso de que no lo estén usando, pues siempre será un ahorro de recursos.

Si queremos crear más respuestas podemos dar clic derecho sobre la operación echoOperation  dela interface del servicio web falso y tendremos la opción “New MockResponse”.

Para comprobar que tenemos 2 operaciones pues abrimos el Request 1 y ajustando el endpoint a http://127.0.0.1:8088/mockEchoSOAP12 podremos ver como primero se obtiene la respuesta creada por el soapui y luego la respuesta creada por nosotros.

El servicio se puede configura un poco más. Basta con ir a la última de la siguiente imagen.

Y veremos esta pantalla

Ahí aproveché para cambiar el host, pero igual pueden cambiar la ruta o el puerto. O tal vez especificar un operación fallida por defecto.

Paso 4: exportar el servicio creado para un servidor de aplicaciones.

Este paso es sumamente importante pues hasta el momento para usar el servicio falso creado tenemos que tener el SOAPUI corriendo, y eso no es muy eficiente. Lo ideal sería que pudiéramos desplegar el servicio  en un servidor de aplicaciones y usarlo desde ahí. Así que manos a la obra.

Paso 4.1:  damos clic en el proyecto creado y seleccionamos “Deploy as War” y procedemos a configurar la forma de despliegue.

Paso 4.2:  desplegar el resultado del paso 2 en un contenedor de aplicaciones.

En este caso para la versión de SOAPUI que tengo no me crea el war, si no recuerdo mal en versiones anteriores si lo hacía.

Así que modifiqué el puerto por el del 8080 para desplegarlo  en un tomcat ya que inicialmente quería hacerlo en el AS de WSO2 y agregué una carpeta en mi escritorio y obtengo lo siguiente:

Dentro del WEB-INF verán un web.xml, el cual pueden configurar a su gusto sin tener que volver a regenerar el proyecto desde el SOAPUI.

La carpeta generada la copio para [tomcat]/ webapps/ y al inicial el servidor me dirijo a http://localhost:8080/soapuimockEcho/ y podemos ver lo siguiente:

Si pinchamos en [EchoSOAP12 MockService] tendremos acceso al WSDL del servicio mock y si lo queremos probar pues hacemos lo mismo que en [2] y listo.

 [1] http://desarrollosoa.blogspot.com/2013/06/usando-soapui-para-consumir-servicios.html

 [2] http://desarrollosoa.blogspot.com/2013/06/puebas-de-carga-y-rendimiento-con.html

Read More [...]

Posted in mock, servicios web, SOAPUI

Puebas de carga y rendimiento con SOAPUI y WSO2.

En esta entrada veremos cómo podemos usar SOAPUI para realizar pruebas sobre los servicios web.

Usaremos el servicio creado en la entrada anterior, pueden usar el servicio seguro o inseguro, como gusten.

Seleccionan un mensaje request y le dan clic derecho y seleccionan “Add to TestCase”

Ahí le ponen un nombre o dejan el que está, porque estaremos creando una suite de pruebas y luego un caso de prueba. Verán entonces lo siguiente:

Les aparecen varias opciones, algunas son aserciones que permiten validar contra el XSD definido dentro del servicio, en el caso de la segunda opción que la marcaré, y en el caso de la primera se valida que el mensaje de respuesta  sea un mensaje SOAP y no un SOAPFault por ejemplo.

Luego dan OK.

Como verán se agrega una suite de prueba con un caso de prueba que tiene además un paso de prueba que se corresponde con la operación que usamos como base.

Si hacen una prueba verán como les devuelve un mensaje de respuesta válido. Además de que nos pone en verde las 2 aserciones que especificamos cuando creábamos el caso de prueba.

Ahora daremos clic derecho encima de “Load Test” y seleccionamos “New Load Test” , ponen un nombre y verán lo siguiente:

Ahora debemos ajustar los parámetros en funcion de nuestras necesidades.

Si queremos simular varios clientes consumiendo el servicio, vamos a la opción señalada en negro, por defecto aparecen 5 pero ustedes puedan variar ese número a discreción, tengan en cuenta que mientras más hilos más consumo del CPU.

Si queremos especificar una demora entre una petición y otra vamos a la opción señalada en rojo. Tengan en cuenta que es en milisegundos.

Si queremos determinar el tiempo de duración del servicio vamos a la opción señalada en verde y aquí se muestra que solo durará 60 segundos pero pueden cambiarla para especificar la cantidad de peticiones por hilo por ejemplo.

Luego es solo cosa de correr la prueba, como mismo se ejecuta una petición a un servicio y esperar los resultados.

En este caso hice una prueba con solo 1 hilo, con una demora de 1ms y con 100 ejecuciones por hilo. Ustedes varíen a su discreción y revisen sus resultados.

Read More [...]

Posted in pruebas, servicios web, SOAPUI, WSO2

Usando SOAPUI para consumir servicios seguros en la plataforma de WSO2.

En esta entrada quería abordar un tema pendiente de la entrada anterior y es el uso de la herramienta SOAPUI para las pruebas en los servicios web y cubrir el cómo acceder a un servicio asegurado con UserNameToken.

Luego de descargarse la herramienta, como pueden ver estoy usando la versión 4.5.1, se les abre una ventana donde pueden ver las siguientes opciones en el menú superior:

Si ya tienen el WSDL de un servicio entonces podemos crear un escenario de pruebas para el servicio.

Haremos lo siguiente:

1. Crearemos un proyecto a partir del WSDL del servicio.Usaremos un servicio sin seguridad, en nuestro caso el servicio de acceso a datos y lo consumiremos desde el SOAPUI. 
2. Luego crearemos otro proyecto para el WSDL del servicio proxy que ya viene con seguridad. 
3. Realizaremos las configuraciones necesarias para especificar la información requerida para poder consumir el servicio.

Comencemos!!!

Paso 1:

Crear un proyecto es muy fácil, dan clic en File y luego en “New soapui Project”

Aquí buscamos el WSDL del servicio ya sea desde el filesystem o desde una URL, como en mi caso ya que voy al AS y copio la URL del WSDL del servicio creado.

Le damos OK y listo.

Verán cómo se crea la estructura del proyecto.

Como ven se han creado dos definiciones, una por cada binding contenido en el WSDL del Servicio, una para SOAP11 y otra para SOAP12. Cada una con todas las operaciones del servicio.

Ahora vamos a consumir el servicio de forma insegura, para eso seleccionamos la operación select_all_datos_operation del SOAP12 y le damos al signo de +, ahí verán que ya hay un mensaje Request creado, cuando dan doble clic encima de este mensaje se les muestra lo siguiente:

Ahora solo tienen que darle al signo que se muestra como un triángulo verde en la ventana recién abierta y eso le envía un mensaje al servicio y verán como inmediatamente se obtiene la respuesta.

Además de ver el mensaje de respuesta también se muestra la demora en el consumo del servicio, en este caso 9 milisegundos.

Es lo mismo para el resto de las operaciones lo que en esos casos deberán de introducir los parámetros en el XML del mensaje request.

Paso 2:

Ahora en vez de usar el WSDL del servicio de acceso a datos usaremos el WSDL del servicio proxy seguro para crear un nuevo proyecto en el SOAPUI.

Esta es la estructura del proyecto.

Si volvemos a consumir la operación del paso anterior  veremos lo siguiente:

Nos está diciendo que el mensaje de request no contiene los encabezados de seguridad necesarios. Veamos cómo se agregan.

Paso 3:

Deben ir a la raíz del proyecto y dan doble clic y seleccionan la pestaña “WS-Security Configuration”

Ahí crearemos una configuración de salida dándole al signo + señalado en rojo

Le ponen un nombre y luego dan clic en el círculo marcado en azul.

Se mostrará una ventana con varios encabezados que se pueden agregar, como se muestra en la siguiente imagen.

Nosotros usaremos:

Timestamp: especifican un “Time to live”  (3000)que determinará el periodo de tiempo en el cual el mensaje se considerará válido. Esto evita que se use el mensaje luego de ese periodo con fines no muy agradables. Solo imagínense que enviamos un mensaje con un descuento de nuestra tarjeta y luego alguien usa ese mismo mensaje y nos vuelve a descontar. Como ya dije, nada agradable :-D

Username: ahí deben especificar el usuario, la contraseña y el formato de la contraseña.

Luego guardan todo y vuelven al request que nos falló en el paso 3.

Lo importante que hay que hacer es en la sección del mensaje request seleccionar en “Outgoing WSS” la configuración que acabamos de crear.

Si vuelven a probar a enviar un mensaje usando esta configuración verán lo siguiente:

Como pueden observar ya el servicio se pudo consumir al agregarle los Header de seguridad, usando la configuración UT que creamos, y en el mensaje de respuesta se pueden ver los encabezados de seguridad que en el mensaje de respuesta incluye un timestamp.

Y bueno eso es todo. Cada vez que necesiten como parte de sus pruebas consumir un servicio seguro con la política usernametoken estos son los pasos que tienen que seguir.

Read More [...]

Posted in seguridad, servicios web, SOAPUI, WSO2