MuleSoft - Guía rápida

ESB significa Enterprise Service Busque es básicamente una herramienta de middleware para integrar varias aplicaciones juntas sobre una infraestructura similar a un bus. Fundamentalmente, es una arquitectura diseñada para proporcionar un medio uniforme de mover el trabajo entre aplicaciones integradas. De esta forma, con la ayuda de la arquitectura ESB podemos conectar diferentes aplicaciones a través de un bus de comunicación y permitir que se comuniquen sin depender unas de otras.

Implementación de ESB

El enfoque principal de la arquitectura ESB es desacoplar los sistemas entre sí y permitir que se comuniquen de manera constante y controlable. La implementación de ESB se puede realizar con la ayuda de‘Bus’ y ‘Adapter’ de la siguiente manera -

  • El concepto de "bus", que se logra a través de un servidor de mensajería como JMS o AMQP, se utiliza para desacoplar diferentes aplicaciones entre sí.

  • El concepto de “adaptador”, responsable de comunicarse con la aplicación backend y transformar los datos del formato de la aplicación al formato del bus, se utiliza entre las aplicaciones y el bus.

Los datos o mensajes que pasan de una aplicación a otra a través del bus tienen un formato canónico, lo que significa que habría un formato de mensaje coherente.

El adaptador también puede realizar otras actividades como seguridad, monitoreo, manejo de errores y administración de enrutamiento de mensajes.

Principios rectores de ESB

Podemos llamar a estos principios como principios básicos de integración. Son los siguientes:

  • Orchestration - Integración de dos o más servicios para lograr la sincronización entre datos y proceso.

  • Transformation - Transformar datos de formato canónico a formato específico de la aplicación.

  • Transportation - Manejo de negociación de protocolos entre formatos como FTP, HTTP, JMS, etc.

  • Mediation - Proporcionar múltiples interfaces para admitir múltiples versiones de un servicio.

  • Non-functional consistency - Proporcionar mecanismo para gestionar transacciones y seguridad también.

Necesidad de ESB

La arquitectura ESB nos permite integrar diferentes aplicaciones donde cada aplicación puede comunicarse a través de ella. A continuación se muestran algunas pautas sobre cuándo utilizar ESB:

  • Integrating two or more applications - El uso de la arquitectura ESB es beneficioso cuando existe la necesidad de integrar dos o más servicios o aplicaciones.

  • Integration of more applications in future - Supongamos que si queremos agregar más servicios o aplicaciones en el futuro, entonces se puede hacer fácilmente con la ayuda de la arquitectura ESB.

  • Using multiple protocols - En caso de que necesitemos utilizar varios protocolos como HTTP, FTP, JMS, etc., ESB es la opción correcta.

  • Message routing - Podemos usar ESB en caso de que necesitemos un enrutamiento de mensajes basado en el contenido del mensaje y otros parámetros similares.

  • Composition and consumption - ESB se puede utilizar si necesitamos publicar servicios para composición y consumo.

Integración P2P frente a integración ESB

Con el aumento en el número de aplicaciones, una gran pregunta frente a los desarrolladores era cómo conectar diferentes aplicaciones. La situación se manejó codificando manualmente una conexión entre varias aplicaciones. Se llamapoint-to-point integration.

Rigidityes el inconveniente más obvio de la integración punto a punto. La complejidad aumenta con el mayor número de conexiones e interfaces. Las desventajas de la integración P-2-P nos llevan a la integración ESB.

ESB es un enfoque más flexible para la integración de aplicaciones. Encapsula y expone la funcionalidad de cada aplicación como un conjunto de capacidades reutilizables discretas. Ninguna aplicación se integra directamente con otra, sino que se integran a través de un ESB como se muestra a continuación:

Para gestionar la integración, ESB tiene los siguientes dos componentes:

  • Service Registry- Mule ESB cuenta con Service Registry / Repository donde se publican y registran todos los servicios expuestos en el ESB. Actúa como un punto de descubrimiento desde donde se pueden consumir los servicios y capacidades de otras aplicaciones.

  • Centralized Administration - Como su nombre lo indica, proporciona una vista de los flujos transaccionales de desempeño de las interacciones que ocurren dentro del ESB.

ESB Functionality- La abreviatura VETRO se utiliza generalmente para resumir la funcionalidad de ESB. Es como sigue:

  • V(Validar): como su nombre lo indica, valida la validación del esquema. Requiere un analizador de validación y un esquema actualizado. Un ejemplo es un documento XML que confirma un esquema actualizado.

  • E(Enriquecer): agrega datos adicionales a un mensaje. El propósito es hacer que el mensaje sea más significativo y útil para un servicio objetivo.

  • T(Transformar) - Convierte la estructura de datos a un formato canónico o de un formato canónico. Algunos ejemplos son la conversión de fecha / hora, moneda, etc.

  • R(Enrutamiento): enrutará el mensaje y actuará como guardián del punto final de un servicio.

  • O(Operar): el trabajo principal de esta función es invocar el servicio de destino o interactuar con la aplicación de destino. Corren en el backend.

El patrón VETRO proporciona flexibilidad general a la integración y asegura que solo los datos consistentes y validados serán enrutados a través del ESB.

¿Qué es Mule ESB?

Mule ESB es una plataforma de integración y bus de servicio empresarial (ESB) basada en Java, ligera y altamente escalable, proporcionada por MuleSoft. Mule ESB permite al desarrollador conectar aplicaciones de forma fácil y rápida. Independientemente de las diversas tecnologías utilizadas por las aplicaciones, Mule ESB permite una fácil integración de las aplicaciones, lo que les permite intercambiar datos. Mule ESB tiene las siguientes dos ediciones:

  • Edición de la comunidad
  • Edición de Empresa

Una ventaja de Mule ESB es que podemos actualizar fácilmente de la comunidad Mule ESB a la empresa Mule ESB porque ambas ediciones se basan en una base de código común.

Características y capacidades de Mule ESB

Mule ESB posee las siguientes características:

  • Tiene un diseño gráfico simple de arrastrar y soltar.
  • Mule ESB es capaz de mapear y transformar datos visuales.
  • El usuario puede obtener la facilidad de cientos de conectores certificados prefabricados.
  • Seguimiento y administración centralizados.
  • Proporciona sólidas capacidades de aplicación de la seguridad empresarial.
  • Proporciona la facilidad de gestión de API.
  • Hay una puerta de enlace de datos segura para la conectividad en la nube o en las instalaciones.
  • Proporciona el registro de servicios donde se publican y registran todos los servicios expuestos en el ESB.
  • Los usuarios pueden tener el control a través de una consola de administración basada en web.
  • La depuración rápida se puede realizar mediante el analizador de flujo de servicios.

Las motivaciones detrás del proyecto Mule fueron:

  • para simplificar las cosas a los programadores,

  • la necesidad de una solución liviana y modular que pudiera escalar desde un marco de mensajería a nivel de aplicación a un marco altamente distribuible en toda la empresa.

Mule ESB está diseñado como un marco programático y orientado a eventos. Está controlado por eventos porque se combina con una representación unificada de mensajes y se puede expandir con módulos conectables. Es programático porque los programadores pueden implantar fácilmente algunos comportamientos adicionales, como el procesamiento de mensajes específicos o la transformación de datos personalizados.

Historia

La perspectiva histórica del proyecto Mule es la siguiente:

Proyecto SourceForge

El proyecto Mule se inició como el proyecto SourceForge en abril de 2003, y después de 2 años se lanzó su primera versión y se trasladó a CodeHaus. La API de Objeto de mensaje universal (UMO) era el núcleo de su arquitectura. La idea detrás de la API de UMO era unificar la lógica y mantenerlos aislados de los transportes subyacentes.

Versión 1.0

Fue lanzado en abril de 2005 y contenía numerosos transportes. El enfoque clave de muchas otras versiones seguidas fue la depuración y la adición de nuevas funciones.

Versión 2.0 (adopción de Spring 2)

Spring 2 como marco de configuración y cableado se adoptó en Mule 2, pero resultó ser una revisión importante debido a la falta de expresividad de la configuración XML requerida. Este problema se resolvió cuando se introdujo la configuración basada en esquemas XML en Spring 2.

Construyendo con Maven

La mayor mejora que simplificó el uso de Mule, tanto en el desarrollo como en la implementación, fue el uso de Maven. A partir de la versión 1.3, se empezó a construir con Maven.

MuleSource

En 2006, MuleSource se incorporó "para ayudar a respaldar y habilitar a la comunidad en rápido crecimiento que usa Mule en aplicaciones empresariales de misión crítica". Resultó ser el hito clave para Mule Project.

Competidores de Mule ESB

A continuación se muestran algunos de los principales competidores de Mule ESB:

  • WSO2 ESB
  • Bus de servicio de Oracle
  • WebSphere Message Broker
  • Plataforma Aurea CX
  • Fiorano ESB
  • Pasarela de WebSphere DataPower
  • Marco de procesos empresariales de Workday
  • Bus de servicio empresarial de Talend
  • Bus de servicio empresarial JBoss
  • Gerente de servicios iWay

Concepto básico de Mule

Como se ha comentado, Mule ESB es una plataforma de integración y bus de servicios empresariales (ESB) basada en Java ligera y altamente escalable. Independientemente de las diversas tecnologías utilizadas por las aplicaciones, Mule ESB permite una fácil integración de aplicaciones, lo que les permite intercambiar datos. En esta sección, discutiremos sobre el concepto central de Mule que entra en juego para hacer que dicha integración suceda.

Para ello, necesitamos comprender su arquitectura y los componentes básicos.

Arquitectura

La arquitectura de Mule ESB tiene tres capas, a saber, capa de transporte, capa de integración y capa de aplicación, como se muestra en el siguiente diagrama:

En general, existen los siguientes tres tipos de tareas que se pueden realizar para configurar y personalizar la implementación de Mule:

Desarrollo de componentes de servicio

Esta tarea implica el desarrollo o la reutilización de los POJO existentes o Spring Beans. POJOs es una clase con atributos que genera los métodos get y set, conectores en la nube. Por otro lado, Spring Beans contiene la lógica empresarial para enriquecer los mensajes.

Orquestación de servicios

Esta tarea básicamente brinda el servicio de mediación que implica configurar el procesador de mensajes, enrutadores, transformadores y filtros.

Integración

La tarea más importante de Mule ESB es la integración de varias aplicaciones independientemente de los protocolos que estén utilizando. Para ello, Mule proporciona métodos de transporte que permiten recibir y enviar los mensajes en varios conectores de protocolo. Mule admite muchos métodos de transporte existentes, o también podemos usar un método de transporte personalizado.

Bloques de construcción

La configuración de Mule tiene los siguientes bloques de construcción:

Frijoles de primavera

El uso principal de Spring beans es construir un componente de servicio. Después de construir el componente de servicio de Spring, podemos definirlo a través de un archivo de configuración o manualmente, en caso de que no tenga un archivo de configuración.

Agentes

