WSO2 ESB + IBM MQ:Escenario REQUEST/RESPONSE.

En una entrada anterior veíamos como crear proxys en el WSO2 ESB para escribir y leer mensajes de colas creadas en IBM MQ, y habíamos quedado en que mostraríamos como implementar un escenario request/response:

Los pasos identificados en la imagen anterior son los siguientes:

1. Al WSO2 ESB llega un mensaje a través de un API.
2. La API envía el mensaje a una cola en el IBM MQ. La cola es SMSStore.
3. El proxy que está escuchando en la cola del punto 2, recupera el mensaje en su secuencia de entrada.
4. El mensaje es enviado al servicio backend, desplegado en el WSO2 AS.
5. La respuesta generada por el backend es enviada al proxy.
6. La respuesta del punto 5 es puesta en una cola de respuesta, indicada en la configuración del endpoint del punto 2.
7. La API recupera el mensaje puesto en la cola de respuesta. La cola de respuesta es SMSReceiveNotificationStore.
8. El mensaje es enviado de vuelta al cliente.

Veamos la API como queda:

<?xml version="1.0" encoding="UTF-8"?>
<api xmlns="http://ws.apache.org/ns/synapse"
     name="CustomersAPI"
     context="/Customers">
   <resource methods="POST GET" uri-template="/getCustomer*">
      <inSequence>   
   <property action="remove" name="TRANSPORT_HEADERS" scope="axis2"/>     
         <send>
            <endpoint>
               <address uri="jms:/SMSStore?transport.jms.ConnectionFactoryJNDIName=myQueueConnectionFactory&java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory&java.naming.provider.url=file:/C:/JNDI-Directory&transport.jms.DestinationType=queue&transport.jms.ReplyDestination=SMSReceiveNotificationStore&transport.jms.ConnectionFactoryType=queue&transport.jms.ContentTypeProperty=contentType"/>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
     <property action="remove" name="TRANSPORT_HEADERS" scope="axis2"/> 
  <send/>
      </outSequence> 
   </resource> 
</api>

El proxy que es invocado indirectamente(escucha en la cola donde se pone el mensaje) por la API es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="CustomerProxy"
       transports="jms"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target faultSequence="fault">
      <inSequence>
        <log level="full"/>        
         <send>
            <endpoint>
               <address uri="http://localhost:9765/jaxrs_basic/services/customers/customerservice/customers">
                  <suspendOnFailure>
                     <errorCodes>-1</errorCodes>
                     <progressionFactor>1.0</progressionFactor>
                  </suspendOnFailure>
                  <markForSuspension>
                     <errorCodes>-1</errorCodes>
                  </markForSuspension>
               </address>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
        <log level="full"/>   
        <property name="Content-Length" scope="transport" action="remove"/>
        <property name="Content-Type" scope="transport" action="remove"/>
         <send/>
      </outSequence>
   </target>
   <parameter name="transport.jms.ContentType">
      <rules>
         <jmsProperty>contentType</jmsProperty>
         <default>text/xml</default>
      </rules>
   </parameter>
   <parameter name="transport.jms.ConnectionFactory">myQueueConnectionFactory</parameter>
   <parameter name="transport.jms.DestinationType">queue</parameter>
   <parameter name="transport.jms.Destination">SMSStore</parameter>
   <description/>
</proxy>

La invocación al API se realiza usando el plugin de firefox RESTClient:

De esta manera queda definido cómo se puede establecer una comunicación entre distintos componentes de la suite de wso2, en un escenario request/response, con colas involucradas las cuales han sido creadas en el IBM MQ.

Esperamos les sea de utilidad.

Read More [...]

Posted in API, ESB, IBM MQ, websphere, WSO2

WSO2 ESB: publicando y leyendo mensajes en IBM MQ.

En la entrada anterior vimos como configurar el IBM MQ y los ajustes a realizar en el WSO2 ESB para integrarse con el IBM MQ.

