martes, 23 de junio de 2015

WSO2 API Manager. Nueva versión.





image


El equipo de WSO2 acaba de liberar la versión 1.9 del API Manager.

Entre las principales funcionalidades que ofrece esta nueva versión se encuentran:
  1. Soporte de servidores key de terceros.
  2. Adopción de Swagger como el lenguaje base para la descripción de las APIs, con un editor de Swagger 2.0 embebido.
  3. Vista compartida de las aplicaciones y subscripciones para usuarios dentro de una misma organización.

Luego volveremos sobre esta nueva versión de la herramienta para mostrar las funcionalidades incorporadas.

sábado, 13 de junio de 2015

WSO2 Certified ESB 4 Developer.


Colegas seguidores de WSO2:
Les recomiendo tomar los cursos de chakray.com en español si desean mejorar su dominio de esta excelente Suite.

Acabo de participar en uno desarrollado en esta semana que finaliza y ha sido una excelente experiencia. Al terminar pueden realizar un examen y certificarse, tal como hicimos un grupo de colegas desarrolladores SOA y yo.

Aquí les dejo la evidencia :-D 


martes, 12 de mayo de 2015

Critical Security Update for WSO2 Identity Server


Según un correo de WSO2, han identificado una vulnerabilidad en las versiones 4.5.0, 4.6.0 y 5.0.0 de la herramienta WSO2 Identity Server que luego de ejecutar determinadas acciones sobre el servicio UserIdentityManagementAdminService permitirían resetear la contraseña de otro usuario de la herramienta, obteniendo acceso a su cuenta.
Se han desarrollado 3 parches para solucionar este problema
  • IS 4.5.0: WSO2-CARBON-PATCH-4.2.0-1268
  • IS 4.6.0: WSO2-CARBON-PATCH-4.2.0-1270
  • IS 5.0.0: WSO2-CARBON-PATCH-4.2.0-1235
Es altamente recomendable que todos aquellos que usen estas versiones del IS en sus desarrollos o despliegues ejecuten dichos parches.

lunes, 20 de abril de 2015

WSO2 BPS: Uso de un ForEach en BPEL.


En una entrada anterior realizamos una introducción al desarrollo de procesos con BPEL y la suite de WSO2 a través de un escenario simple que involucraba el consumo de varias operaciones de servicios web externos desde un BPEL.
En esta entrada, para continuar con los temas de BPEL y la suite de WSO2, mostraremos como implementar un escenario de un poco más de complejidad que involucra utilizar un iterador para realizar determinada lógica de negocio.
La descripción del escenario es la siguiente:
Se tiene acceso a un servicio web que dado el nombre de una persona devuelve:
  • nombre.
  • apellido.
  • listado con los ID de las direcciones relacionadas con esta persona.
Para obtener la información completa de una dirección se tiene acceso a otro servicio web que dado el ID de una dirección devuelve:
  • calle.
  • numero.
  • prov.

Se desea exponer a través de un servicio la información completa de una persona de manera tal que contenga los datos personales del usuario y un listado con los datos completos de sus direcciones asociadas.
Para implementar este escenario bien podríamos usar el WSO2 ESB, pero en este caso en particular usaremos el WSO2 BPS para demostrar el uso del componente iterador.

En la siguiente imagen mostramos la implementación visual del proceso.

UsuariosDireccionProcess

Al proceso le llega como entrada el nombre del usuario, por lo que esta información es asignada a la variable de entrada usada para invocar al servicio UsuariosData.
A continuación inicializamos 2 variables: una contendrá un elemento de tipo Direccion para almacenar la dirección que retorne la invocación del segundo servicio,pues esta se pierde en el ForEach, mientras que la segunda variable será de tipo un arreglo de Direccion para almacenar el listado de direcciones asociadas a un usuario. La respuesta de la invocación al segundo servicio no se inserta directamente en este arreglo pues primero debe pasar por una transformación ya que no coinciden los nombres de los elementos.
Teniendo la respuesta de la primera invocación al servicio UsuariosData podemos usar el componente ForEach e iterar por cada ID de direccion que exista, tal y como se muestra a continuación.


image
Usando esta expresión XPATH:
count($UsuariosDataPLResponse.parameters/Usuarios[1]/idDirecciones/idDireccion)
Podemos contar la cantidad de ID contenidos en la respuesta y ese será el valor final de nuestro ForEach.
Lo que sigue es básico:
  • Guardamos el valor del ID actual.
  • Asignamos este ID al request de la invocación al servicio DireccionUsuario.
  • La respuesta de este servicio la asignamos a la variable DirOK, que es de tipo direccion.
  • Insertamos esta variable como último elemento del listado de direcciones, que se ha creado en la variable listadoDirecciones.