Básicamente es un servicio creado en Anypoint Studio antes que Mule Studio. Se crea un agente una vez que inicia un servidor y se destruirá una vez que lo detenga.

Conector

Es un componente de software configurado con los parámetros específicos de los protocolos. Se utiliza principalmente para controlar el uso de un protocolo. Por ejemplo, un conector JMS está configurado con unConnection y este conector será compartido entre varias entidades encargadas de la comunicación real.

configuración global

Como su nombre lo indica, este bloque de construcción se utiliza para establecer las propiedades y configuraciones globales.

Puntos finales globales

Se puede usar en la pestaña Elementos globales, que se puede usar tantas veces en un flujo:

Procesador de mensajes global

Como su nombre lo indica, observa o modifica un mensaje o flujo de mensajes. Los transformadores y filtros son ejemplos de Procesador de mensajes global.

Transformers- El trabajo principal de un transformador es convertir datos de un formato a otro. Se puede definir globalmente y se puede utilizar en múltiples flujos.

Filters- Es el filtro que decidirá qué mensaje de Mule se debe procesar. El filtro básicamente especifica las condiciones que deben cumplirse para que un mensaje se procese y se enrute a un servicio.

Modelos

A diferencia de los agentes, es una agrupación lógica de servicios que se crean en Studio. Tenemos la libertad de iniciar y detener todos los servicios dentro de un modelo específico.

Services- Los servicios son los que envuelven nuestra lógica o componentes de negocio. También configura enrutadores, puntos finales, transformadores y filtros específicamente para ese servicio.

Endpoints- Puede definirse como un objeto en el que los servicios recibirán mensajes entrantes y salientes (enviarán). Los servicios están conectados a través de puntos finales.

Fluir

El procesador de mensajes utiliza flujos para definir un flujo de mensajes entre un origen y un destino.

Estructura del mensaje de mula

Un mensaje de Mule, totalmente envuelto en Mule Message Object, son los datos que pasan a través de aplicaciones a través de los flujos de Mule. La estructura del mensaje de Mule se muestra en el siguiente diagrama:

Como se ve en el diagrama anterior, Mule Message consta de dos partes principales:

Encabezamiento

No son más que los metadatos del mensaje que además están representados por las siguientes dos propiedades:

Inbound Properties- Estas son las propiedades que configura automáticamente la fuente del mensaje. No pueden ser manipulados ni configurados por el usuario. En la naturaleza, las propiedades entrantes son inmutables.

Outbound Properties- Estas son las propiedades que contienen metadatos como una propiedad de entrada y se pueden configurar durante el curso del flujo. Pueden ser configurados automáticamente por Mule o manualmente por un usuario. En la naturaleza, las propiedades salientes son mutables.

Las propiedades de salida se convierten en propiedades de entrada cuando el mensaje pasa del punto final de salida de un flujo al punto final de entrada de un flujo diferente a través de un transporte.

Las propiedades de salida siguen siendo propiedades de salida cuando el mensaje se pasa a un nuevo flujo a través de una ref de flujo en lugar de un conector.

Carga útil

El mensaje comercial real transportado por el objeto de mensaje se denomina carga útil.

Variables

Puede definirse como los metadatos definidos por el usuario sobre un mensaje. Básicamente, las variables son piezas temporales de información sobre un mensaje que utiliza la aplicación que lo está procesando. No está destinado a transmitirse junto con los mensajes a su destino. Son de tres tipos, como se indica a continuación:

Flow variables - Estas variables se aplican solo al flujo en el que existen.

Session variables - Estas variables se aplican a todos los flujos dentro de la misma aplicación.

Record variables - Estas variables se aplican solo a los registros procesados ​​como parte de un lote.

Archivos adjuntos y carga adicional

Estos son algunos metadatos adicionales sobre la carga útil del mensaje que no necesariamente aparecen siempre en el objeto del mensaje.

En los capítulos anteriores, hemos aprendido los conceptos básicos de Mule ESB. En este capítulo, aprendamos cómo instalarlo y configurarlo.

Prerrequisitos

Necesitamos satisfacer los siguientes requisitos previos antes de instalar Mule en nuestra computadora:

Kit de desarrollo de Java (JDK)

Antes de instalar MULE, verifique que tenga una versión compatible de Java en su sistema. Se recomienda JDK 1.8.0 para instalar Mule con éxito en su sistema.

Sistema operativo

Los siguientes sistemas operativos son compatibles con Mule:

  • MacOS 10.11.x
  • HP-UX 11iV3
  • AIX 7.2
  • Servidor de Windows 2016
  • Servidor Windows 2012 R2
  • Windows 10
  • Windows 8.1
  • Solaris 11.3
  • RHEL 7
  • Ubuntu Server 18.04
  • Kernel de Linux 3.13+

Base de datos

No se requiere un servidor de aplicaciones o una base de datos, ya que Mule Runtime se ejecuta como un servidor independiente. Pero si necesitamos acceder a un almacén de datos o queremos utilizar un servidor de aplicaciones, se pueden utilizar los siguientes servidores de aplicaciones o bases de datos compatibles:

  • Oracle 11g
  • Oracle 12c
  • MySQL 5.5+
  • IBM DB2 10
  • PostgreSQL 9
  • Derby 10
  • Microsoft SQL Server 2014

Requisitos del sistema

Antes de instalar Mule en su sistema, debe cumplir con los siguientes requisitos del sistema:

  • CPU de al menos 2 GHz o 1 CPU virtual en entornos virtualizados
  • Mínimo 1 GB de RAM
  • Almacenamiento mínimo de 4 GB

Descarga Mule

Para descargar el archivo binario de Mule 4, haga clic en el enlace https://www.mulesoft.com/lp/dl/mule-esb-enterprise y lo llevará a la página web oficial de MuleSoft de la siguiente manera:

Al proporcionar los detalles necesarios, puede obtener el archivo binario de Mule 4 en formato Zip.

Instalar y ejecutar Mule

Ahora, después de descargar el archivo binario de Mule 4, descomprímalo y configure una variable de entorno llamada MULE_HOME para el directorio Mule dentro de la carpeta extraída.

Por ejemplo, la variable de entorno, en entornos Windows y Linux / Unix, se puede configurar para la versión 4.1.5 en el directorio de Descargas de la siguiente manera:

Entornos de Windows

$ env:MULE_HOME=C:\Downloads\mule-enterprise-standalone-4.1.5\

Entornos Unix / Linux

$ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.1.5/

Ahora, para probar si Mule se está ejecutando en su sistema sin ningún error, use los siguientes comandos:

Entornos de Windows

$ $MULE_HOME\bin\mule.bat

Entornos Unix / Linux

$ $MULE_HOME/bin/mule

Los comandos anteriores ejecutarán Mule en el modo de primer plano. Si Mule se está ejecutando, no podemos emitir ningún otro comando en la terminal. Prensadoctrl-c comando en la terminal, detendrá a Mule.

Iniciar servicios Mule

Podemos iniciar Mule como un servicio de Windows y también como un demonio de Linux / Unix.

Mule como servicio de Windows

Para ejecutar Mule como un servicio de Windows, debemos seguir los pasos a continuación:

Step 1 - Primero, instálelo con la ayuda del siguiente comando -

$ $MULE_HOME\bin\mule.bat install

Step 2 - Una vez instalado, podemos ejecutar mule como un servicio de Windows con la ayuda del siguiente comando:

$ $MULE_HOME\bin\mule.bat start

Mule como demonio de Linux / Unix

Para ejecutar Mule como un demonio de Linux / Unix, debemos seguir los pasos a continuación:

Step 1 - Instálelo con la ayuda del siguiente comando -

$ $MULE_HOME/bin/mule install

Step 2 - Una vez instalado, podemos ejecutar mule como un servicio de Windows con la ayuda del siguiente comando -

$ $MULE_HOME/bin/mule start

Example

El siguiente ejemplo inicia Mule como un demonio de Unix:

$ $MULE_HOME/bin/mule start
MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.1.5
MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.1.5
Starting Mule Enterprise Edition...
Waiting for Mule Enterprise Edition.................
running: PID:87329

Implementar aplicaciones de Mule

Podemos implementar nuestras aplicaciones Mule con la ayuda de los siguientes pasos:

Step 1 - Primero, inicia Mule.

Step 2 - Una vez que Mule se inicia, podemos implementar nuestras aplicaciones Mule moviendo nuestros archivos de paquete JAR al apps directorio en $MULE_HOME.

Servicios de Stop Mule

Nosotros podemos usar stopcomando para detener a Mulo. Por ejemplo, el siguiente ejemplo inicia Mule como un demonio de Unix:

$ $MULE_HOME/bin/mule stop
MULE_HOME is set to /Applications/mule-enterprise-standalone-4.1.5
MULE_BASE is set to /Applications/mule-enterprise-standalone-4.1.5
Stopping Mule Enterprise Edition...
Stopped Mule Enterprise Edition.

También podemos usar removecomando para eliminar el Mule Service o Daemon de nuestro sistema. El siguiente ejemplo elimina Mule como un demonio de Unix:

$ $MULE_HOME/bin/mule remove
MULE_HOME is set to /Applications/mule-enterprise-standalone-4.1.5
MULE_BASE is set to /Applications/mule-enterprise-standalone-4.1.5
Detected Mac OSX:
Mule Enterprise Edition is not running.
Removing Mule Enterprise Edition daemon...

Anypoint Studio de MuleSoft es fácil de usar IDE (integration development environment)utilizado para diseñar y probar aplicaciones Mule. Es un IDE basado en Eclipse. Podemos arrastrar conectores fácilmente desde la paleta Mule. En otras palabras, Anypoint Studio es un IDE basado en Eclipse para el desarrollo de flujo, etc.

Prerrequisitos

Necesitamos cumplir con los siguientes requisitos previos antes de instalar Mule en todos los sistemas operativos, es decir, Windows, Mac y Linux / Unix.

Java Development Kit (JDK)- Antes de instalar Mule, verifique que tenga una versión compatible de Java en su sistema. Se recomienda JDK 1.8.0 para instalar correctamente Anypoint en su sistema.

Descarga e instalación de Anypoint Studio

El procedimiento para descargar e instalar Anypoint Studio en diferentes sistemas operativos puede variar. A continuación, hay pasos que se deben seguir para descargar e instalar Anypoint Studio en varios sistemas operativos:

En Windows

Para descargar e instalar Anypoint Studio en Windows, debemos seguir los pasos a continuación:

Step 1 - Primero, haga clic en el enlace https://www.mulesoft.com/lp/dl/studio y elija el sistema operativo Windows de la lista descendente para descargar el estudio.

Step 2 - Ahora, extráigalo en el ‘C:\’ carpeta raíz.

Step 3 - Abra el Anypoint Studio extraído.

Step 4- Para aceptar el espacio de trabajo predeterminado, haga clic en Aceptar. Recibirá un mensaje de bienvenida cuando se cargue por primera vez.

Step 5 - Ahora, haga clic en el botón Comenzar para usar Anypoint Studio.

