Blog!

Busqueda de información

¿Cómo convertir un proceso de negocio que no es síncrono en uno que sí lo es?

Ratio: 4 / 5

Inicio activadoInicio activadoInicio activadoInicio activadoInicio desactivado
 

 

Cada día es más común la necesidad de integrar procesos síncronos, asíncronos, unidireccionales, etcétera, con variantes en el requerimiento de petición y respuesta, donde a veces el cliente solicitante necesita la respuesta en el mismo canal de petición o bien la respuesta debe ser asíncrona.


Cuando un proceso se conforma de diversas interacciones entre servicios, donde éstos son una combinación de servicios síncronos, asíncronos o unidireccionales y además se requiere una respuesta síncrona, Oracle Service Bus es la mejor solución para resolver este problema de integración con la ayuda de JMS.


Supongamos que tenemos un proceso que consta de varios servicios unidireccionales, donde la interacción es como la que se muestra a continuación:


Y por definición de negocio el proceso puede finalizar en cualquier punto si ocurre algún error y además el cliente que inicia el flujo necesita recibir la respuesta con el error o el éxito del proceso.


Con OSB y JMS podemos ‘simular’ lo ilustrado anteriormente como un proceso síncrono, para lo cual es necesario configurar los siguientes recursos en el servidor de Weblogic:


Una vez creado nuestro proyecto OSB, crearemos dos Servicios de Negocio:

005 03
El Servicio de Negocio SyncRequest tendrá la definición de las colas de petición y respuesta y es quien se encargará de proporcionar la sincronía, es decir, al cliente en el mismo canal de petición le proporcionará la respuesta de error o éxito del proceso. Su configuración se muestra en la siguiente imagen:

005 04

005 05

El Servicio de Negocio SyncResponse tendrá la definición de la cola ResponseQueue y se encargará de encolar el mensaje de respuesta del procesamiento. Su configuración a continuación:

 

005 06

Los Servicios de Proxy que necesitamos para nuestro proyecto son los siguientes:

005 07
El proxy SyncRequestPS es el que será invocado por el cliente y donde se iniciará el procesamiento. En la siguiente imagen se muestra su configuración:

005 08

Dentro del flujo de este proxy sólo se redirecciona al Servicio de Negocio SyncRequest, con esta acción el mensaje de petición del cliente se encolará en la RequestQueue.

005 09
Ahora lo que necesitamos es iniciar el flujo del procesamiento, desencolando el mensaje de la RequestQueue y enviándolo al Servicio A.

005 10

El proxy que realizará tal tarea es el DequeueSyncRequestPS, con la siguiente configuración:

005 11

Dentro del flujo del proxy, se encuentra la invocación al Servicio A enviando el mensaje:

005 12
Importante mencionar que para correlacionar los mensajes de petición y respuesta es necesario utilizar una propiedad de JMS, en este ejemplo el CorrelationID, que tiene que viajar en el mensaje a lo largo de todo el proceso.

Una vez que inicia el proceso en el Servicio A, pueden ocurrir dos cosas:

  1. Se genera una excepción y se informa al cliente del error o
  2. Continúa el flujo en el siguiente servicio, en este caso el Servicio B.

De acuerdo al diagrama donde se muestra la interacción entre los distintos servicios, la notificación de error será enviada desde el Servicio donde haya ocurrido (A, B, C ... N) y la notificación de éxito se enviará únicamente desde el Servicio N, siendo el proxy AsyncResponsePS el que será invocado tanto para el error como para el éxito.

En el caso de que ocurra un error en el Servicio A, dentro de éste se debe invocar nuestro último Servicio de Proxy: AsyncResponsePS.

005 13
Donde el flujo del proxy AsyncResponsePS es el siguiente:

005 14
Del mensaje enviado por el servicio de donde se esté generando la respuesta, por ejemplo el Servicio A, se extrae el CorrelationID en una variable, digamos responseRelatesTo (dentro del stage ST_GetCorrelationID) y finalmente direccionamos al Servicio de Negocio que tiene la configuración de la ResponseQueue:

005 15

Como se puede observar en la imagen anterior, vemos que se agrega la propiedad JMSCorrelationID como cabecera de transporte.


Finalemente nuestro proceso quedaría como se ilustra en la siguiente imagen:

005 16

 

Y es así como podemos lograr que un proceso sea síncrono aun cuando por su naturaleza no pueda serlo.

 

Cualquier duda o comentario es bienvenido.

Contáctanos a info[at]baware.com.mx o a ngarcia[at]baware.com.mx

Log in