Este último punto lo mostramos en la siguiente imagen pues se hace uso de una función xpath especifica de Apache ODE.


image

Consideraciones finales.
  1. La implementación del proceso es bastante fácil de lograr, y sigue una línea que se ajusta bastante a como se podría implementar con Oracle BPEL.
  2. El IDE aun tiene sus pequeños bugs…en determinamos momentos me movió secciones de código del inicio para el final o no me reconocía las variables con los tipos de datos que le asociaba, es cosa de cerrar y volver a abrir el .bpel.
  3. La expresión xpath de ODE no es reconocida y da un warning, aunque funciona sin problema.
  4. Se detectó un ¿bug? de Apache ODE que pueden ver comentado y con un work around en este enlace. La solución propuesta es realmente simple y fácil de implementar.
  5. A la implementación actual le falta aun el manejo de errores, lo cual será incorporado en una siguiente entrada.
  6. También incorporaremos la posibilidad de recibir en la invocación al servicio UsuariosData, varios usuarios en vez de solo uno.

A pesar de los problemas antes mencionados y teniendo en cuenta la fácil integración del WSO2 BPS con el resto de las herramientas de la suite de WSO2, es factible el uso de la misma para la implementación de BPEL de pequeña o mediana complejidad. Ya para implementaciones que requieran de transformaciones y mapeos muy grandes no creo que sea muy productiva como digamos el BPEL de Oracle con su automapping incluido.

El fuente del proyecto, que incluye los WSDL de los servicios BE se encuentra en este repo.

martes, 31 de marzo de 2015

WSO2 BPS: Introducción a BPEL con el Developer Studio.

Como parte de una serie de trabajos relacionados con BPEL y WSO2 les dejo este primer documento introductorio al desarrollo de procesos de negocio.



martes, 3 de marzo de 2015

WSO2 ESB: creando una API REST tonta en 1 minuto.

image

Este es un escenario que se nos puede dar en cualquier desarrollo, bien sea en una PoC o como parte de un desarrollo ágil donde necesitamos consumir un servicio REST y no tenemos tiempo para implementar algo desde 0.

Digamos que requimos un servicio que se consulte a través de la siguiente URL:
http://localhost:8281/DummyRESTService/orders

Y queremos que nos devuelva:
{"Order":{"additions":"Milk","drinkName":"Vanilla Flavored Coffee","locked":false,"orderId":123}}


Esta sería su implementación:


<?xml version="1.0" encoding="UTF-8"?>
<api xmlns="http://ws.apache.org/ns/synapse"
     name="DummyRESTService"
     context="/DummyRESTService">
   <resource methods="GET" url-mapping="/orders" faultSequence="fault">
      <inSequence>
         <payloadFactory media-type="json">
            <format>{"Order":{"additions":"Milk","drinkName":"Vanilla Flavored Coffee","locked":false,"orderId":123}}</format>
            <args/>
         </payloadFactory>
         <log>
            <property name="JSON-Payload" expression="json-eval($.)"/>
         </log>
         <property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
         <property name="messageType"
                   value="application/json"
                   scope="axis2"
                   type="STRING"/>
         <respond/>
      </inSequence>
   </resource>
</api>


Se usa el mediador payloadfactory en su configuración para JSON y dentro de los tags de format se especifica el  JSON que se requiere sea devuelto por el servicio.


Como ven solo hay que cambiar el payload y claro ajustar el nombre, contexto y la url de mapeo.


Importante notar la propiedad NO_ENTITY_BODY la cual permite no enviar el cuerpo de la respuesta, solo los encabezados. Así que se toma como action = remove.


Si se quiere probar se puede usar el firefox con su plugin RESTClient:


image


O usando curl:


image Y listo. Eso es todo.


Tomada la solución de:


http://ruchirawageesha.blogspot.com/2012/07/wso2-esb-sending-dummy-response.html
http://stackoverflow.com/questions/28572800/how-to-implement-a-dummy-rest-api-in-wso2-esb

lunes, 23 de febrero de 2015

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”.

image

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.

image


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

image




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:

image

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:

image


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

image
image


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.

image



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.

image

Sus configuraciones son realmente sencillas. La de clientes es:

image


Y la de insertarCiente es:

image


Paso 4: Probar por REST.

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

image

También lo podemos probar desde el SOAPUI:

image 

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

image

Y luego por el cliente REST de firefox:

image

Vean que se insertaron Cliente7 y Cliente8.

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

image 

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

Esperamos les sea de utilidad.

WSO2 MB: Enviando y recibiendo mensajes con JMS.