En OS X

Para descargar e instalar Anypoint Studio en OS X, debemos seguir los pasos a continuación:

Step 1 - Primero, haga clic en el enlace https://www.mulesoft.com/lp/dl/studio y descarga el estudio.

Step 2- Ahora, extráelo. En caso de que esté utilizando la versión del sistema operativo Sierra, asegúrese de mover la aplicación extraída a/Applications folder antes de lanzarlo.

Step 3 - Abra el Anypoint Studio extraído.

Step 4- Para aceptar el espacio de trabajo predeterminado, haga clic en Aceptar. Recibirá un mensaje de bienvenida cuando se cargue por primera vez.

Step 5 - Ahora, haga clic en Get Started para utilizar Anypoint Studio.

Si va a utilizar una ruta personalizada a su espacio de trabajo, tenga en cuenta que Anypoint Studio no expande la tilde ~ utilizada en los sistemas Linux / Unix. Por lo tanto, se recomienda utilizar la ruta absoluta al definir el espacio de trabajo.

En Linux

Para descargar e instalar Anypoint Studio en Linux, debemos seguir los pasos a continuación:

Step 1 - Primero, haga clic en el enlace https://www.mulesoft.com/lp/dl/studio y elija el sistema operativo Linux de la lista descendente para descargar el estudio.

Step 2 - Ahora, extráelo.

Step 3 - A continuación, abra el Anypoint Studio extraído.

Step 4- Para aceptar el espacio de trabajo predeterminado, haga clic en Aceptar. Recibirá un mensaje de bienvenida cuando se cargue por primera vez.

Step 5 - Ahora, haga clic en el botón Comenzar para usar Anypoint Studio.

Si va a utilizar una ruta personalizada a su espacio de trabajo, tenga en cuenta que Anypoint Studio no expande la tilde ~ utilizada en los sistemas Linux / Unix. Por lo tanto, se recomienda utilizar la ruta absoluta al definir el espacio de trabajo.

También se recomienda instalar GTK versión 2 para utilizar temas de Studio completos en Linux.

Características de Anypoint Studio

A continuación se presentan algunas características de Anypoint Studio que mejoran la productividad al crear aplicaciones Mule:

  • Proporciona una ejecución instantánea de la aplicación Mule dentro de un tiempo de ejecución local.

  • Anypoint Studio nos brinda un editor visual para configurar archivos de definición de API y dominios Mule.

  • Tiene un marco de prueba unitario integrado que mejora la productividad.

  • Anypoint Studio nos proporciona el soporte integrado para implementar en CloudHub.

  • Tiene la capacidad de integrarse con Exchange para importar plantillas, ejemplos, definiciones y otros recursos de otra organización de Anypoint Platform.

Los editores de Anypoint Studio nos ayudan a diseñar nuestras aplicaciones, API, propiedades y archivos de configuración. Junto con el diseño, también nos ayuda a editarlos. Contamos con el editor de archivos de configuración de Mule para tal fin. Para abrir este editor, haga doble clic en el archivo XML de la aplicación en/src/main/mule.

Para trabajar con nuestra aplicación, tenemos las siguientes tres pestañas en el editor de archivos de configuración de Mule.

La pestaña Flujo de mensajes

Esta pestaña ofrece una representación visual del flujo de trabajo. Básicamente contiene un lienzo que nos ayuda a comprobar visualmente nuestros flujos. Si desea agregar procesadores de eventos de la paleta Mule en el lienzo, simplemente arrastre y suelte y se reflejará en el lienzo.

Al hacer clic en un procesador de eventos, puede obtener la vista de propiedades de Mule con los atributos del procesador seleccionado. También podemos editarlos.

La pestaña Elementos Globales

Esta pestaña contiene los elementos de configuración global de Mule para los módulos. En esta pestaña podemos crear, editar o eliminar archivos de configuración.

La pestaña Configuración XML

Como su nombre lo indica, contiene el XML que define su aplicación Mule. Todos los cambios que haga aquí se reflejarán en el lienzo, así como en la vista de propiedades del procesador de eventos en la pestaña Flujo de mensajes.

Puntos de vista

Para el editor activo, Anypoint Studio nos brinda la representación gráfica de los metadatos de nuestro proyecto, propiedades con la ayuda de vistas. Un usuario puede mover, cerrar y agregar vistas en el proyecto Mule. A continuación se muestran algunas vistas predeterminadas en Anypoint Studio:

Explorador de paquetes

La tarea principal de la vista Explorador de paquetes es mostrar las carpetas del proyecto y los archivos incluidos en un proyecto Mule. Podemos expandir o contraer la carpeta del proyecto Mule haciendo clic en la flecha al lado. Se puede abrir una carpeta o un archivo haciendo doble clic en él. Eche un vistazo a su captura de pantalla:

Paleta de mulas

La vista Mule Palette muestra los procesadores de eventos como ámbitos, filtros y enrutadores de control de flujo junto con los módulos y sus operaciones relacionadas. Las principales tareas de la vista Paleta de mule son las siguientes:

  • Esta vista nos ayuda a gestionar los módulos y conectores de nuestro proyecto.
  • También podemos agregar nuevos elementos desde Exchange.

Eche un vistazo a su captura de pantalla:

Propiedades de la mula

Como su nombre lo indica, nos permite editar las propiedades del módulo actualmente seleccionado en nuestro lienzo. La vista Propiedades de la mula incluye lo siguiente:

  • DataSense Explorer que proporciona información en tiempo real sobre la estructura de datos de nuestra carga útil.

  • Propiedades entrantes y salientes, si están disponibles o variables.

A continuación se muestra la captura de pantalla:

Consola

Siempre que creamos o ejecutamos la aplicación Mule, el servidor Mule integrado muestra una lista de eventos y problemas, si los hay, informados por Studio. La vista de consola contiene la consola de ese servidor Mule integrado. Eche un vistazo a su captura de pantalla:

Vista de problemas

Podemos encontrar muchos problemas mientras trabajamos en nuestro Proyecto Mule. Todos esos problemas se muestran en la vista Problemas. A continuación se muestra la captura de pantalla

Perspectivas

En Anypoint Studio, es una colección de vistas y editores en una disposición específica. Hay dos tipos de perspectivas en Anypoint Studio:

Mule Design Perspective - Es la perspectiva predeterminada que obtenemos en Studio.

Mule Debug Perspective - Otra perspectiva proporcionada por Anypoint Studio es Mule Debug Perspective.

Por otro lado, también podemos crear nuestra propia perspectiva y podemos agregar o eliminar cualquiera de las vistas predeterminadas.

En este capítulo vamos a crear nuestra primera aplicación Mule en Anypoint Studio de MuleSoft. Para crearlo, primero debemos iniciar Anypoint Studio.

Lanzamiento de Anypoint Studio

Haga clic en Anypoint Studio para iniciarlo. Si lo está iniciando por primera vez, verá la siguiente ventana:

Interfaz de usuario de Anypoint Studio

Una vez que haga clic en el botón Ir al espacio de trabajo, lo llevará a la interfaz de usuario de Anypoint Studio de la siguiente manera:

Pasos para crear la aplicación Mule

Para crear su aplicación Mule, siga los pasos a continuación:

Crear nuevo proyecto

El primer paso para crear la aplicación Mule es crear un nuevo proyecto. Se puede hacer siguiendo el caminoFILE → NEW → Mule Project como se muestra a continuación -

Nombrar el proyecto

Después de hacer clic en el nuevo Proyecto Mule, como se describió anteriormente, se abrirá una nueva ventana solicitando el nombre del proyecto y otras especificaciones. Dar el nombre del proyecto, 'TestAPP1'y luego haga clic en el botón Finalizar.

Una vez que haga clic en el botón Finalizar, se abrirá el espacio de trabajo creado para su MuleProject, a saber ‘TestAPP1’. Puedes ver todos losEditors y Views descrito en el capítulo anterior.

Configuración del conector

Aquí, vamos a construir una aplicación Mule simple para HTTP Listener. Para esto, necesitamos arrastrar el conector HTTP Listener desde Mule Palette y soltarlo en el espacio de trabajo como se muestra a continuación:

Ahora, necesitamos configurarlo. Haga clic en el signo + de color verde después de la configuración del conector en Configuración básica como se muestra arriba.

Al hacer clic en Aceptar, volverá a la página de propiedades del escucha HTTP. Ahora debemos proporcionar la ruta en la pestaña General. En este ejemplo particular, hemos proporcionado/FirstAPP como nombre de ruta.

Configurar el conector de carga útil

Ahora, necesitamos tomar un conector Set Payload. También debemos dar su valor en la pestaña Configuración de la siguiente manera:

This is my first Mule Application, es el nombre proporcionado en este ejemplo.

Aplicación Running Mule

Ahora, guárdelo y haga clic Run as Mule Application como se muestra a continuación -

Podemos verificarlo en Consola que implementa la aplicación de la siguiente manera:

Muestra que ha creado con éxito su primera aplicación Mule.

Verificación de la aplicación de la mula

Ahora, necesitamos probar si nuestra aplicación se está ejecutando o no. Go to POSTMAN, una aplicación de Chrome e ingrese la URL: http:/localhost:8081. Muestra el mensaje que proporcionamos al crear la aplicación Mule como se muestra a continuación:

DataWeave es básicamente un lenguaje de expresión de MuleSoft. Se utiliza principalmente para acceder y transformar los datos recibidos a través de una aplicación Mule. El tiempo de ejecución de Mule es responsable de ejecutar el script y las expresiones en nuestra aplicación Mule, DataWeave está fuertemente integrado con el tiempo de ejecución de Mule.

Características del lenguaje DataWeave

A continuación se muestran algunas características importantes del lenguaje DataWeave:

Los datos se pueden transformar de un formato a otro muy fácilmente. Por ejemplo, podemos transformar application / json en application / xml. La carga útil de entrada es la siguiente:

{
   "title": "MuleSoft",
   "author": " tutorialspoint.com ",
   "year": 2019
}

A continuación se muestra el código en DataWeave para transformar:

%dw 2.0
output application/xml
---
{
   order: {
      'type': 'Tutorial', 
      'title': payload.title, 
      'author': upper(payload.author), 
      'year': payload.year
   }
}

A continuación, el output la carga útil es la siguiente:

<?xml version = '1.0' encoding = 'UTF-8'?>
<order>
   <type>Tutorial</type>
   <title>MuleSoft</title>
   <author>tutorialspoint.com</author>
   <year>2019</year>
</order>

El componente de transformación se puede utilizar para crear scripts que realicen transformaciones de datos tanto simples como complejas.

Podemos acceder y utilizar funciones centrales de DataWeave en partes del evento Mule que necesitamos, ya que la mayoría de los procesadores de mensajes de Mule admiten expresiones DataWeave.

Prerrequisitos

