Mostrando entradas con la etiqueta RESTful. Mostrar todas las entradas
Mostrando entradas con la etiqueta RESTful. Mostrar todas las entradas

jueves, 3 de septiembre de 2015

WSO2 ESB: Error WSA Action igual a null

Revisando un error que le daba a un cliente luego de seguir un tutorial del año 2012 en el sitio de WSO2 me decidí a postear la solución pues pasa por ser bastante sencilla y les puede ahorrar algunos minutos de su tiempo.

El tutorial lo pueden encontrar en este enlace, y está bastante completo. Incluye los ficheros de configuración tanto del servicio de acceso a datos como de la API en el WSO2 ESB.

En el mismo se aclaran las versiones de las herramientas y esto es importante pues el ESB usando es el 4.0.3 y ya vamos por el 4.8.1, casi que el 4.9.0(este es el que usé en su RC1 para el ajuste).

El error:
Al invocar al método GET del API usando un cliente REST podemos apreciar el error:

Este es un error típico que se nos puede presentar y básicamente consiste en que a partir de la información proporcionada no se puede identificar la operación a invocar en el backend. En este caso falta el WSA Action, que es enviado como null.

Si revisamos la secuencia encargada de crear la petición y enviarla al backend tenemos lo siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<sequence xmlns="http://ws.apache.org/ns/synapse" name="StudentGetInSequence">
    <payloadFactory>
        <format>
            <p:GetStudent xmlns:p="http://ws.wso2.org/dataservice">
                <p:registration_number>$1</p:registration_number>
            </p:GetStudent>
        </format>
        <args>
            <arg xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns3="http://org.apache.synapse/xsd" expression="get-property('uri.var.registrationNumber')"/>
        </args>
    </payloadFactory>
    <send>
        <endpoint key="StudentServiceEndpoint"/>
    </send>
</sequence> 

Esta secuencia debe ser modificada para que incluya el mediador header añadiendo un Action, antes de pasar al mediador send, encargado de enviar la solicitud al backend, quedando entonces de la siguiente manera la secuencia.

<?xml version="1.0" encoding="UTF-8"?>
<sequence xmlns="http://ws.apache.org/ns/synapse" name="StudentGetInSequence">
    <payloadFactory>
        <format>
            <p:GetStudent xmlns:p="http://ws.wso2.org/dataservice">
                <p:registration_number>$1</p:registration_number>
            </p:GetStudent>
        </format>
        <args>
            <arg xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns3="http://org.apache.synapse/xsd" expression="get-property('uri.var.registrationNumber')"/>
        </args>
    </payloadFactory>
 <header name="Action" value="urn:GetStudent"/>
    <send>
        <endpoint key="StudentServiceEndpoint"/>
    </send>
</sequence>


Noten que se ha añadido el header antes del mediador send.

Si volvemos a probar el servicio obtendremos una respuesta válida:

NOTA: para cada secuencia correspondiente a una operación se debe realizar el mismo procedimiento para garantizar que se envía el Action en el request.

martes, 18 de junio de 2013

Uso de XStream en un cliente RESTful para un servicio en WSO2

En otra entrada habíamos visto un ejemplo de consumo de un servicio de datos expuesto como RESTful usando jersey. También habíamos comentado que se podía obtener los valores del XML usando XStream y ese es el objetivo de esta entrada.

Para eso le dejamos el fuente de los 2 proyectos nuevamente  y una imagen de cómo queda el cliente.


Nuevamente les dejo imágenes de las estadísticas en el Dashboard del servicio en el Application Server de WSO2.

Para el consumo del clientes RESTful



Con una demora en el cliente de 43segundos en una primer corrida y 44 en una segunda corrida.


Para el consumo del servicio Axis2.


Con una demora en el cliente de 37segundos en una primera corrida y luego 36 en una segunda.

Además de las recomendaciones de la entrada anterior habría que hacer lo siguiente:
  • Cambiar implementaciones del framework para trabajar con el XML en el ejemplo de REST, tal vez usar JAXB a ver que pasa.
  • Tabular los resultados de diferentes corridas para cada ejemplo y poder sacar estadisticas más claras de los resultados.



En esta entrada quisiera mostrarles como consumir este servicio de acceso a datos RESTful usando la librería Jersey y además una comparativa entre el consumo usando esta variante y la de un cliente axis2.
No es objetivo decir que una variante sea mejor que la otra si no que vean los números y puedan elaborar comparativas más claras en este tema.

Para crear un proyecto que implemente un cliente de un servicio web RESTful con jersey solo basta seguir los siguientes pasos:

Crear un proyecto Maven con el arquetipo “Maven-archetype-quickstart”






En el pom del proyecto creado incluir la dependencia a jersey como pueden ver en esta imagen.


Implementar el cliente como sigue:


Este cliente es realmente sencillo, el parámetro se lo estamos incluyendo en la misma URL del servicio, aunque jersey deja pasarle múltiples parámetros y con diferentes propiedades.
El resultado no lo estamos utilizando para nada, solo lo obtenemos y no extraemos información útil del mismo. Solo basta decir que es un XML y con una librería como XStream se podrían obtener sus valores.

Un ejemplo de resultado es este:



Para la comparativa e implementado un cliente axis2 creando también un proyecto Maven. De hecho lo que hice fue crear un cliente axis2 usando el dashboard del Developers Studio de WSO2 y luego pasé el proyecto a Maven.


El cliente es realmente sencillo:


En este caso como pueden ver no solo obtenemos la respuesta si no que vamos al valor dentro del XML y lo imprimimos en pantalla.
En ambas pruebas hicimos unas 10000 iteraciones para ver cómo se comportaba el tiempo de respuesta. Aclaro que no es una prueba válida ni sujeta a criterios comparativos fiables, es solo la base para que todo el que quiera probar tenga un inicio rápido.

En esta imagen pueden ver el tiempo de respuesta del servicio usando el cliente restful luego de 2 peticiones fallidas y 20019 peticiones válidas.


Como pueden ver el tiempo máximo fue de 121ms y el promedio de respuesta fue de 0.248ms


En esta otra imagen tienen lo mismo pero sumándole 2 llamadas al cliente axis2 del servicio de acceso a datos, recuerden que cada llamada lleva un ciclo dentro.
Como pueden ver el tiempo máximo no se ha excedido y el promedio ha bajado un poco, nada significativo.


Las pruebas fueron realizadas localmente y sería interesante:

  1. Trabajar con el XML obtenido con el cliente RESTful para que se asemeje más al cliente axis2.
  2. Incluir diferentes tamaños de los mensajes de request y response.
  3. Implementar el escenario de forma remota y no local.

Creo que así las pruebas tendrían un poco más de valor para decidirnos qué tipo de cliente usar.

Les adjunto:
Proyecto Maven para el cliente RESTful.
Proyecto Maven para el cliente Axis2.

Espero les sea de utilidad.