Mulesoft / Por

< Volver al curso

Punto de Control 4

En la sección de hoy del punto de control 4, 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?

Lo primero de todo, recomiendo que realicéis todos los puntos de control (el 4 cuando acabéis de leer la sección), para repasar los conocimientos y verificar que los habéis asimilado correctamente.

Si lleváis al día las clases, sabréis que AnyPoint Studio nos ha servido para diseñar nuestra Mule Application en local, sin necesitar una conexión a Internet ni depender de la nube de Mulesoft, AnyPoint Platform.

Lo tiene todo, salvo un Exchange, ya que la finalidad de la misma es publicar una API, y en local, pierde sentido.

Pero, vamos a repasar que hemos hecho con AnyPoint Studio:

  • Importar una API Specification de AnyPoint Platform.
  • Crear, diseñar y modificar una Mule Application.
  • Manipular la estructura de datos que nos llega de una base de datos MySQL, transformando el formato JAVA que nos llega a JSON.
  • Realizar acciones desde la Mule Application sobre una base de datos MySQL, aunque algunas estén capadas por falta de permisos.
  • Fusionar una API Specification con una Mule Application, el esqueleto y su motor.
  • Llamar a un Flow de una Mule Application desde una API Specification.
  • Desplegar una Mule Application y una API Specification gracias a Mule Runtime, el servidor Mule Standalone que incorpora el propio AnyPoint Studio. Si queréis saber más sobre Mule Standalone revisad la entrada Mulesoft Standalone 3.8.1 en Windows y Linux Server.
  • Probar la Mule Application y la API Specification gracias a API Console.
  • Llevar un control de versiones de las API Specification gracias a GIT Staging.
  • Subir los cambios a la nube, Exchange y Design Center de AnyPoint Platform gracias a APISync.

Cuando fusionamos nuestra Mule Application con la API Specification de AnyPoint Platform, en la primera clase se utilizó el método de copiar y pegar los componentes que había en el Flow de la Mule Application por cada método que había creado en la API Specification, más concretamente en el RAML.

Eso es un procedimiento bastante lento, pero nos sirve para ver 2 cosas:

  1. La API Specification crea un Flow por cada método que hay definido en el RAML. Revisad la clase Fusionar API Spec y Mule App en Anypoint Studio, donde se explica lo que sucede y cómo funciona.
  2. Esto es igual cuando se crea una Mule Application y se realiza un Flow para cada método (no necesariamente todos los Flows son métodos, pero esto se verá más adelante). Esto es porque la finalidad de la API Specification es definir el esqueleto de la futura API, la Mule Application lleva a cabo esas acciones, es el motor que las ejecuta y contiene toda la lógica de la aplicación. Por lo tanto, es lógico y necesario que contengan los mismos métodos.

A partir de la necesidad de unificar nuestra API Specification con nuestra Mule Application, ¿existe otra forma que no sea copiando y pegando?

Existe una, a Mulesoft no se le iba a pasar esto, el componente Flow Reference, que permite enrutar un Flow hacia otro, incluso si se encuentra en otro archivo de configuración. El primer archivo de configuración sería donde están los Flows de la API Specification y el segundo archivo donde están los de la Mule Application.

Y, ¿cómo se queda entonces un Flow de la API Specification?

¿Qué solitario verdad?

Un Flow básico está distribuido por un Event Source, uno o varios Event Processors y uno o varios Errors Handling, en la clase Crear una Mule Application en AnyPoint Studio con MYSQL está explicado detalladamente.

En el caso del Flow de la imagen solamente tenemos un Event Processor, el Flow Reference, con esto podemos verificar que esta es la configuración mínima para que un Flow compile en una Mule Application o API Specification.

Otra pregunta que nos surge ante esa imagen es, ¿cómo se puede llamar a este método sin un Listener que proporcione la URL para ser llamado?

Aquí juega un papel muy importante el Flow de APIkit, donde aparte de redirigirnos hacia los Flows que se han definido en el RAML, también contiene un Listener que nos proporciona el recurso, o la URL para realizar las llamadas.

En el siguiente diagrama podéis observar la configuración para obtener la URL o URI base.

Si os fijáis en el diagrama anterior, en General – Path, está definido «/api/*», eso quiere decir que todos los nombres que se incluyan después del recurso estarán incluidos. En el siguiente diagrama podéis observar la configuración del método GET llamando al recurso Flights.

 

En la configuración del Flow de GET está definido en el nombre el método y el recurso. Esta configuración la hereda del RAML, en la clase que he mencionado antes Crear una Mule Application en AnyPoint Studio con MYSQL también está explicado y tenéis un diagrama donde compara los Flows con el código RAML de la API Specification.

Una vez explicado todo lo que se ha realizado en este bloque sobre AnyPoint Studio, ya estáis listos para probar con la cuarta prueba y verificar que estáis asimilando los conocimientos necesarios para la certificación.

Espero que os haya gustado el primer nivel para ser desarrollador de Mulesoft y vamos a darle caña al punto de control 4.

¡Nos vemos en el siguiente nivel!

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 punto de control 4!

 

Solamente sabréis todas las respuestas correctas si sacáis un 10.

Vamos a por la nota perfecta ¿no?

Mucha suerte, aunque no deberíais necesitarla 🙂

Nombre
Introduce tu correo para que puedas ver el resultado de tu prueba

 

Clases del curso

< Volver al curso