Necesitamos satisfacer los siguientes requisitos previos antes de usar los scripts DataWeave en nuestra computadora:

  • Se requiere Anypoint Studio 7 para usar scripts de Dataweave.

  • Después de instalar Anypoint Studio, necesitamos configurar un proyecto con un componente Transform Message para poder usar scripts de DataWeave.

Pasos para usar el script DataWeave con el ejemplo

Para utilizar el script DataWeave, debemos seguir los pasos a continuación:

Step 1

Primero, necesitamos configurar un nuevo proyecto, como hicimos en el capítulo anterior, usando File → New → Mule Project.

Step 2

A continuación, debemos proporcionar el nombre del proyecto. Para este ejemplo, le damos el nombre,Mule_test_script.

Step 3

Ahora, necesitamos arrastrar el Transform Message component desde Mule Palette tab dentro canvas. Se muestra a continuación:

Step 4

A continuación, en el Transform Message componentpestaña, haga clic en Vista previa para abrir el panel Vista previa. Podemos expandir el área del código fuente haciendo clic en el rectángulo vacío junto a Vista previa.

Step 5

Ahora, podemos empezar a crear scripts con el lenguaje DataWeave.

Ejemplo

A continuación se muestra el ejemplo simple de concatenar dos cadenas en una:

El script DataWeave anterior tiene un par clave-valor ({ myString: ("hello" ++ "World") }) que concatenará dos cadenas en una.

Los módulos de secuencias de comandos facilitan a los usuarios utilizar el lenguaje de secuencias de comandos en Mule. En palabras simples, el módulo de secuencias de comandos puede intercambiar lógica personalizada escrita en lenguaje de secuencias de comandos. Los scripts se pueden utilizar como implementaciones o transformadores. Se pueden utilizar para la evaluación de expresiones, es decir, para controlar el enrutamiento de mensajes.

Mule tiene los siguientes lenguajes de secuencias de comandos compatibles:

  • Groovy
  • Python
  • JavaScript
  • Ruby

¿Cómo instalar módulos de secuencias de comandos?

En realidad, Anypoint Studio viene con los módulos de secuencias de comandos. Si no encuentra el módulo en Mule Palette, puede agregarlo usando+Add Module. Después de agregar, podemos usar las operaciones del módulo de secuencias de comandos en nuestra aplicación Mule.

Ejemplo de implementación

Como se discutió, necesitamos arrastrar y soltar el módulo en el lienzo para crear un espacio de trabajo y usarlo en nuestra aplicación. A continuación se muestra un ejemplo de ello:

Ya sabemos cómo configurar el componente HTTP Listener; por lo tanto, vamos a discutir sobre la configuración de los módulos de secuencias de comandos. Necesitamos seguir los pasos que se describen a continuación para configurar el módulo de secuencias de comandos:

Step 1

Busque el módulo Scripting de Mule Palette y arrastre el EXECUTE operación del módulo de secuencias de comandos en su flujo como se muestra arriba.

Step 2

Ahora, abra la pestaña Ejecutar configuración haciendo doble clic en la misma.

Step 3

Bajo la General pestaña, debemos proporcionar el código en la Code text window como se muestra a continuación -

Step 4

Por fin, tenemos que elegir el Enginedesde el componente de ejecución. La lista de motores es la siguiente:

  • Groovy
  • Nashorn(javaScript)
  • jython(Python)
  • jRuby(Ruby)

El XML del ejemplo de ejecución anterior en el editor XML de configuración es el siguiente:

<scripting:execute engine="jython" doc:name = "Script">
   <scripting:code>
      def factorial(n):
         if n == 0: return 1
      return n * factorial(n-1)
      result = factorial(10)
   </scripting:code>
</scripting:execute>

Fuentes de mensajes

Mule 4 tiene un modelo simplificado que el mensaje Mule 3, lo que facilita el trabajo con datos de forma coherente en todos los conectores sin sobrescribir la información. En el modelo de mensaje de Mule 4, cada evento de Mule consta de dos cosas:a message and variables associated with it.

Un mensaje de Mule tiene carga útil y sus atributos, donde el atributo es principalmente metadatos como el tamaño del archivo.

Y una variable contiene la información arbitraria del usuario, como el resultado de la operación, los valores auxiliares, etc.

Entrante

Las propiedades entrantes en Mule 3 ahora se convierten en Atributos en Mule 4. Como sabemos, las propiedades entrantes almacenan información adicional sobre la carga útil obtenida a través de una fuente de mensaje, pero esto ahora, en Mule 4, se hace con la ayuda de atributos. Los atributos tienen las siguientes ventajas:

  • Con la ayuda de los atributos, podemos ver fácilmente qué datos están disponibles, porque los atributos están fuertemente tipados.

  • Podemos acceder fácilmente a la información contenida en los atributos.

A continuación se muestra el ejemplo de un mensaje típico en Mule 4:

Saliente

Los conectores y transportes de Mule deben especificar explícitamente las propiedades de salida en Mule 3 para enviar datos adicionales. Pero en Mule 4, cada uno de ellos se puede configurar por separado, usando una expresión DataWeave para cada uno de ellos. No produce ningún efecto secundario en el flujo principal.

Por ejemplo, la siguiente expresión DataWeave realizará una solicitud HTTP y generará encabezados y parámetros de consulta sin necesidad de establecer las propiedades del mensaje. Esto se muestra en el siguiente código:

<http:request path = "M_issue" config-ref="http" method = "GET">
   <http:headers>#[{'path':'input/issues-list.json'}]</http:headers>
   <http:query-params>#[{'provider':'memory-provider'}]</http:query-params>
</http:request>

Procesador de mensajes

Una vez que Mule recibe un mensaje de una fuente de mensajes, comienza el trabajo del procesador de mensajes. The Mule utiliza uno o más procesadores de mensajes para procesar el mensaje a través de un flujo. La tarea principal del procesador de mensajes es transformar, filtrar, enriquecer y procesar el mensaje a medida que pasa por el flujo de Mule.

Categorización del procesador Mule

Las siguientes son las categorías de Procesador Mule, basadas en funciones:

  • Connectors- Estos procesadores de mensajes envían y reciben datos. También conectan datos a fuentes de datos externas a través de protocolos estándar o API de terceros.

  • Components - Estos procesadores de mensajes son de naturaleza flexible y ejecutan lógica empresarial implementada en varios lenguajes como Java, JavaScript, Groovy, Python o Ruby.

  • Filters - Filtran los mensajes y permiten que solo se sigan procesando mensajes específicos en un flujo, en función de criterios específicos.

  • Routers - Este procesador de mensajes se utiliza para controlar el flujo de mensajes a enrutar, resecuenciar o dividir.

  • Scopes - Básicamente, envuelven fragmentos de código con el fin de definir un comportamiento detallado dentro de un flujo.

  • Transformers - La función de los transformadores es convertir el tipo de carga útil del mensaje y el formato de datos para facilitar la comunicación entre sistemas.

  • Business Events - Básicamente capturan datos asociados con indicadores clave de desempeño.

  • Exception strategies - Estos procesadores de mensajes manejan errores de cualquier tipo que ocurren durante el procesamiento de mensajes.

Una de las habilidades más importantes de Mule es que puede realizar enrutamiento, transformación y procesamiento con los componentes, por lo que el archivo de configuración de la aplicación Mule que combina varios elementos es muy grande.

Los siguientes son los tipos de patrones de configuración proporcionados por Mule:

  • Patrón de servicio simple
  • Bridge
  • Validator
  • Proxy HTTP
  • Proxy WS

Configurar el componente

En Anypoint Studio, podemos seguir los pasos a continuación para configurar un componente:

Step 1

Necesitamos arrastrar el componente que deseamos usar en nuestra aplicación Mule. Por ejemplo, aquí usamos el componente de escucha HTTP de la siguiente manera:

Step 2

A continuación, haga doble clic en el componente para obtener la ventana de configuración. Para el oyente HTTP, se muestra a continuación:

Step 3

Podemos configurar el componente según el requisito de nuestro proyecto. Digamos, por ejemplo, lo hicimos para el componente de escucha HTTP:

Los componentes centrales son uno de los bloques de construcción importantes del flujo de trabajo en la aplicación Mule. La lógica para procesar un evento Mule es proporcionada por estos componentes centrales. En Anypoint Studio, para acceder a estos componentes principales, puede hacer clic en Core from Mule Palette como se muestra a continuación:

Los siguientes son varios core components and their working in Mule 4 -

Eventos comerciales personalizados

Este componente central se utiliza para la recopilación de información sobre flujos y procesadores de mensajes que manejan las transacciones comerciales en la aplicación Mule. En otras palabras, podemos usar el componente Evento comercial personalizado para agregar lo siguiente en nuestro flujo de trabajo:

  • Metadata
  • Indicadores clave de rendimiento (KPI)

¿Cómo agregar KPI?

Los siguientes son los pasos para agregar KPI en nuestro flujo en la aplicación Mule:

Step 1 - Sigue a Mule Palette → Core → Components → Custom Business Event, para agregar el componente Evento comercial personalizado a un flujo de trabajo en su aplicación Mule.

Step 2 - Haga clic en el componente para abrirlo.

Step 3 - Ahora, debemos proporcionar valores para el nombre para mostrar y el nombre del evento.

Step 4 - Para capturar información de la carga útil del mensaje, agregue los KPI de la siguiente manera:

  • Dé un nombre (clave) para el KPI ( seguimiento: elemento de metadatos ) y un valor. El nombre se utilizará en la interfaz de búsqueda de Runtime Manager.

  • Da un valor que puede ser cualquier expresión de Mule.

Ejemplo

La siguiente tabla consta de la lista de KPI con nombre y valor:

Nombre Expresión / Valor
Lista de estudiantes No # [carga útil ['RollNo']]
Nombre del estudiante # [payload ['Nombre']]

Evaluación dinámica

Este componente principal se utiliza para seleccionar dinámicamente un script en la aplicación Mule. También podemos usar un script hardcore a través del componente Transform Message, pero usar el componente Dynamic Evaluate es una mejor manera. Este componente central funciona de la siguiente manera:

  • En primer lugar, evalúa una expresión que debería dar como resultado otro script.
  • Luego evalúa ese script para obtener el resultado final.

De esta forma, nos permite seleccionar dinámicamente el script en lugar de codificarlo.

Ejemplo

A continuación, se muestra un ejemplo de cómo seleccionar un script de la base de datos a través de un parámetro de consulta Id y almacenar ese script en una variable llamada MyScript . Ahora, el componente de evaluación dinámica accederá a la variable para invocar los scripts para que pueda agregar una variable de nombre desdeUName parámetro de consulta.

La configuración XML del flujo se da a continuación:

<flow name = "DynamicE-example-flow">
   <http:listener config-ref = "HTTP_Listener_Configuration" path = "/"/>
   <db:select config-ref = "dbConfig" target = "myScript">
      <db:sql>#["SELECT script FROM SCRIPTS WHERE ID = 
         $(attributes.queryParams.Id)"]
      </db:sql>
   </db:select>
   <ee:dynamic-evaluate expression = "#[vars.myScript]">
      <ee:parameters>#[{name: attributes.queryParams.UName}]</ee:parameters>
   </ee:dynamic-evaluate>
