Punto de Control 2
En el punto de control 2 vamos a repasar los conceptos teóricos para poder pasar al siguiente nivel y no perderos con definiciones que no acabáis de entender. Ya sé que la teoría es un rollo, pero voy a intentar que no se os atragante con algún que otro dibujito. ¿Os parece?.
En este bloque hemos aprendido a manipular y a controlar el estado de los datos de un evento de Mule. Esto es importantísimo, ya que la finalidad de realizar una integración con Mulesoft es la transformación de los datos, que se obtienen de un origen y se presentan a un destino con el formato indicado.
Por lo tanto, saber en todo momento lo que está sucediendo en nuestra Mule Application y poder jugar o hacer malabares con estos datos, será clave a la hora de desarrollar en un futuro.
A continuación muestro un esquema básico de los componentes de una Mule Application que utilizaré para relacionarlo con lo aprendido en este módulo:
Y aquí un pequeño resumencillo del bloque haciendo referencia al diagrama anterior…
Los breakpoints.
Primero atacaremos a los puntos rojos que observamos en los componentes, que pueden ser, Event Processors o Event Source, cómo explique en la clase Transformando datos en una Mule Application.
Estos puntos, llamados Breakpoints, nos permiten ver los datos del evento pausándolo o interrumpiéndolo. Esto nos permitirá analizar el contenido del evento (Message, Payloads, variables y atributos) cuando tenemos la aplicación en modo Debug, explicado en la clase Debugging de una Mule Application.
Creación del evento.
Cuando se realice una solicitud a nuestra Mule Application, mediante la URL que proporciona el componente HTTP Listener, este creará un evento nuevo (por eso el nombre Event Source).
Podemos encontrar los Event Processor que definen los valores de las variables y de los Payload. El primero nos salvará los datos al realizar llamadas a otro sistema, con HTTP Request, y el segundo será el componente que contenga los datos de salida de la Mule Application.
El componente Logger nos servirá para poder definir los Logs de nuestra Mule Application, con tal de facilitar la trazabilidad de la aplicación a la hora de buscar fallos e incongruencia de datos en el evento de Mule.
Solicitando información a otro recurso.
Por otra parte, tenemos el componente de oro en este bloque, HTTP Request. Este Event Processor nos permite realizar llamadas a otras APIs (sistemas) y obtener datos de respuesta que se almacenarán en el Payload del evento, machacando los atributos y Payloads del Flow que veis (por eso recurrimos a las variables).
El nuevo lenguaje llamado DataWeave.
Finalmente, hemos aprendido a utilizar el lenguaje que nos permite obtener los datos del evento de Mule, DataWeave, aquí dejo unas expresiones de ejemplo:
- message.attributes.queryParams.nombre
- ‘Bye Bye’ ++ ‘ ‘++ message.attributes.queryParams.nombre
- payload
Espero que os haya gustado este bloque y el nivel 2 del curso de Mulesoft, y ahora, os dejo un pequeño test del punto de control 2 para validar vuestros conocimientos y poder seguir dándole caña.
Si quieres saber más o necesitas ayuda personalizada, puedes suscribirte a mis servicios en el siguiente enlace
➡️ SUSCRIBIRSE A INGENIERO BINARIO ⬅️
¡Ponte a prueba con el test del punto de control 2!
Clases del curso
- 1. Desplegar una aplicación de Mule en CloudHub (10:54)
- 2. Crear una API Proxy en AnyPoint Platform (11:10)
- 3. Aplicar políticas en una API Proxy (14:46)
- 4. Solicitar accesos SLA a una API Proxy (15:51)
- 5. Solicitar identificarse a los usuarios con RAML (20:31)
- Punto de Control 1
- 6. Ver datos de un evento de Mule (11:42)
- 7. Debug de una Mule Application (10:20)
- 8. Datos Evento Mule con HTTP Request (09:27)
- 9. Manipular datos de un evento con DataWeave (09:30)
- 10. Almacenar datos de un evento en variables (12:26)
- Punto de Control 2