¡Bienvenido! Seguro que recuerdas el post anterior sobre el enrutamiento simple basado en el contenido del mensaje con Filter Mediator. Pues bien, en esta ocasión planteamos un nuevo ejemplo pero realizando el enrutamiento con Switch Meaditor. Tras la presentación, es momento de seguir aprendiendo sobre ESB. ¡Vamos!
Introducción
Retomando el catálogo de ejemplos de Synapse, hoy vamos a ver cómo funciona el enrutamiento de mensajes basado en su contenido, pero implementando esta integración con el mediador Switch. Recordemos que en el post anterior, el mediador que empleamos era Filter. En el post de hoy nos centraremos en el valor del payload del mensaje.
Los mensajes se enrutan en este ejemplo al mismo punto final. Emplearemos el Switch para añadir al mensaje propiedades dependiendo del valor del payload del mismo. ¿Preparado?
Mediación de Mensaje
-
Enrutamiento Simple Basado en el Contenido (Switch Case Mediator).
El mensaje se envía con el Cliente inteligente Axis2:
ant stockquote -Daddurl=<addressingEPR> -Dtrpurl=<synapse>
La propiedad addurl selecciona el recurso punto final usando la especificación WS-Addressing, así poder almacenar este valor.
En nuestro ejemplo esta propiedad apunta al backed Axis2. El servicio en el backend se expone con el protocolo SOAP. Resulta evidente que esta propiedad del comando stockquote va a formar parte también del valor de la cabecera TO del mensaje, indicando hacia dónde se dirige el mensaje. Mientras que la propiedad trpurl apunta a nuestro querido ESB.
El funcionamiento de la mediación del ESB es el siguiente: Cuando se envía un mensaje al ESB, se recupera el valor de symbol del payload: getQuote/request/symbol
-Seguro que alguna vez lo has pensado… ¿Son los microservices el final de los ESB?-
Según este valor, un mediador Switch cambia el flujo de mediación del mensaje, para añadir una propiedad al mensaje y mostrar este valor con el log mediator. De tal forma que el mensaje se redirecciona al punto final con el valor de la propiedad TO.
En el siguiente gráfico se muestra todo este proceso:
Como comentábamos en el anterior artículo, primero arrancaremos el backend Axis2 y después el ESB. Si tienes dudas podéis leer cómo poder hacer esto con ayuda de los posts anteriores.
Como recordatorio te mostramos donde se encuentra cada componente:
Ruta del servidor Axis2: /wso2esb-4.9.0/samples/axis2Server/
Ruta del cliente Axis2 : /wso2esb-4.9.0/samples/axis2Client/
Ruta de WSO2ESB : /wso2esb-4.9.0/bin
¡Atención!. Resulta muy importante no olvidar usar Eclipse para generar el CAR file con las secuencias y desplegar este archivo en el ESB.
-
Probando el enrutamiento.
Ahora debemos lanzar la petición desde la ruta donde se encuentra el cliente Axis2.
ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/ -Dsymbol=IBM
El log mediator en el inSequence muestra el mensaje de entrada o request:
Como se puede ver en el mensaje la acción que se selecciona es el getQuote, la cual se dirige hacia el punto final, To: http://localhost:9000/services/SimpleStockQuoteService, que es el Axis2 backend,el símbolo en el payload es IBM.
Dentro del ESB, switch mediator busca el valor de symbol:
Ese símbolo coincide con el valor de la primera expresión regular del switch mediator:
Esto hace que el procesamiento de la request o del mensaje pase por este case, y añade una nueva propiedad en el contexto del mensaje, con el nombre symbol.
El siguiente log mediator ,después del switch mediator, imprime el valor de la cabecera To y el valor symbol que se acaba de añadir en el switch.
La información que muestra este log mediator por la línea de comandos es:
symbol = Great stock – IBM,
epr = http://localhost:9000/services/SimpleStockQuoteService
Finalmente aparece el send mediator:
Éste lo que hace es enviar el mensaje al punto final almacenado en la cabecera TO.
El backend recibe el mensaje y muestra esta notification en la pantalla de comandos, tal que así:
-¡Implementa WSO2 paso a paso en tu empresa con nuestra guía!-
La respuesta que envía el backend la muestra el log mediator del outSequence en el ESB:
Como se aprecia en el cuadrado rojo, aparece el valor de la última cotización para el símbolo IBM. Mientras que en el cuadrado azul se muestra que el mensaje corresponde a una respuesta.
El identificador del mensaje o ID es distinto al del mensaje request, dado a que se refiere a otra comunicación entre el backend y el cliente. En este caso es una respuesta, es otro mensaje y otro identificador. No obstante, se corresponde totalmente con el mensaje entrante o request que acabamos de procesar en el ESB anteriormente.
Ahora el mensaje resultante que muestra el cliente de Axis2 es:
Por tanto, queda así completo el circuito petición-respuesta.
-¿Te perdiste el primer post de la saga de ESB? Descubre “Apache Synapse ESB y WSO2”-
Te sugerimos que pruebes con el resto de peticiones para comprobar también las salidas del log mediator en el ESB:
ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/ -Dsymbol=MSFT
En este caso el mensaje request es procesado por el segundo case del switch mediator.
ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/ -Dsymbol=SUN
Por último, como no existe ninguna expresión regular que se corresponda con el símbolo SUN, en este caso el mensaje será procesado por el case default.
Conclusión
Este nuevo post es una extensión del anterior, donde estudiamos el mismo caso de uso, enrutamiento basado en el contenido, pero implementado con el Filter mediator, esta vez está implementado con el Switch mediator y tomando los valores del payload del mensaje.
Tal y como has podido comprobar, el comportamiento es idéntico. En el ejemplo de hoy se añaden unas propiedades en el contexto del mensaje según el símbolo, de tal forma que coincida con la expresión regular del case del Switch mediator, aunque también se podría haber enviado el mensaje a distintos puntos finales según el valor de cada símbolo.
Por tanto, este ejemplo coincide con el patrón de integración Message Routing -> Content-Based Router, como en el artículo anterior.
¡Nos leemos en la siguiente entrega de ESB WSO2!