</flow>

El script puede usar variables de contexto como mensaje, carga útil, variables o atributos. Sin embargo, si desea agregar una variable de contexto personalizada, debe proporcionar un conjunto de pares clave-valor.

Configuración de Dynamic Evaluate

La siguiente tabla proporciona una forma de configurar el componente Dynamic Evaluate:

Campo Valor Descripción Ejemplo
Expresión Expresión de DataWeave Especifica la expresión que se evaluará en el script final. expresión = "# [vars.generateOrderScript]"
Parámetros Expresión de DataWeave Especifica pares clave-valor. # [{joiner: 'y', id: payload.user.id}]

Componente de referencia de flujo

Si desea enrutar el evento Mule a otro flujo o subflujo y regresar dentro de la misma aplicación Mule, entonces el componente de referencia de flujo es la opción correcta.

Caracteristicas

Las siguientes son las características de este componente central:

  • Este componente central nos permite tratar todo el flujo referenciado como un solo componente en el flujo actual.

  • Divide la aplicación Mule en unidades discretas y reutilizables. Por ejemplo, un flujo enumera archivos de forma regular. Podría hacer referencia a otro flujo que procesa la salida de la operación de lista.

  • De esta manera, en lugar de agregar todos los pasos de procesamiento, podemos agregar referencias de flujo que apuntan al flujo de procesamiento. La siguiente captura de pantalla muestra que el componente principal de referencia de flujo apunta hacia un subflujo denominadoProcessFiles.

Trabajando

El funcionamiento del componente Flow Ref se puede entender con la ayuda del siguiente diagrama:

El diagrama muestra el orden de procesamiento en la aplicación Mule cuando un flujo hace referencia a otro flujo en la misma aplicación. Cuando se activa el flujo de trabajo principal en la aplicación Mule, el evento Mule recorre todo y ejecuta el flujo hasta que el evento Mule alcanza la referencia de flujo.

Después de llegar a Flow Reference, el evento Mule ejecuta el flujo referenciado de principio a fin. Una vez que el evento Mule termina de ejecutar el Ref Flow, vuelve al flujo principal.

Ejemplo

Para un mejor entendimiento, let us use this component in Anypoint Studio. En este ejemplo, estamos tomando un escucha HTTP para OBTENER un mensaje, como hicimos en el capítulo anterior. Entonces, podemos arrastrar y soltar el componente y configurarlo. Pero para este ejemplo, necesitamos agregar un componente de subflujo y establecer el componente de carga útil debajo de él, como se muestra a continuación:

A continuación, necesitamos configurar Set Payload, haciendo doble clic en él. Aquí le damos el valor, "Subflujo ejecutado" como se muestra a continuación:

Una vez que configuramos con éxito el componente de subflujo, necesitamos que el Componente de referencia de flujo se establezca después de Establecer carga útil del flujo principal, que podemos arrastrar y soltar desde la Paleta de mule como se muestra a continuación:

A continuación, mientras configuramos el Componente de referencia de flujo, debemos elegir Nombre de flujo en la pestaña Genérico como se muestra a continuación:

Ahora, guarde y ejecute esta aplicación. Para probar esto, vaya a POSTMAN y escribahttp:/localhost:8181/FirstAPP en la barra de URL, y obtendrá el mensaje, Subflujo ejecutado.

Componente del registrador

El componente central llamado logger nos ayuda a monitorear y depurar nuestra aplicación Mule al registrar información importante como mensajes de error, notificaciones de estado, cargas útiles, etc. En AnyPoint Studio, aparecen en el Console.

Ventajas

A continuación se presentan algunas ventajas del componente Logger:

  • Podemos agregar este componente principal en cualquier parte del flujo de trabajo.
  • Podemos configurarlo para registrar una cadena especificada por nosotros.
  • Podemos configurarlo a la salida de una expresión DataWeave escrita por nosotros.
  • También podemos configurarlo para cualquier combinación de cadenas y expresiones.

Ejemplo

El siguiente ejemplo muestra el mensaje "Hola mundo" en la carga de configuración en un navegador y también registra el mensaje.

A continuación se muestra la configuración XML del flujo en el ejemplo anterior:

<http:listener-config name = "HTTP_Listener_Configuration" host = "localhost" port = "8081"/>
<flow name = "mymuleprojectFlow">
   <http:listener config-ref="HTTP_Listener_Configuration" path="/"/>
   <set-payload value="Hello World"/>
   <logger message = "#[payload]" level = "INFO"/>
</flow>

Componente de mensaje de transferencia

Transform Message Component, también llamado componente Transfer, nos permite convertir los datos de entrada a un nuevo formato de salida.

Métodos para construir la transformación

Podemos construir nuestra transformación con la ayuda de los siguientes dos métodos:

Drag-and-Drop Editor (Graphical View)- Este es el primer y más utilizado método para construir nuestra transformación. En este método, podemos usar el mapeador visual de este componente para arrastrar y soltar los elementos de la estructura de datos entrantes. Por ejemplo, en el siguiente diagrama, dos vistas de árbol muestran las estructuras de metadatos esperadas de la entrada y la salida. Las líneas que conectan la entrada al campo de salida representan el mapeo entre dos vistas de árbol.

Script View- El mapeo visual de Transformation también se puede representar con la ayuda de DataWeave, un lenguaje para código Mule. Podemos hacer codificación para algunas transformaciones avanzadas como agregación, normalización, agrupación, unión, partición, pivotación y filtrado. El ejemplo se da a continuación:

Este componente central básicamente acepta metadatos de entrada y salida para una variable, un atributo o una carga útil de mensaje. Podemos proporcionar recursos específicos de formato para lo siguiente:

  • CSV
  • Schema
  • Esquema de archivo plano
  • JSON
  • Clase de objeto
  • Tipo simple
  • Esquema XML
  • Nombre y tipo de columna de Excel
  • Nombre y tipo de columna de ancho fijo

Los puntos finales incluyen básicamente aquellos componentes que activan o inician el procesamiento en un flujo de trabajo de la aplicación Mule. Se les llamaSource en Anypoint Studio y Triggersen el Centro de Diseño de Mule. Un punto final importante en Mule 4 esScheduler component.

Punto final del planificador

Este componente funciona en condiciones basadas en el tiempo, lo que significa que nos permite activar un flujo siempre que se cumpla una condición basada en el tiempo. Por ejemplo, un programador puede activar un evento para iniciar un flujo de trabajo de Mule cada, digamos 10 segundos. También podemos utilizar una expresión Cron flexible para activar un punto final del planificador.

Puntos importantes sobre el programador

Al usar el evento del Programador, debemos ocuparnos de algunos puntos importantes como se indica a continuación:

  • Scheduler Endpoint sigue la zona horaria de la máquina donde se ejecuta el tiempo de ejecución de Mule.

  • Suponga que si una aplicación Mule se está ejecutando en CloudHub, el Programador seguirá la zona horaria de la región en la que se está ejecutando el trabajador de CloudHub.

  • En un momento dado, solo puede estar activo un flujo desencadenado por el punto final del planificador.

  • En el clúster de tiempo de ejecución de Mule, el punto final del planificador se ejecuta o se activa solo en el nodo principal.

Formas de configurar un programador

Como se discutió anteriormente, podemos configurar un punto final del programador para que se active en un intervalo fijo o también podemos dar una expresión Cron.

Parámetros para configurar un programador (para intervalo fijo)

Los siguientes son los parámetros para configurar un programador para activar un flujo a intervalos regulares:

Frequency- Básicamente describe a qué frecuencia el punto final del planificador activará el flujo de mulas. La unidad de tiempo para esto se puede seleccionar en el campo Unidad de tiempo. En caso de que no proporcione ningún valor para esto, utilizará el valor predeterminado que es 1000. Por otro lado, si proporciona 0 o un valor negativo, también utilizará el valor predeterminado.

Start Delay- Es el tiempo que debemos esperar antes de activar el flujo de Mule por primera vez una vez iniciada la aplicación. El valor del retardo de inicio se expresa en la misma unidad de tiempo que la frecuencia. Su valor predeterminado es 0.

Time Unit- Describe la unidad de tiempo para Frecuencia y Retardo de inicio. Los posibles valores de la unidad de tiempo son milisegundos, segundos, minutos, horas, días. El valor predeterminado es milisegundos.

Parámetros para configurar un programador (para expresión Cron)

En realidad, Cron es un estándar que se utiliza para describir la información de fecha y hora. En caso de que utilice la expresión Cron flexible para hacer que el Programador se active, el Punto final del Programador realiza un seguimiento de cada segundo y crea un evento Mule siempre que la expresión Quartz Cron coincida con la configuración de fecha y hora. Con la expresión Cron, el evento se puede activar solo una vez o en intervalos regulares.

La siguiente tabla muestra la expresión de fecha y hora de seis configuraciones requeridas:

Atributo Valor
Segundos 0-59
Minutos 0-59
Horas 0-23
Dia del mes 1-31
Mes 1-12 o ENE-DIC
Día de la semana 1-7 o SUN-SAT

A continuación se ofrecen algunos ejemplos de expresiones Quartz Cron compatibles con el punto final del planificador:

  • ½ * * * * ? - significa que el programador se ejecuta cada 2 segundos del día, todos los días.

  • 0 0/5 16 ** ? - significa que el programador se ejecuta cada 5 minutos a partir de las 4 pm y termina a las 4:55 pm, todos los días.

  • 1 1 1 1, 5 * ? - significa que el planificador se ejecuta el primer día de enero y el primer día de abril, todos los años.

Ejemplo

El siguiente código registra el mensaje "hola" cada segundo:

<flow name = "cronFlow" doc:id = "ae257a5d-6b4f-4006-80c8-e7c76d2f67a0">
   <doc:name = "Scheduler" doc:id = "e7b6scheduler8ccb-c6d8-4567-87af-aa7904a50359">
      <scheduling-strategy>
         <cron expression = "* * * * * ?" timeZone = "America/Los_Angeles"/>
      </scheduling-strategy>
   </scheduler>
   <logger level = "INFO" doc:name = "Logger" 
      doc:id = "e2626dbb-54a9-4791-8ffa-b7c9a23e88a1" message = '"hi"'/>
</flow>

Control de flujo (enrutadores)

La tarea principal del componente Flow Control es tomar el evento Mule de entrada y enrutarlo a una o más secuencias separadas de componentes. Básicamente, se trata de enrutar el evento Mule de entrada a otras secuencias de componentes. Por lo tanto, también se denomina enrutadores. Los enrutadores Choice y Scatter-Gather son los enrutadores más utilizados en el componente Control de flujo.

Elección del enrutador