image

En esta entrada queremos mostrarles como usar el WSO2 Message Broker para enviar y recibir mensajes usando las colas JMS desde Java.

Para los códigos de enviar un mensaje a una cola en el WSO2 MB y para leer de la cola, hacemos uso de los ejemplos entregados por WSO2 en la documentación de la herramienta.

En el MB tenemos una cola creada como se muestra a continuación:

image

El nombre de la cola es QueueMB1, por lo que debe ser revisado en el código, y el puerto que se está usando para conectarse a la consola web del WSO2 MB es el 9447 lo que nos indica que el Offset es de 4, por lo que también debe ser ajustado en el código de las clases que envían y reciben los mensajes.

El proyecto con las clases usadas lo pueden obtener de este enlace.

Resultado de la ejecución de la clase QueueSender en el MB para 100 mensajes:

image
image

Resultado de la ejecución de la clase QueueSender en el IDE:

image


Resultado de la ejecución de la clase QueueReceiver en el MB:

image


Resultado en el IDE:

image

De esta manera estamos seguros que el WSO2 MB 2.2.0 funciona para el envío y recepción de mensajes desde JAVA y seguramente desde otros sistemas, como puede ser el WSO2 ESB.

sábado, 21 de febrero de 2015

WSO2 BPS: Desarrollando un proceso de negocio en la práctica.

En esta entrada quiero mostrarles como combinar distintas herramientas de WSO2 para desarrollar un proceso de negocio usando BPEL. Las herramientas son:
  1. WSO2 AS: para el despliegue de los servicios backend.
  2. WSO2 Developer Studio: para el desarrollo de los servicios backend en axis2 y para el desarrollo del proceso usando BPEL.
  3. WSO2 BPS: para el despliegue del proceso BPEL.

Para ello he desarrollado este tutorial que les guiará detalladamente a lo largo del proceso, paso a paso.

Esperamos les sea de utilidad.

En otras entradas usaremos un proceso más cercano a la realidad para incorporarle nuevas funcionalidades.

martes, 3 de febrero de 2015

Configurando la suite de WSO2 con Oracle.


Todos los productos de WSO2 pueden ser configurados muy facilmente para usar distintos gestores de BD como:
  1. MySQL.
  2. Oracle.
  3. PostgreSQL.
  4. …..
Nosotros por lo general usamos PostgreSQL en nuestros desarrollos, pero también hacemos uso de Oracle DB cuando nuestros clientes así lo desean, por esta razón quiero mostrarles como configurar el WSO2 MB 2.2.0 para usar una BD en Oracle.

Paso 1: Usar el asistente de Oracle dbca para crear una BD. En nuestro caso la BD se llama dbmb.
Aquí es importante que los ficheros tnsnames.ora y listener.ora estén correctamente configurados para no tener problemas en la creación y el acceso a la BD.

Paso 2: Conectarnos a Oracle usando el comando:
sqlplus sysadmin/[tu contraseña] as sysdba
image

Paso 3: conectarse a la instancia usando el comando connect, si no están conectados ya. Crear el usuario y conectarse con este usuario.
image

Paso 4:  Crear una sesión y  ejecutar un commit.
image

Paso 5: Configurar el fichero [MB-HOME]\repository\conf\datasources\master-datasources.xml para que se conecte a la BD creada y configurada en los pasos anteriores.
<datasource>
 <name>WSO2_CARBON_DB</name>
 <description>The datasource used for registry and user manager</description>
 <jndiConfig>
  <name>jdbc/WSO2CarbonDB</name>
 </jndiConfig>
 <definition type="RDBMS">
  <configuration>
   <url>jdbc:oracle:thin:@localhost:1521/dbmb</url>
   <username>dbgreg</username>
   <password>dbgreg</password>
   <driverClassName>oracle.jdbc.driver.OracleDriver</driverClassName>
   <maxActive>50</maxActive>
   <maxWait>60000</maxWait>
   <testOnBorrow>true</testOnBorrow>
   <validationQuery>SELECT 1</validationQuery>
   <validationInterval>30000</validationInterval>
  </configuration>
 </definition>
</datasource>


Paso 6: Copiar el driver de Oracle para [MB-HOME]\repository\components\lib\ en nuestro caso el driver es ojdbc6.jar.


Paso 7: Iniciar el servidor de la siguiente manera: wso2server.bat o .sh  y el parámetro  -Dsetup para que nos cree las tablas en la BD.


image


Y eso es todo. De esta manera tenemos configurada cualquier herramienta de WSO2, en este caso el WSO2 Message Broker 2.2.0, para que use como BD a Oracle.