En esta entrada veremos la configuración de 2 proxies. Uno para escribir un mensaje en la cola y otro para leer el mensaje de la cola.

Servicio proxy para enviar un mensaje XML a una cola en IBM MQ:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="testMQsender" 
                      transports="http"
                      startOnLoad="true"
                      trace="disable">
  <description/>
  <target>
  <endpoint>
  <address uri="jms:/myQueueRecieve?transport.jms.ConnectionFactoryJNDIName=myQueueConnectionFactory&java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory&java.naming.provider.url=file:/C:/JNDI-Directory&transport.jms.DestinationType=queue&transport.jms.ConnectionFactoryType=queue&transport.jms.Destination=myQueueRecieve"/>
  </endpoint>
  <inSequence>
  <log level="custom">
     <property name="ESTADO" value="Mensaje enviado a la cola myQueueRecieve"/>
  </log>
  <property name="OUT_ONLY" value="true"/>
  <property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
  <property name="Accept-Encoding" scope="transport" action="remove"/>
  <property name="Content-Length" scope="transport" action="remove"/>
  <property name="User-Agent" scope="transport" action="remove"/>
  <property name="Content-Type" scope="transport" action="remove"/>
  <property name="Transfer-Encoding" scope="transport" action="remove"/>
  </inSequence>
  <outSequence/>
    <sequence name="fault">
        <log level="full">
            <property name="MESSAGE" value="Executing default fault sequence"/>
            <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
            <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
        </log>
        <drop/>
    </sequence>      
   </target>
   <parameter name="transport.jms.ConnectionFactory">myQueueConnectionFactory</parameter>
   </proxy>

NOTAS:

1. Se agrega la propiedad OUT_ONLY como true para indicar que es una operación de un solo sentido.
2. En el caso de los mensajes de un solo sentido y que son JMS no se devuelve por defecto el código 202, hay que indicarle al ESB que lo retorne al cliente usando la propiedad FORCE_SC_ACCEPTED.
3. Las propiedades en el scope de transporte se eliminan siempre que incluyan el caracter – en su nombre, pues el IBM MQ cumple con la especificación que indica que no se puede usar dicho caracter en el nombre de las propiedades.

Antes de poner el mensaje en cola, podemos ver que en el Explorer MQ el estado de las colas es el siguiente:




Luego de poner el mensaje en la cola invocando al servicio y enviandole un payload XML:



En la cola se ve que la profundidad ahora es 1.



Si exploramos en la cola, veremos el mensaje.



Y en el ESB veremos el log:




Para consumir un mensaje de la cola el servicio proxy es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="testMQrecieve" 
    transports="jms" 
    startOnLoad="true">
    <description/>    
 <target>
  <inSequence>
  <log level="custom">
     <property name="ESTADO" value="Leyendo mensaje de la cola myQueueRecieve"/>
  </log>  
   <property name="OUT_ONLY" value="true"/>
   <log level="full"/>
   <drop/>
  </inSequence>
  <outSequence/>
    <sequence name="fault">
        <log level="full">
            <property name="MESSAGE" value="Executing default fault sequence"/>
            <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
            <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
        </log>
        <drop/>
    </sequence>  
 </target>
 <parameter name="transport.jms.ContentType">
  <rules>
   <jmsProperty>contentType</jmsProperty>
   <default>application/xml</default>
  </rules>
 </parameter>
 <parameter name="transport.jms.ConnectionFactory">myQueueConnectionFactory</parameter>
 <parameter name="transport.jms.DestinationType">queue</parameter>
 <parameter name="transport.jms.Destination">myQueueRecieve</parameter>
</proxy>

NOTAS:

1. De esta configuración lo más interesante es el parámetro transport.jms.ContentType donde especificamos que será application/xml.
2. Este proxy no es necesario iniciarlo con una llamada, pues automaticamente está escuchando en la cola myQueueRecieve y cuando detecta un mensaje invoca a la secuencia de entrada.

El log en el ESB es el siguiente:



En la siguiente entrada veremos como implementar estas funcionalidades en un solo proxy REQUEST/RESPONSE.

Read More [...]

Posted in ESB, IBM MQ, websphere, WSO2

Integración entre WSO2 ESB e IBM MQ 7

Muchas grandes empresas tienen entre su portafolio de productos los ESB de Oracle o IBM, los han usado por años para el desarrollo de sus backend y para la gestión de su negocio. Hasta hace unos 10 años atrás no existía un ESB capaz de satisfacer las demandas que permitieron que ESB como el de Oracle o IBM sacaran una buena tajada del mercado de soluciones de integración empresarial, pero con la llegada de WSO2 esto ha ido cambiando poco a poco. Y es que además de ser opensource, con un modelo de negocios que si funciona para los bolsillos, permite realizar muchas de las soluciones que las grandes empresas de hoy necesitan y que estaban implementadas hasta el momento bien en el bus de Oracle o en el de IBM.

En esta entrada estaremos mostrando los pasos para dejar un ambiente listo para probar las funcionalidades del WSO2 ESB de conjunto con el IBM WebSphere 7.5.0.1. La idea es que una vez montado el ambiente podamos ir trabajando en distintos escenarios que nos permitan mostrarles a los fans de WSO2 como se puede proponer una migración de un broker como el de IBM a soluciones más ligeras como WSO2 ESB.
Precondiciones:

1. Tener instalado y ejecutándose el broker de IBM. En este caso usamos la versión 7.5.0.1
2. Tener el WSO2 ESB más actualizado. Preferiblemente la versión 4.9.0 RC1 descargada de su repo de github.

Pasos a seguir:

Paso 1: Crear un nuevo gestor de colas en el broker usando el IBM WebSphere Explorer.



Le pondremos como nombre myQueueManager y además lo marcaremos como el predeterminado.



Daremos clic en Siguiente:


Clic en Siguiente:



Y aquí vean como marcamos  que se iniciara luego de creado, que fuera automático para que inicie con el sistema y además marcamos la opción de Crear un canal de conexión con el servidor.
Damos clic en Siguiente:



Y aquí hemos seleccionado “Crear escucha configurado para TCP/IP”  en el puerto 1415.
Nuevamente damos clic en siguiente:



Ya hemos terminado la configuración del nuevo gestor de colas, así que damos clic en Finalizar.

Paso 2: Creación de las colas.
En este paso es donde vamos a crear las colas. Para el fin de esta entrada solo crearemos una pero es el mismo proceso de este paso para las restantes colas que quieran crear.
Lo primero es ir al nuevo gestor de colas, dar clic derecho en Colas, seleccionar Nuevo y luego Cola local.

 

La cola a crear se llama myQueue:



Damos clic en Siguiente:



Y luego clic en Finalizar.
Aquí ya la cola está creada, yo seguí este mismo paso para las restantes colas y ahora mi gestor de colas luce así.



Paso 3: Crear el canal de conexión con el servidor.
Este paso es muy fácil, damos clic derecho en Canales, luego seleccionamos Nuevo, luego seleccionamos “Canal de conexión con el servidor” y le damos clic.



El nombre del canal será “myChannel”.

 

Damos clic en Siguiente:



Seleccionamos como Protocolo de transmisión TCP, si no está por defecto. Damos clic en Finalizar y eso es todo. De esta manera también se nos crea una escucha en el puerto 1415, como pueden ver a continuación.



Paso 4: Creación de los objetos administrados.
Nos vamos a la opción “Objetos administrados de JMS” damos clic derecho y seleccionamos “Añadir contexto inicial”.



Marcamos la opción Sistema de archivos, veremos que se configura una clase de fábrica, en este caso RedFSContextFactory.
Como Directorio de enlace usamos la ubicación “C:\JNDI-Directory\” donde al terminar se creará un fichero .bindings donde estarán las configuraciones para la conexión con el broker de IBM.



Damos clic en siguiente y marcamos las opciones como se muestran a continuación:



Damos clic en Finalizar y ya tendremos creado el contexto inicial al cual debemos agregarle ahora la fábrica de conexiones y los destinos.

Para la fábrica de conexiones seleccionamos la opción “Fábrica de Conexiones” damos clic derecho, seleccionamos Nuevo y damos clic en “Fábrica de conexiones”:



Como nombre de la fábrica usaremos “MyQueueConnectionFactory”:

 

Damos clic en Siguiente:



Seleccionamos el tipo mostrado en la imagen y Nuevamente clic en Siguiente:



Aquí seleccionamos el transporte “Cliente MQ” y damos clic en Siguiente:



Volvemos a dar clic en siguiente y comprobamos que el puerto sea el 1415:



Ahora damos clic en Finalizar y veremos lo siguiente:



Lo siguiente a realizar es configurar los destinos, que tendrán el mismo nombre de la cola creada anteriormente. Para fines de esta entrada solo crearemos uno.
Seleccionamos “Destinos”, damos clic derecho y seleccionamos “Nuevo”, seleccionamos “Destino” y damos clic.



En la siguiente ventana definimos el nombre del destino y el tipo, en este caso “Cola”:



Damos clic en Siguiente:



En la siguiente ventana debemos definir el gestor de cola y la cola asociada, tal como se muestra en las siguientes imágenes.



Seleccionamos el gestor, y luego la Cola:



Quedaría como sigue:



Damos clic en Finalizar y el destino se verá como sigue:

 

Paso 5: Configurar el WSO2 ESB.
En la raíz del ESB debemos crear una carpeta que se llame mq y dentro copiaremos los siguientes jars:

• com.ibm.mq.jar
• com.ibm.mq.headers.jar
• com.ibm.mq.jmqi.jar
• com.ibm.mqjms.jar
• dhbcore.jar
• fscontext.jar
• providerutil.jar

Luego iremos al fichero wso2server.bat o .sh y agregaremos la siguiente línea:
set CARBON_CLASSPATH=.\mq\com.ibm.mq.jar;.\mq\com.ibm.mqjms.jar;.\mq\com.ibm.mq.jmqi.jar;.\mq\dhbcore.jar;.\mq\fscontext.jar;.\mq\providerutil.jar;.\mq\com.ibm.mq.headers.jar;%CARBON_CLASSPATH%
Como se muestra en la siguiente imagen.

Ahora realizaremos la configuración del axis2, que se localiza en [ESB_HOME]\repository\conf\axis2\axis2.xml

NOTA: Como ya les comentaba al inicio estamos usando el WSO2 ESB wso2esb-4.9.0-RC1-SNAPSHOT.

Lo primero en este fichero es agregar un transportReceiver:

<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
 <parameter name="myQueueConnectionFactory" locked="false">
  <parameter name="java.naming.factory.initial" locked = "false">com.sun.jndi.fscontext.RefFSContextFactory</parameter>
  <parameter name="java.naming.provider.url" locked="false">file:/C:/JNDI-Directory</parameter>
  <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">MyQueueConnectionFactory</parameter>
  <parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
  <parameter name="transport.jms.JMSSpecVersion">1.0</parameter>
 </parameter>

 <parameter name="default" locked="false">
  <parameter name="java.naming.factory.initial" locked = "false">com.sun.jndi.fscontext.RefFSContextFactory</parameter>
  <parameter name="java.naming.provider.url" locked="false">file:/C:/JNDI-Directory</parameter>
  <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">MyQueueConnectionFactory</parameter>
  <parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
  <parameter name="transport.jms.JMSSpecVersion">1.0</parameter>
 </parameter>
 </transportReceiver> 
 

Y luego agregar un transportSender:

<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender">
 <parameter name="myQueueConnectionFactory" locked="false">
  <parameter name="java.naming.factory.initial" locked = "false">com.sun.jndi.fscontext.RefFSContextFactory</parameter>
  <parameter name="java.naming.provider.url" locked="false">file:/C:/JNDI-Directory/</parameter>
  <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">MyQueueConnectionFactory</parameter>
  <parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
  <parameter name="transport.jms.JMSSpecVersion">1.0</parameter>
 </parameter>

 <parameter name="default" locked="false">
  <parameter name="java.naming.factory.initial" locked = "false">com.sun.jndi.fscontext.RefFSContextFactory</parameter>
  <parameter name="java.naming.provider.url" locked="false">file:/C:/JNDI-Directory/</parameter>
  <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">MyQueueConnectionFactory</parameter>
  <parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
  <parameter name="transport.jms.JMSSpecVersion">1.0</parameter>      
 </parameter>
 </transportSender>  
  

Paso 6: Prueba en el ESB.


En la primera corrida del ESB nos debe dar un error como este:





[2015-08-23 22:21:39,458]  WARN - JMSListener Error connecting to JMS.

com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').


Y podemos apreciar que es un problema de autorización en el broker. Si seguimos revisando los logs veremos lo siguiente:


[2015-08-23 22:21:39,490] ERROR - JMSListener Unable to continue server startup as it seems the JMS Provider is not yet started. Please start the JMS provider now.
[2015-08-23 22:21:39,490] ERROR - JMSListener Connection attempt : 3 for JMS Provider failed. Next retry in 80 seconds

Lo interesante es que aunque queramos cerrar el ESB como lo hacemos siempre, no será posible. Deberemos tumbar el proceso para que concluya esta tarea pues de lo contrario cae en un ciclo, aunque se digan que ya estaba resuelto este bug.

La solución al error de autorización es la siguiente:

1. Abrimos como administrador la consola del IBM Integration.
2. Ejecutamos el comando runmqsc myQueueManager
3. Ejecutamos el comando ALTER QMGR CHLAUTH(DISABLED)
4. Ejecutamos el comando REFRESH SECURITY TYPE(AUTHSERV)

De esta manera deshabilitamos la seguridad.

Volvemos a iniciar el ESB y ya lo hace de manera satisfactoria.


Ahora probaremos con un servicio proxy que estará escuchando en la cola “myQueue” e imprimirá en consola el payload puesto en dicha cola.


El proxy es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="testMQrecieve" 
    transports="jms" 
    startOnLoad="true">
    <description/>    
 <target>
  <inSequence>
   <property name="OUT_ONLY" value="true"/>
   <log level="full"/>
   <drop/>
  </inSequence>
  <outSequence/>
    <sequence name="fault">
        <log level="full">
            <property name="MESSAGE" value="Executing default fault sequence"/>
            <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
            <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
        </log>
        <drop/>
    </sequence>  
 </target>
 <parameter name="transport.jms.ContentType">
  <rules>
   <jmsProperty>contentType</jmsProperty>
   <default>application/xml</default>
  </rules>
 </parameter>
 <parameter name="transport.jms.ConnectionFactory">myQueueConnectionFactory</parameter>
 <parameter name="transport.jms.DestinationType">queue</parameter>
 <parameter name="transport.jms.Destination">myQueue</parameter>
</proxy>

El payload usado es el siguiente:

<ESBMQmsg>Hola WSO2 ESB, hasta la vista IIB!!!!</ESBMQmsg>

Debe ser puesto el mensaje en la cola myQueue y se verá la salida en el WSO2 ESB, lo que nos confirma que el ESB leyó correctamente de la cola y que usa el mensaje obtenido.

[2015-08-23 22:49:49,372]  INFO - LogMediator To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: ID:414d51206d7951756575654d616e61679865da5520021b03, Direction: request, Envelope: 

<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>           
      <ESBMQmsg>Hola WSO2 ESB, hasta la vista IIB!!!!</ESBMQmsg>
  </soapenv:Body>
</soapenv:Envelope>

Esperen próximas configuraciones y escenarios para ir reemplazando el IIB por el WSO2 ESB.

Read More [...]

Posted in ESB, IBM MQ, JMS, websphere, WSO2