Como sugiere el nombre, este enrutador aplica la lógica DataWeave para elegir una de dos o más rutas. Como se discutió anteriormente, cada ruta es una secuencia separada de procesadores de eventos Mule. Podemos definir los enrutadores de elección como el enrutador que enruta dinámicamente el mensaje a través de un flujo de acuerdo con un conjunto de expresiones DataWeave utilizadas para evaluar el contenido del mensaje.

Diagrama esquemático de Choice Router

El efecto de usar el enrutador Choice es como agregar procesamiento condicional a un flujo o un if/then/elsebloque de código en la mayoría de los lenguajes de programación. A continuación se muestra el diagrama esquemático de un Choice Router, que tiene tres opciones. Entre ellos, uno es el enrutador predeterminado.

Enrutador Scatter-Gather

Otro procesador de eventos de enrutamiento más utilizado es Scatter-Gather component. Como su nombre lo indica, trabaja sobre los fundamentos de scatters (copiar) y Gather (Consolidates). Podemos entender su funcionamiento con la ayuda de los siguientes dos puntos:

  • Primero, este enrutador copia (Scatter) un evento Mule en dos o más rutas paralelas. La condición es que cada ruta debe ser una secuencia de uno o más procesadores de eventos que es como un subflujo. En este caso, cada ruta creará un evento Mule usando un hilo separado. Cada evento de Mule tendrá su propia carga útil, atributos y variables.

  • A continuación, este enrutador recopila los eventos Mule creados de cada ruta y luego los consolida en un nuevo evento Mule. Después de esto, pasa este evento Mule consolidado al siguiente procesador de eventos. Aquí la condición es que el enrutador SG pasará un evento Mule consolidado al siguiente procesador de eventos solo cuando todas las rutas se completen con éxito.

Diagrama esquemático del enrutador Scatter-Gather

A continuación se muestra el diagrama esquemático de un enrutador Scatter-Gather que tiene cuatro procesadores de eventos. Ejecuta cada ruta en paralelo y no secuencialmente.

Manejo de errores mediante el enrutador Scatter-Gather

Primero, debemos tener conocimiento sobre el tipo de error que se puede generar dentro del componente Scatter-Gather. Se puede generar cualquier error dentro de los procesadores de eventos que llevan al componente Scatter-Gather a generar un error de tipoMule: COMPOSITE_ERROR. Este error lo lanzará el componente SG solo después de que cada ruta falle o se complete.

Para manejar este tipo de error, un try scopese puede utilizar en cada ruta del componente Scatter-Gather. Si el error es manejado con éxito portry scope, entonces la ruta podrá generar un evento Mule, seguro.

Transformadores

Supongamos que si queremos configurar o eliminar una parte de cualquier evento de Mule, el componente Transformer es la mejor opción. Los componentes del transformador son de los siguientes tipos:

Quitar transformador variable

Como su nombre lo indica, este componente toma un nombre de variable y elimina esa variable del evento Mule.

Configurar quitar transformador variable

La siguiente tabla muestra el nombre de los campos y su descripción a considerar al configurar la eliminación del transformador variable -

No Señor Campo y explicación
1

Display Name (doc:name)

Podemos personalizar esto para mostrar un nombre único para este componente en nuestro flujo de trabajo de Mule.

2

Name (variableName)

Representa el nombre de la variable a eliminar.

Configurar transformador de carga útil

Con la ayuda de set-payloadcomponente, podemos actualizar la carga útil, que puede ser una cadena literal o expresión DataWeave, del mensaje. No se recomienda utilizar este componente para expresiones o transformaciones complejas. Se puede usar para simples comoselections.

La siguiente tabla muestra el nombre de los campos y su descripción que se deben considerar al configurar el transformador de carga útil establecido:

Campo Uso Explicación
Valor (valor) Obligatorio El valor archivado es necesario para configurar una carga útil. Aceptará una cadena literal o una expresión DataWeave que defina cómo configurar la carga útil. Los ejemplos son como "alguna cadena"
Tipo de Mime (mimeType) Opcional Es opcional pero representa el tipo mime del valor asignado a la carga útil del mensaje. Los ejemplos son como texto / sin formato.
Codificación (codificación) Opcional También es opcional, pero representa la codificación del valor que se asigna a la carga útil del mensaje. Los ejemplos son como UTF-8.

Podemos establecer una carga útil a través del código de configuración XML:

With Static Content - El siguiente código de configuración XML establecerá la carga útil mediante el uso de contenido estático -

<set-payload value = "{ 'name' : 'Gaurav', 'Id' : '2510' }" 
   mimeType = "application/json" encoding = "UTF-8"/>

With Expression Content - El siguiente código de configuración XML establecerá la carga útil mediante el uso de contenido de expresión -

<set-payload value = "#['Hi' ++ ' Today is ' ++ now()]"/>

El ejemplo anterior agregará la fecha de hoy con el mensaje "Hola".

Configurar transformador variable

Con la ayuda de set variablecomponente, podemos crear o actualizar una variable para almacenar valores que pueden ser valores literales simples como cadenas, cargas útiles de mensajes u objetos de atributo, para usar dentro del flujo de la aplicación Mule. No se recomienda utilizar este componente para expresiones o transformaciones complejas. Se puede usar para simples comoselections.

Configurar transformador de variable de set

La siguiente tabla muestra el nombre de los campos y su descripción que se deben considerar al configurar el transformador de carga útil establecido:

Campo Uso Explicación
Nombre de variable (variableName) Obligatorio Se requiere archivado y representa el nombre de la variable. Al dar el nombre, siga la convención de nomenclatura, ya que debe contener números, caracteres y guiones bajos.
Valor (valor) Obligatorio El valor archivado es necesario para establecer una variable. Aceptará una cadena literal o expresión DataWeave.
Tipo de Mime (mimeType) Opcional Es opcional pero representa el tipo mime de la variable. Los ejemplos son como texto / sin formato.
Codificación (codificación) Opcional También es opcional pero representa la codificación de la variable. Los ejemplos son como ISO 10646 / Unicode (UTF-8).

Ejemplo

El siguiente ejemplo establecerá la variable en la carga útil del mensaje:

Variable Name = msg_var
Value = payload in Design center and #[payload] in Anypoint Studio

De manera similar, el siguiente ejemplo establecerá la variable en la carga útil del mensaje:

Variable Name = msg_var
Value = attributes in Design center and #[attributes] in Anypoint Studio.

Servicio web REST

La forma completa de REST es Representational State Transfer, que está vinculada con HTTP. Por tanto, si quieres diseñar una aplicación para uso exclusivo en la web, REST es la mejor opción.

Consumir servicios web RESTful

En el siguiente ejemplo, usaremos el componente REST y un servicio RESTful público proporcionado por Mule Soft llamado American Flights details. Tiene varios detalles pero vamos a usar GET:http://training-american-ws.cloudhub.io/api/flightsque devolverá todos los detalles del vuelo. Como se discutió anteriormente, REST está vinculado con HTTP, por lo tanto, necesitamos dos componentes HTTP: uno es Listener y otro es Request, también para esta aplicación. La siguiente captura de pantalla muestra la configuración del oyente HTTP:

Configurar y pasar argumentos

La configuración para la solicitud HTTP se proporciona a continuación:

Ahora, según el flujo de nuestro espacio de trabajo, hemos tomado el registrador para que se pueda configurar como se muestra a continuación:

En la pestaña de mensajes, escribimos código para convertir la carga útil en cadenas.

Prueba de la aplicación

Ahora, guarde y ejecute la aplicación y vaya a POSTMAN para verificar el resultado final como se muestra a continuación:

Puede ver que proporciona los detalles del vuelo utilizando el componente REST.

Componente SOAP

La forma completa de SOAP es Simple Object Access Protocol. Básicamente es una especificación de protocolo de mensajería para intercambiar información en la implementación de servicios web. A continuación, usaremos la API SOAP en Anypoint Studio para acceder a la información mediante servicios web.

Consumir servicios web basados ​​en SOAP

Para este ejemplo, vamos a utilizar el servicio público SOAP cuyo nombre es Country Info Service que retiene los servicios relacionados con la información del país. Su dirección WSDL es:http://www.oorsprong.org/websamples.countryinfo/countryinfoservice.wso?WSDL

Primero, necesitamos arrastrar el consumo de SOAP en nuestro lienzo desde Mule Palette como se muestra a continuación:

Configurar y pasar argumentos

A continuación, necesitamos configurar la solicitud HTTP como se hizo en el ejemplo anterior como se indica a continuación:

Ahora, también necesitamos configurar el consumidor de servicios web como se muestra a continuación:

En el lugar de la ubicación de WSDL, debemos proporcionar la dirección web de WSDL, que se proporciona arriba (para este ejemplo). Una vez que proporcione la dirección web, Studio buscará el servicio, el puerto y la dirección por sí mismo. No es necesario que lo proporcione manualmente.

Transferir respuesta del servicio web

Para esto, necesitamos agregar un registrador en el flujo de Mule y configurarlo para dar la carga útil como se muestra a continuación:

Prueba de la aplicación

Guarde y ejecute la aplicación y vaya a Google Chrome para verificar el resultado final. Tipohttp://localhist:8081/helloSOAP (para este ejemplo) y mostrará el nombre del país por código como se muestra en la captura de pantalla a continuación:

El nuevo manejo de errores de Mule es uno de los cambios más grandes e importantes realizados en Mule 4. El nuevo manejo de errores puede parecer complejo, pero es mejor y más eficiente. En este capítulo, analizaremos los componentes del error Mule, los tipos de error, las categorías de error Mule y los componentes para el manejo de errores Mule.

Componentes de Mule Error

El error de Mule es el resultado de una excepción de Mule que tiene los siguientes componentes:

Descripción

Es un componente importante del error Mule que dará una descripción sobre el problema. Su expresión es la siguiente:

#[error.description]

Tipo

El componente de tipo del error Mule se utiliza para caracterizar el problema. También permite el enrutamiento dentro de un controlador de errores. Su expresión es la siguiente:

#[error.errorType]

Porque

El componente Cause del error Mule proporciona el Java subyacente arrojable que causa la falla. Su expresión es la siguiente:

#[error.cause]

Mensaje

El componente Mensaje del error Mule muestra un mensaje opcional con respecto al error. Su expresión es la siguiente:

#[error.errorMessage]

Errores del niño

El Errores infantiles componente de error de mula da una colección opcional de errores internos. Estos errores internos son utilizados principalmente por elementos como Scatter-Gather para proporcionar errores de ruta agregados. Su expresión es la siguiente:

#[error.childErrors]

Ejemplo

En caso de falla de la solicitud HTTP con un código de estado 401, los errores de Mule son los siguientes:

Description: HTTP GET on resource ‘http://localhost:8181/TestApp’ 
failed: unauthorized (401)
Type: HTTP:UNAUTHORIZED
Cause: a ResponseValidatorTypedException instance
Error Message: { "message" : "Could not authorize the user." }
No Señor Tipo de error y descripción
1

TRANSFORMATION

Este tipo de error indica que se produjo un error al transformar un valor. La transformación es la transformación interna de Mule Runtime y no las transformaciones de DataWeave.

