SCI + Enterprise messaging, lanzando mensajes al aire (Parte 3)
Final de esta saga de enterprise messaging por el momento. En esta entrada recibiremos los mensajes mandados por el iFlow de la entrada anterior.
Estos mensajes los recibiremos en un iFlow y en un microservicio. Pero, si te perdiste las dos entradas anteriores donde configurábamos en entorno y el servicio.
En el punto en el que estamos, tenemos una o varias colas con mensajes esperando para ser recibidos. Este seria el estatus en el que nos encontraríamos a nivel de Enterprise Messaging.
Tabla resumen de contenido
iFlow (SCI) conectado a la cola de mensajes
Vamos a crear un iFlow que estará atento a la cola de mensajes, esto nos permitirá tener un proceso sin la necesidad de crear un job de lectura de datos por ejemplo.
Aprovechamos el package creado anteriormente y creamos un nuevo iFlow, en este caso yo lo llamaré «receiver»
Y este será la implementación del nuevo iFlow, como vemos utilizaremos el adapter AMQP y un script que nos imprimirá el mensaje:
Vamos a ver cada step en detalle:
- Adapter AMQP: Añadiremos un adaptador con protocolo WebSocket
Como en el anterior ejemplo de envío, los datos de conexión y los tenemos en la key, en este caso buscamos el protocolo «amqp10ws»:
En la ultima pestaña añadimos la cola a escuchar.
- El script nos permitirá ver de manera rápida el contenido del mensaje por pantalla. Este es su código:
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if(messageLog != null){
messageLog.setStringProperty("Logging#1", "Printing Payload As Attachment")
messageLog.addAttachmentAsString("ResponsePayload:", body, "text/plain");
}
return message;
}En este punto ya solo nos queda hacer deploy del iFlow y ver los resultados ya que tenemos mensajes en cola.
Como podemos ver, al deployar el iFlow se han leído los mensajes pendientes. Tambien podemos ver el detalle del mensaje con el resultado de la ejecución del script.
En caso de volver a deployar el iFlow para el envio de mensajes podemos ver que el iFlow sigue escuchando la cola y recibe los mensajes.
Recibiendo mensajes con microservices
Ahora que ya tenemos la cola funcionado y hemos visto como los mensajes se envia y se procesan, vamos a ver como nuestros microservicios también pueden estar escuchando estas colas.
Para ello, deployaremos en nuestra subaccount una aplicación en node.js que recibirá los mensajes y los añadirá al log.
Para deployar nuestra aplicación, accedemos al Business Application Studio y cargaremos la siguiente aplicación:
Lo primero, una vez subido a nuestro entorno BAS ejecutamos el comando de instalación de las librerías node.js. En el terminal ejecutamos el comando:
npm installUna vez instaladas las librerías vamos a ver los puntos mas importantes del servicio que vamos a deployar:
- Indicamos el Topic a filtrar en el código del server:
- En el manifest, hacemos binding de nuestra aplicación con el servicio de enterprise messaging (línia 7) y la cola a escuchar (línia 10).
Es momento de hacer deploy. Por lo que vamos al terminal de nuevo y ejecutamos el comando para hacer deploy:
cf pushNota: si te aparece un fallo al hacer el deploy puede ser que sea porque no has hecho login en la plataforma CF. Para ello acuérdate de ejecutar el comando CF login 😉
Una vez tengamos el servicio desplegado, vamos a ver su detalle:
En el detalle de la aplicación tenemos la ruta de nuestra aplicación. Accedemos a la aplicación para conectarla a la cola:
Al acceder a la URL, vemos los botones de conexión y desconexión, vamos a pulsar en Connect y nos aparecerá el mensaje que indicara que se ha conectado.
Una vez conectado, volvemos al log y veremos como se han recibido los mensajes pendientes.
Tambien podremos ver que la cola se ha vaciado de mensajes.
Ya tenemos todo el ciclo de envio de mensajes completos. Como veis, este servicio nos permite realizar conexiones de manera asynchrony y descentralizada. En este sentido, lo que nos permite este tipo de arquitectura es no tener que mantener conexiones punto a punto mediante llamadas a los endpoints de los distintos sistemas implicados.
Otro punto importante es que nos permite tener el dato en tiempo real a todas las aplicaciones que esten escuchado el servicio.
Os dejo un par de links para ampliar la información. El primero es el que inspira esta serie, como mandar mensajes des de SCPI a una aplicación node, aunque la aplicación ha sido modificada para que funcione con el trial y para salvar algunos errores de librerías. El segundo nos permite conectar un sistema ABAP a las colas.
https://blogs.sap.com/2020/07/01/how-to-use-sap-s-4hana-event-enablement-with-sap-cloud-platform-en/
Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última
