Mulesoft / Por

< Volver al curso

Punto de Control 3

En la sección de hoy del punto de control 3 vamos a repasar los conceptos teóricos para poder pasar a las siguientes clases y no perdernos con definiciones que no acabamos 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?

A continuación os muestro un diagrama que representa el Core del ciclo de vida que inicia el diseño de un proyecto Mulesoft:

El cuerpo «Core» del proyecto.

Cuando me refiero al Core, hago referencia a la parte más importante del proyecto y dónde comienza su desarrollo. Y puede que estéis pensando que lo lógico es publicar la API una vez ya está realizada por completo.  Pero…

El nuevo ciclo de diseño presentado por Mulesoft pretende comenzar de fuera hacia adentro. Es decir, primero se decidirá la estructura y el comportamiento de la API antes de comenzar a desarrollar su motor. Ahí entra la función de la API Specification, es el diseño de la interfaz de usuario de la API que emula el comportamiento real que tendrá una vez se implemente el motor, o mejor dicho, la Mule Application.

Este enfoque generalmente se le conoce como enfoque de «diseño primero», por tanto, debe seguir un ciclo de vida de diseño de API que sea óptimo y, además, que proporcione la mejor experiencia cumpliendo las necesidades del usuario. Como resultado, es importante poder hacer esto de una manera legible, así que se utiliza RAML para realizar el diseño y se sirve a través de Exchange-Portal para su consumo de prueba.

Recordad que en las clases de este apartado hemos utilizado datos de ejemplo sin consultar bases de datos reales, ya que directamente se introducían los datos en el RAML NamedExample siguiendo las estructuras de datos definidas en el RAML Datatype.

El ciclo de vida de un proyecto.

Entonces, y para acabar de estructurar cada parte del ciclo de vida del diseño de un proyecto de Mulesoft, la descripción de las fases es la siguiente:

  1. DISEÑO. Identificar los procesos y los requerimientos de negocio. Crear el diseño lógico, la primera estructura, que se tendrá que aprobar para seguir con la siguiente fase.
  2. SIMULACIÓN. Crear el modelo. El RAML incluirá los recursos, métodos, estructura de datos y ejemplos.
  3. FEEDBACK. Publicar la API en el Exchange mediante Mocking Service. Se realizarán pruebas desde la API Console, integrado en el propio portal de la API, y se recibirá el feedback de los desarrolladores.
  4. VALIDACIÓN. Según el feedback proporcionado por los desarrolladores, se realizarán las modificaciones oportunas hasta que finalmente sea validada la API Specification, finalizando el ciclo de diseño.

Una vez explicadas las fases del diseño de una API Specification y habiendo seguido todas las clases de este apartado, ya estáis listos para probar con la tercera prueba y verificar que estáis asimilando los conocimientos necesarios para la certificación.

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 3!

 

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