2

EXPRESSION

Este tipo de tipo de error indica que se produjo un error al evaluar una expresión.

3

VALIDATION

Este tipo de tipo de error indica que ocurrió un error de validación.

4

DUPLICATE_MESSAGE

Una especie de error de validación que se produce cuando un mensaje se procesa dos veces.

5

REDELIVERY_EXHAUSTED

Este tipo de tipo de error se produce cuando se han agotado los intentos máximos de reprocesar un mensaje de una fuente.

6

CONNECTIVITY

Este tipo de error indica un problema al establecer una conexión.

7

ROUTING

Este tipo de error indica que ocurrió un error al enrutar un mensaje.

8

SECURITY

Este tipo de error indica que ocurrió un error de seguridad. Por ejemplo, se recibieron credenciales no válidas.

9

STREAM_MAXIMUM_SIZE_EXCEEDED

Este tipo de error se produce cuando se agota el tamaño máximo permitido para una secuencia.

10

TIMEOUT

Indica el tiempo de espera mientras se procesa un mensaje.

11

UNKNOWN

Este tipo de error indica que ocurrió un error inesperado.

12

SOURCE

Representa la ocurrencia de un error en la fuente del flujo.

13

SOURCE_RESPONSE

Representa la ocurrencia de un error en la fuente del flujo mientras se procesa una respuesta exitosa.

En el ejemplo anterior, puede ver el componente de mensaje de error de mula.

Tipos de error

Entendamos los tipos de error con la ayuda de sus características:

  • La primera característica de los tipos de error de mula es que consta de ambos, a namespace and an identifier. Esto nos permite distinguir los tipos según su dominio. En el ejemplo anterior, el tipo de error esHTTP: UNAUTHORIZED.

  • La segunda e importante característica es que el tipo de error puede tener un tipo principal. Por ejemplo, el tipo de errorHTTP: UNAUTHORIZED tiene MULE:CLIENT_SECURITY como el padre que a su vez también tiene un padre llamado MULE:SECURITY. Esta característica establece el tipo de error como especificación de un elemento más global.

Tipos de tipos de error

A continuación se muestran las categorías en las que caen todos los errores:

NINGUNA

Los errores de esta categoría son los errores que pueden ocurrir en un flujo. No son tan graves y se pueden manipular fácilmente.

CRÍTICO

Los errores de esta categoría son los errores graves que no se pueden manejar. A continuación se muestra la lista de tipos de error en esta categoría:

No Señor Tipo de error y descripción
1

OVERLOAD

Este tipo de error indica que ocurrió un error debido a un problema de sobrecarga. En este caso, la ejecución será rechazada.

2

FATAL_JVM_ERROR

Este tipo de tipo de error indica la ocurrencia de un error fatal. Por ejemplo, desbordamiento de pila.

Tipo de error PERSONALIZADO

Los tipos de errores PERSONALIZADOS son los errores que definimos nosotros. Se pueden definir al mapear o al plantear los errores. Debemos dar un espacio de nombres personalizado específico a estos tipos de error para distinguirlos de los otros tipos de error existentes dentro de la aplicación Mule. Por ejemplo, en la aplicación Mule que usa HTTP, no podemos usar HTTP como el tipo de error personalizado.

Categorías de error de mula

En sentido amplio, los errores en Mule se pueden dividir en dos categorías, a saber, Messaging Errors and System Errors.

Error de mensajería

Esta categoría de error de Mulas está relacionada con el flujo de Mulas. Siempre que ocurre un problema dentro de un flujo de Mule, Mule lanza un mensaje de error. Podemos configurarOn Error componente dentro del componente controlador de errores para manejar estos errores de Mule.

Error del sistema

El error del sistema indica que se produce una excepción a nivel del sistema. Si no hay un evento Mule, el error del sistema lo maneja un controlador de errores del sistema. El siguiente tipo de excepciones manejadas por un controlador de errores del sistema:

  • Excepción que ocurre durante el inicio de una aplicación.
  • Excepción que ocurre cuando falla una conexión a un sistema externo.

En caso de que ocurra un error del sistema, Mule envía una notificación de error a los oyentes registrados. También registra el error. Por otro lado, Mule ejecuta una estrategia de reconexión si el error fue causado por una falla en la conexión.

Manejo de errores de mula

Mule tiene los siguientes dos controladores de errores para manejar los errores:

Controladores de errores en caso de error

El primer controlador de errores de Mule es el componente On-Error, que define los tipos de errores que pueden manejar. Como se discutió anteriormente, podemos configurar componentes en caso de error dentro del componente de controlador de errores similar al alcance. Cada flujo de Mule contiene solo un manejador de errores, pero este manejador de errores puede contener tantos alcances en caso de error como necesitemos. Los pasos para manejar el error Mule dentro del flujo, con la ayuda del componente On-Error, son los siguientes:

  • Primero, siempre que un flujo de Mule genera un error, la ejecución normal del flujo se detiene.

  • A continuación, el proceso se transferirá al Error Handler Component que ya tengo On Error component para hacer coincidir los tipos y expresiones de error.

  • Por fin, el componente Manejador de errores enruta el error al primer On Error scope que coincide con el error.

Los siguientes son los dos tipos de componentes en caso de error compatibles con Mule:

Propagación en caso de error

El componente de propagación en caso de error se ejecuta, pero propaga el error al siguiente nivel e interrumpe la ejecución del propietario. La transacción se revertirá si la gestionaOn Error Propagate componente.

Continuar en caso de error

Al igual que el componente Propagar en caso de error, el componente Continuar en caso de error también ejecuta la transacción. La única condición es que, si el propietario completó la ejecución con éxito, este componente utilizará el resultado de la ejecución como el resultado de su propietario. La transacción se confirmará si es manejada por el componente Continuar en caso de error.

Pruebe el componente Scope

Try Scope es una de las muchas novedades disponibles en Mule 4. Funciona de forma similar al bloque try de JAVA en el que solíamos encerrar el código teniendo la posibilidad de ser una excepción, de modo que se pueda manejar sin romper todo el código.

Podemos envolver uno o más procesadores de eventos Mule en Try Scope y luego, try scope detectará y manejará cualquier excepción lanzada por estos procesadores de eventos. El funcionamiento principal del alcance de prueba gira en torno a su propia estrategia de manejo de errores que admite el manejo de errores en su componente interno en lugar de todo el flujo. Es por eso que no necesitamos extraer el flujo en un flujo separado.

Example

A continuación se muestra un ejemplo del uso del alcance de prueba:

Configurar el alcance de prueba para manejar transacciones

Como sabemos, una transacción es una serie de acciones que nunca deben ejecutarse parcialmente. Todas las operaciones dentro del alcance de una transacción se ejecutan en el mismo hilo y si ocurre un error, debería conducir a una reversión o un compromiso. Podemos configurar el alcance de prueba, de la siguiente manera, para que trate las operaciones secundarias como una transacción.

  • INDIFFERENT [Default]- Si elegimos esta configuración en el bloque try, las acciones secundarias no se tratarán como una transacción. En este caso, el error no provoca la reversión ni la confirmación.

  • ALWAYS_BEGIN - Indica que se iniciará una nueva transacción cada vez que se ejecute el alcance.

  • BEGIN_OR_JOIN- Indica que si el procesamiento actual del flujo ya ha iniciado una transacción, únete a ella. De lo contrario, inicie uno nuevo.

En el caso de todos los proyectos, el hecho de las excepciones es que están destinadas a suceder. Por eso es importante capturar, categorizar y manejar las excepciones para que el sistema / aplicación no quede en un estado inconsistente. Existe una estrategia de excepción predeterminada que se aplica implícitamente a todas las aplicaciones de Mule. Revertir cualquier transacción pendiente automáticamente es la estrategia de excepción predeterminada.

Excepciones en Mule

Antes de profundizar en el manejo excepcional, debemos comprender qué tipo de excepciones pueden ocurrir junto con tres preguntas básicas que un desarrollador debe tener al diseñar controladores de excepciones.

¿Qué transporte es importante?

Esta pregunta tiene mucha relevancia antes de diseñar manejadores de excepciones porque no todos los transportes apoyan la transnacionalidad.

File o HTTPno admite transacciones. Por eso, si se produce una excepción en estos casos, debemos gestionarla manualmente.

Databasestransacciones de apoyo. Al diseñar controladores de excepciones en este caso, debemos tener en cuenta que las transacciones de la base de datos se pueden deshacer automáticamente (si es necesario).

En caso de REST APIs, debemos tener en cuenta que deben devolver los códigos de estado HTTP correctos. Por ejemplo, 404 para un recurso no encontrado.

¿Qué patrón de intercambio de mensajes se utilizará?

Al diseñar controladores de excepciones, debemos cuidar el patrón de intercambio de mensajes. Puede haber un patrón de mensaje sincrónico (solicitud-respuesta) o asincrónico (fuego-olvido).

Synchronous message pattern se basa en el formato de solicitud-respuesta, lo que significa que este patrón esperará una respuesta y se bloqueará hasta que se devuelva una respuesta o se agote el tiempo de espera.

Asynchronous message pattern se basa en el formato de olvido de fuego, lo que significa que este patrón asume que las solicitudes se procesarán en última instancia.

¿Qué tipo de excepción es?

Una regla muy simple es que manejará la excepción según su tipo. ¿Es muy importante saber si la excepción se debe a un problema técnico o del sistema oa un problema comercial?

Una excepción ocurrió por system/technical issue (como una interrupción de la red) debe manejarse automáticamente mediante un mecanismo de reintento.

Por otro lado, ocurrió una excepción by a business issue (como datos no válidos) no debe resolverse aplicando un mecanismo de reintento porque no es útil reintentar sin corregir la causa subyacente.

¿Por qué categorizar las excepciones?

Como sabemos que no todas las excepciones son iguales, es muy importante categorizar las excepciones. A alto nivel, las excepciones se pueden clasificar en los siguientes dos tipos:

Excepciones comerciales

Las principales razones para la aparición de excepciones comerciales son datos incorrectos o flujo de proceso incorrecto. Este tipo de excepciones no suelen ser de naturaleza recuperable y, por tanto, no es bueno configurar unrollback. Incluso aplicandoretryEl mecanismo no tendría ningún sentido porque no es útil volver a intentarlo sin corregir la causa subyacente. Para manejar tales excepciones, el procesamiento debe detenerse inmediatamente y la excepción debe devolverse como respuesta a una cola de mensajes no entregados. También se debe enviar una notificación a las operaciones.

Excepciones no comerciales

Las principales razones de la aparición de excepciones no comerciales son problemas del sistema o problemas técnicos. Este tipo de excepciones son de naturaleza recuperable y, por lo tanto, es bueno configurar unretry mecanismo para resolver estas excepciones.

Estrategias de manejo de excepciones

Mule tiene las siguientes cinco estrategias de manejo de excepciones:

Estrategia de excepción predeterminada

Mule aplica implícitamente esta estrategia a los flujos de Mule. Puede manejar todas las excepciones en nuestro flujo, pero también se puede anular agregando una estrategia de excepción catch, Choice o Rollback. Esta estrategia de excepción revertirá cualquier transacción pendiente y también registrará las excepciones. Una característica importante de esta estrategia de excepción es que también registrará la excepción si no hay transacción.

Como es la estrategia predeterminada, Mule implementa esto cuando ocurre algún error en el flujo. No podemos configurar en AnyPoint Studio.

Estrategia de excepción de reversión

Suponga que si no hay una solución posible para corregir el error, ¿qué hacer? Una solución es utilizar la estrategia de excepción de reversión, que revertirá la transacción junto con el envío de un mensaje al conector de entrada del flujo principal para volver a procesar el mensaje. Esta estrategia también es muy útil cuando queremos reprocesar un mensaje.

Example

Esta estrategia se puede aplicar a transacciones bancarias donde los fondos se depositan en una cuenta corriente o de ahorros. Podemos configurar una estrategia de excepción de reversión aquí porque en caso de que ocurra un error durante la transacción, esta estrategia revierte el mensaje al principio en el flujo para reintentar el procesamiento.

Estrategia de captura de excepción

Esta estrategia detecta todas las excepciones que se lanzan dentro de su flujo principal. Anula la estrategia de excepción predeterminada de Mule al procesar todas las excepciones lanzadas por el flujo principal. Podemos utilizar una estrategia de captura de excepciones para evitar la propagación de excepciones a los conectores entrantes y a los flujos principales.

Esta estrategia también garantiza que una transacción procesada por el flujo no se deshaga cuando se produce una excepción.

Example

Esta estrategia se puede aplicar al sistema de reserva de vuelos en el que tenemos un flujo para procesar mensajes de una cola. Un enriquecedor de mensajes agrega una propiedad al mensaje para la asignación de asiento y luego envía el mensaje a otra cola.

Ahora, si ocurre algún error en este flujo, el mensaje generará una excepción. Aquí, nuestra estrategia de captura de excepción puede agregar un encabezado con un mensaje apropiado y puede empujar ese mensaje fuera del flujo a la siguiente cola.

Estrategia de excepción de elección

En caso de que desee manejar la excepción en función del contenido del mensaje, la estrategia de excepción de elección sería la mejor opción. El funcionamiento de esta estrategia de excepción será el siguiente:

  • Primero, captura todas las excepciones lanzadas dentro del flujo principal.
  • A continuación, comprueba el contenido del mensaje y el tipo de excepción.
  • Y, por último, dirige el mensaje a la estrategia de excepción adecuada.

Habría más de una estrategia de excepción como Catch o Rollback, definida dentro de la estrategia de excepción de elección. En caso de que no haya una estrategia definida bajo esta estrategia de excepción, entonces enrutará el mensaje a la estrategia de excepción predeterminada. Nunca realiza ninguna actividad de compromiso, reversión o consumo.

Estrategia de excepción de referencia

Esto se refiere a una estrategia de excepción común que se define en un archivo de configuración independiente. En caso de que un mensaje arroje una excepción, esta estrategia de excepción se referirá a los parámetros de manejo de errores definidos en una estrategia global de captura, reversión o excepción de elección. Al igual que la estrategia de excepción de elección, nunca realiza ninguna actividad de compromiso, reversión o consumo.

Entendemos que las pruebas unitarias son un método mediante el cual se pueden probar unidades individuales de código fuente para determinar si son aptas para su uso o no. Los programadores de Java pueden usar el marco Junit para escribir casos de prueba. De manera similar, MuleSoft también tiene un marco llamado MUnit que nos permite escribir casos de prueba automatizados para nuestras API e integraciones. Es un ajuste perfecto para el entorno de implementación / integración continua. Una de las mayores ventajas del marco MUnit es que podemos integrarlo con Maven y Surefire.

Características de MUnit

A continuación se muestran algunas de las características muy útiles del marco de prueba Mule MUnit:

  • En el marco MUnit, podemos crear nuestra prueba Mule utilizando código Mule y código Java.

  • Podemos diseñar y probar nuestras aplicaciones y API Mule, ya sea gráficamente o en XML, dentro de Anypoint Studio.

  • MUnit nos permite integrar fácilmente las pruebas en el proceso de CI / CD existente.

  • Proporciona pruebas e informes de cobertura generados automáticamente; de ahí que el trabajo manual sea mínimo.

  • También podemos utilizar servidores locales de DB / FTP / correo para hacer que las pruebas sean más portátiles a través del proceso de CI.

  • Nos permite habilitar o deshabilitar pruebas.

  • También podemos ampliar el marco MUnit con complementos.

  • Nos permite verificar las llamadas al procesador de mensajes.

  • Con la ayuda del marco de prueba MUnit, podemos deshabilitar los conectores de punto final y los puntos finales de entrada de flujo.

  • Podemos comprobar los informes de error con el seguimiento de pila de Mule.

Última versión del marco de prueba Mule MUnit

MUnit 2.1.4 es la última versión del marco de prueba de Mule MUnit. Requiere los siguientes requisitos de hardware y software:

  • MS Windows 8+
  • Apple Mac OS X 10.10+
  • Linux
  • Java 8
  • Maven 3.3.3, 3.3.9, 3.5.4, 3.6.0

Es compatible con Mule 4.1.4 y Anypoint Studio 7.3.0.

MUnit y Anypoint Studio

Como se discutió, MUnit está completamente integrado en Anypoint Studio y podemos diseñar y probar nuestras aplicaciones y API Mule gráficamente o en XML dentro de Anypoint Studio. En otras palabras, podemos usar la interfaz gráfica de Anypoint Studio para hacer lo siguiente:

  • Para crear y diseñar pruebas MUnit
  • Para ejecutar nuestras pruebas
  • Para ver los resultados de las pruebas y el informe de cobertura
  • Para depurar las pruebas

Entonces, comencemos a discutir cada tarea una por una.

Creación y diseño de pruebas MUnit

Una vez que comience un nuevo proyecto, automáticamente agregará una nueva carpeta a saber src/test/munita nuestro proyecto. Por ejemplo, comenzamos un nuevo proyecto de Mule a sabertest_munit, puede ver en la imagen de abajo, agrega la carpeta mencionada anteriormente en nuestro proyecto.

Ahora, una vez que comenzó un nuevo proyecto, hay dos formas básicas de crear una nueva prueba MUnit en Anypoint Studio:

  • By Right-Clicking the Flow - En este método, debemos hacer clic con el botón derecho en el flujo específico y seleccionar MUnit en el menú desplegable.

  • By Using the Wizard- En este método, necesitamos usar el asistente para crear una prueba. Nos permite crear una prueba para cualquier flujo en el espacio de trabajo.

Vamos a utilizar la forma 'Hacer clic con el botón derecho en el flujo' para crear una prueba para un flujo específico.

Primero, necesitamos crear un flujo en el espacio de trabajo de la siguiente manera:

Ahora, haga clic derecho en este flujo y seleccione MUnit para crear una prueba para este flujo, como se muestra a continuación:

Creará un nuevo conjunto de pruebas con el nombre del archivo XML donde reside el flujo. En este caso,test_munit-test-suite es el nombre del nuevo conjunto de pruebas como se muestra a continuación:

A continuación se muestra el editor XML para el flujo de mensajes anterior:

Ahora, podemos agregar un MUnit procesador de mensajes a la suite de prueba arrastrándolo desde Mule Palette.

Si desea crear una prueba a través del asistente, siga File → New → MUnit y lo llevará al siguiente conjunto de pruebas MUnit:

Configurar la prueba

En Mule 4, tenemos dos secciones nuevas a saber MUnit y MUnit Tools, teniendo colectivamente todo el procesador de mensajes MUnit. Puede arrastrar cualquiera de los procesadores de mensajes en su área de prueba MUnit. Se muestra en la siguiente captura de pantalla:

Ahora, si desea editar la configuración de su traje o prueba en Anypoint Studio, debe seguir los pasos a continuación:

Step 1

Ve a la Package Explorer y haga clic derecho en el .xml filepara su suite o prueba. Luego, seleccione elProperties.

Step 2

Ahora, en la ventana Propiedades, debemos hacer clic en Run/Debug Settings. Después de este clicNew.

Step 3

En el último paso, haga clic en MUnit debajo Select Configuration Type ventana y luego haga clic en OK.

Ejecutando la prueba

Podemos ejecutar tanto una suite de pruebas como una prueba. Primero, veremos cómo ejecutar un conjunto de pruebas.

Ejecución de un conjunto de pruebas

Para ejecutar una suite de pruebas, haga clic derecho en la parte vacía del Mule Canvas donde reside su suite de pruebas. Se abrirá un menú desplegable. Ahora, haga clic en elRun MUnit suite como se muestra a continuación -

Posteriormente, podemos ver la salida en la consola.

Ejecutando una prueba

Para ejecutar una prueba específica, debemos seleccionar la prueba específica y hacer clic derecho en ella. Obtendremos el mismo menú desplegable que obtuvimos mientras ejecutamos el conjunto de pruebas. Ahora, haga clic en elRun MUnit Test opción como se muestra a continuación -

Allí después se puede ver la salida en la consola.

Ver y analizar el resultado de la prueba

Anypoint Studio muestra el resultado de la prueba MUnit en el MUnit tabdel panel del explorador de la izquierda. Puede encontrar pruebas exitosas en color verde y pruebas fallidas en rojo, como se muestra a continuación:

Podemos analizar el resultado de nuestra prueba viendo el informe de cobertura. La característica principal del Informe de cobertura es proporcionar una métrica sobre la cantidad de una aplicación Mule que se ha ejecutado con éxito mediante un conjunto de pruebas MUnit. La cobertura de MUnit se basa básicamente en la cantidad de procesadores de mensajes MUnit ejecutados. El informe de cobertura de MUnit proporciona métricas para lo siguiente:

  • Cobertura general de la aplicación
  • Cobertura de recursos
  • Cobertura de flujo

Para obtener el informe de cobertura, debemos hacer clic en 'Generar informe' en la pestaña MUnit como se muestra a continuación:

Depurando la prueba

Podemos depurar tanto una suite de pruebas como una prueba. Primero, veremos cómo depurar un conjunto de pruebas.

Depurar una suite de pruebas

Para depurar un conjunto de pruebas, haga clic con el botón derecho en la parte vacía del Mule Canvas donde reside su conjunto de pruebas. Se abrirá un menú desplegable. Ahora, haga clic en elDebug MUnit Suite como se muestra en la imagen de abajo -

Luego, podemos ver la salida en la consola.

Depurar una prueba

Para depurar una prueba específica, debemos seleccionar la prueba específica y hacer clic derecho en ella. Obtendremos el mismo menú desplegable que obtuvimos al depurar el conjunto de pruebas. Ahora, haga clic en elDebug MUnit Testopción. Se muestra en la siguiente captura de pantalla.