MuleSoft - Guia rápido

ESB significa Enterprise Service Busque é basicamente uma ferramenta de middleware para integrar vários aplicativos em uma infraestrutura semelhante a um barramento. Fundamentalmente, é uma arquitetura projetada para fornecer um meio uniforme de movimentação do trabalho entre aplicativos integrados. Desta forma, com a ajuda da arquitetura ESB podemos conectar diferentes aplicativos através de um barramento de comunicação e permitir que eles se comuniquem sem depender uns dos outros.

Implementando ESB

O foco principal da arquitetura ESB é separar os sistemas uns dos outros e permitir que eles se comuniquem de forma estável e controlável. A implementação do ESB pode ser feita com a ajuda de‘Bus’ e ‘Adapter’ da seguinte maneira -

• O conceito de “barramento”, que é alcançado através de um servidor de mensagens como JMS ou AMQP, é usado para separar aplicativos diferentes uns dos outros.

• O conceito de “adaptador”, responsável por se comunicar com o aplicativo backend e transformar os dados do formato do aplicativo para o formato do barramento, é usado entre os aplicativos e o barramento.

Os dados ou mensagens que passam de um aplicativo para outro através do barramento estão em um formato canônico, o que significa que haveria um formato de mensagem consistente.

O adaptador também pode executar outras atividades como segurança, monitoramento, tratamento de erros e gerenciamento de roteamento de mensagens.

Princípios Orientadores do ESB

Podemos chamar esses princípios de princípios básicos de integração. Eles são os seguintes -

• Orchestration - Integração de dois ou mais serviços para conseguir a sincronização entre dados e processos.

• Transformation - Transformar dados do formato canônico para o formato específico do aplicativo.

• Transportation - Lidar com negociação de protocolo entre formatos como FTP, HTTP, JMS, etc.

• Mediation - Fornecimento de várias interfaces para oferecer suporte a várias versões de um serviço.

• Non-functional consistency - Fornecer mecanismo para gerenciar transações e segurança também.

Necessidade de ESB

A arquitetura ESB nos permite integrar diferentes aplicativos, onde cada aplicativo pode se comunicar por meio dele. A seguir estão algumas orientações sobre quando usar ESB -

• Integrating two or more applications - O uso da arquitetura ESB é benéfico quando há necessidade de integrar dois ou mais serviços ou aplicativos.

• Integration of more applications in future - Suponha que se desejamos adicionar mais serviços ou aplicativos no futuro, isso pode ser feito facilmente com a ajuda da arquitetura ESB.

• Using multiple protocols - No caso de precisarmos usar vários protocolos como HTTP, FTP, JMS etc., ESB é a opção certa.

• Message routing - Podemos usar ESB no caso de exigirmos o roteamento de mensagens com base no conteúdo da mensagem e outros parâmetros semelhantes.

• Composition and consumption - ESB pode ser usado se precisarmos publicar serviços para composição e consumo.

Integração P2P vs. integração ESB

Com o aumento do número de aplicativos, uma grande dúvida aos desenvolvedores era como conectar diferentes aplicativos? A situação foi tratada codificando manualmente uma conexão entre vários aplicativos. Isso é chamadopoint-to-point integration.

Rigidityé a desvantagem mais óbvia da integração ponto a ponto. A complexidade aumenta com o aumento do número de conexões e interfaces. As desvantagens da integração P-2-P nos levam à integração ESB.

ESB é uma abordagem mais flexível para integração de aplicativos. Ele encapsula e expõe a funcionalidade de cada aplicativo como um conjunto de recursos reutilizáveis ​​discretos. Nenhum aplicativo se integra diretamente a outro, em vez disso, eles se integram por meio de um ESB, conforme mostrado abaixo -

Para gerenciar a integração, o ESB possui os seguintes dois componentes -

• Service Registry- Mule ESB tem Service Registry / Repository onde todos os serviços expostos no ESB são publicados e registrados. Ele atua como um ponto de descoberta de onde se pode consumir os serviços e recursos de outros aplicativos.

• Centralized Administration - Como o nome indica, fornece uma visão dos fluxos transacionais de desempenho das interações que ocorrem dentro do ESB.

ESB Functionality- A abreviatura VETRO é geralmente usada para resumir a funcionalidade do ESB. É o seguinte -

• V(Validar) - Como o nome indica, ele valida a validação do esquema. Requer um analisador de validação e esquema atualizado. Um exemplo é um documento XML confirmando um esquema atualizado.

• E(Enriquecer) - Adiciona dados adicionais a uma mensagem. O objetivo é tornar a mensagem mais significativa e útil para um serviço de destino.

• T(Transformar) - Converte a estrutura de dados em um formato canônico ou de um formato canônico. Exemplos são a conversão de data / hora, moeda, etc.

• R(Roteamento) - Ele roteará a mensagem e atuará como um porteiro do endpoint de um serviço.

• O(Operar) - A principal tarefa desta função é invocar o serviço de destino ou interagir com o aplicativo de destino. Eles são executados no backend.

O padrão VETRO fornece flexibilidade geral para a integração e garante que apenas dados consistentes e validados sejam encaminhados para o ESB.

O que é Mule ESB?

O Mule ESB é um barramento de serviço empresarial (ESB) e plataforma de integração baseado em Java, leve e altamente escalável, fornecido pela MuleSoft. O Mule ESB permite ao desenvolvedor conectar aplicativos de forma fácil e rápida. Independentemente das várias tecnologias usadas pelos aplicativos, o Mule ESB permite uma fácil integração de aplicativos, permitindo que eles troquem dados. O Mule ESB tem as seguintes duas edições -

• Edição da comunidade
• Enterprise Edition

Uma vantagem do Mule ESB é que podemos facilmente atualizar da comunidade Mule ESB para o Mule ESB enterprise porque ambas as edições são construídas em uma base de código comum.

Recursos e capacidades do Mule ESB

As seguintes características são possuídas pelo Mule ESB -

• Possui design gráfico simples de arrastar e soltar.
• O Mule ESB é capaz de mapeamento e transformação de dados visuais.
• O usuário pode obter a facilidade de centenas de conectores certificados pré-fabricados.
• Monitoramento e administração centralizada.
• Ele fornece recursos robustos de aplicação de segurança corporativa.
• Ele fornece a facilidade de gerenciamento de API.
• Há um gateway de dados seguro para conectividade em nuvem / local.
• Ele fornece o registro de serviço onde todos os serviços expostos no ESB são publicados e registrados.
• Os usuários podem ter controle por meio de um console de gerenciamento baseado na web.
• A depuração rápida pode ser realizada usando o analisador de fluxo de serviço.

As motivações por trás do projeto Mule foram -

• para tornar as coisas mais simples para os programadores,

• a necessidade de uma solução leve e modular que pudesse escalar de uma estrutura de mensagens no nível do aplicativo a uma estrutura altamente distribuível em toda a empresa.

O Mule ESB foi projetado como uma estrutura orientada a eventos e programática. É orientado por eventos porque é combinado com a representação unificada de mensagens e pode ser expansível com módulos plugáveis. É programático porque os programadores podem facilmente implantar alguns comportamentos adicionais, como processamento de mensagens específicas ou transformação de dados personalizados.

História

A perspectiva histórica do projeto Mule é a seguinte -

Projeto SourceForge

O projeto Mule foi iniciado como projeto SourceForge em abril de 2003 e, após 2 anos, sua primeira versão foi lançada e movida para CodeHaus. A API Universal Message Object (UMO) estava no centro de sua arquitetura. A ideia por trás da API UMO era unificar a lógica enquanto os mantinha isolados dos transportes subjacentes.

Versão 1.0

Foi lançado em abril de 2005 contendo vários transportes. O foco principal de muitas outras versões seguidas por ele foi a depuração e adição de novos recursos.

Versão 2.0 (Adoção da Primavera 2)

O Spring 2 como estrutura de configuração e fiação foi adotado no Mule 2, mas provou ser uma grande revisão por causa da falta de expressividade da configuração XML necessária. Esse problema foi resolvido quando a configuração baseada em esquema XML foi introduzida no Spring 2.

Construindo com Maven

A maior melhoria que simplificou o uso do Mule, tanto no desenvolvimento quanto na implantação, foi o uso do Maven. A partir da versão 1.3, ele começou a ser construído com o Maven.

MuleSource

Em 2006, o MuleSource foi incorporado “para ajudar a apoiar e capacitar a comunidade em rápido crescimento que usa o Mule em aplicativos corporativos de missão crítica”. Provou ser o marco fundamental para o Projeto Mula.

Concorrentes do Mule ESB

A seguir estão alguns dos principais concorrentes do Mule ESB -

• WSO2 ESB
• Oracle Service Bus
• WebSphere Message Broker
• Plataforma Aurea CX
• Fiorano ESB
• WebSphere DataPower Gateway
• Estrutura do processo de negócios do dia de trabalho
• Talend Enterprise Service Bus
• JBoss Enterprise Service Bus
• iWay Service Manager

Mule's Core Concept

Conforme discutido, Mule ESB é um barramento de serviço corporativo (ESB) e plataforma de integração leve e altamente escalável baseado em Java. Independentemente das várias tecnologias usadas pelos aplicativos, o Mule ESB permite uma fácil integração de aplicativos, permitindo que eles troquem dados. Nesta seção, discutiremos sobre o conceito central do Mule entrando em ação para fazer essa integração acontecer.

Para isso, precisamos entender sua arquitetura, bem como os blocos de construção.

Arquitetura

A arquitetura do Mule ESB tem três camadas, a saber, camada de transporte, camada de integração e camada de aplicação, conforme mostrado no diagrama a seguir -

Geralmente, existem três tipos de tarefas que podem ser realizadas para configurar e personalizar a implantação do Mule -

Desenvolvimento de componentes de serviço

Esta tarefa envolve o desenvolvimento ou reutilização dos POJOs ou Spring Beans existentes. POJOs é uma classe com atributos que gera os métodos get e set, conectores de nuvem. Por outro lado, Spring Beans contém a lógica de negócios para enriquecer as mensagens.

Orquestração de Serviço

Essa tarefa fornece basicamente a mediação de serviço que envolve a configuração do processador de mensagens, roteadores, transformadores e filtros.

Integração

A tarefa mais importante do Mule ESB é a integração de vários aplicativos, independentemente dos protocolos que estão usando. Para isso, o Mule fornece métodos de transporte que permitem receber e despachar as mensagens em vários conectores de protocolo. O Mule suporta muitos métodos de transporte existentes, ou também podemos usar um método de transporte personalizado.

Blocos de construção

A configuração do Mule tem os seguintes blocos de construção -

Feijão primavera

O principal uso dos beans Spring é construir componentes de serviço. Após construir o componente do serviço spring, podemos defini-lo através de um arquivo de configuração ou manualmente, caso você não tenha arquivo de configuração.

Agentes

É basicamente um serviço criado no Anypoint Studio antes do Mule Studio. Um agente é criado assim que você inicia um servidor e será destruído assim que você parar o servidor.

Conector

É um componente de software configurado com os parâmetros específicos dos protocolos. É usado principalmente para controlar o uso de um protocolo. Por exemplo, um conector JMS é configurado com umConnection e esse conector será compartilhado entre várias entidades responsáveis ​​pela comunicação real.

Configuração Global

Como o nome indica, este bloco de construção é usado para definir as propriedades e configurações globais.

Endpoints globais

Ele pode ser usado na guia Elementos globais, que pode ser usada quantas vezes em um fluxo -

Processador de Mensagem Global

Como o nome indica, ele observa ou modifica uma mensagem ou fluxo de mensagens. Transformers e filtros são os exemplos do Global Message Processor.

Transformers- A principal tarefa de um transformador é converter dados de um formato para outro. Ele pode ser definido globalmente e pode ser usado em vários fluxos.

Filters- É o filtro que vai decidir qual mensagem Mule deve ser processada. O filtro especifica basicamente as condições que devem ser atendidas para que uma mensagem seja processada e roteada para um serviço.

Modelos

Em contraste com os agentes, é um agrupamento lógico de serviços que são criados no estúdio. Temos a liberdade de iniciar e interromper todos os serviços dentro de um modelo específico.

Services- Os serviços são aqueles que envolvem nossa lógica de negócios ou componentes. Ele também configura roteadores, terminais, transformadores e filtros especificamente para esse serviço.

Endpoints- Pode ser definido como um objeto no qual os serviços irão receber (receber) e enviar (enviar) mensagens. Os serviços são conectados por meio de terminais.

Fluxo

O processador de mensagens usa fluxos para definir um fluxo de mensagens entre uma origem e um destino.

Estrutura da Mensagem Mula

Uma mensagem Mule, totalmente envolvida em Objeto de Mensagem Mule, são os dados que passam pelos aplicativos por meio de fluxos Mule. A estrutura da mensagem do Mule é mostrada no diagrama a seguir -

Como visto no diagrama acima, a Mensagem Mula consiste em duas partes principais -

Cabeçalho

Nada mais é que os metadados da mensagem, que são posteriormente representados pelas duas propriedades a seguir -

Inbound Properties- Estas são as propriedades que são definidas automaticamente pela origem da mensagem. Eles não podem ser manipulados ou configurados pelo usuário. Na natureza, as propriedades de entrada são imutáveis.

Outbound Properties- Essas são as propriedades que contêm metadados como uma propriedade de entrada e podem ser configuradas durante o curso do fluxo. Eles podem ser configurados automaticamente pelo Mule ou manualmente por um usuário. Na natureza, as propriedades de saída são mutáveis.

As propriedades de saída tornam-se propriedades de entrada quando a mensagem passa do terminal de saída de um fluxo para o terminal de entrada de um fluxo diferente por meio de um transporte.

As propriedades de saída permanecem propriedades de saída quando a mensagem é passada para um novo fluxo por meio de um flow-ref em vez de um conector.

Carga útil

A mensagem de negócios real transportada pelo objeto de mensagem é chamada de carga útil.

Variáveis

Pode ser definido como os metadados definidos pelo usuário sobre uma mensagem. Basicamente, as variáveis ​​são informações temporárias sobre uma mensagem usada pelo aplicativo que a está processando. Não se destina a ser transmitido com as mensagens ao seu destino. Eles são de três tipos, conforme indicado abaixo -

Flow variables - Essas variáveis ​​se aplicam apenas ao fluxo em que existem.

Session variables - Essas variáveis ​​se aplicam a todos os fluxos dentro do mesmo aplicativo.

Record variables - Essas variáveis ​​se aplicam apenas a registros processados ​​como parte de um lote.

Anexos e carga extra

Esses são alguns metadados extras sobre a carga útil da mensagem que não necessariamente aparecem todas as vezes no objeto da mensagem.

Nos capítulos anteriores, aprendemos o básico do Mule ESB. Neste capítulo, vamos aprender como instalá-lo e configurá-lo.

Pré-requisitos

Precisamos satisfazer os seguintes pré-requisitos antes de instalar o Mule em nosso computador -

Kit de Desenvolvimento Java (JDK)

Antes de instalar o MULE, verifique se você tem uma versão compatível do Java em seu sistema. O JDK 1.8.0 é recomendado para instalar o Mule em seu sistema com sucesso.

Sistema operacional

Os seguintes sistemas operacionais são suportados pelo Mule -

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

Base de dados

Um servidor de aplicativos ou banco de dados não é necessário, pois o Mule Runtime é executado como um servidor independente. Mas se precisarmos acessar um armazenamento de dados ou quisermos usar um servidor de aplicativos, os seguintes servidores de aplicativos ou bancos de dados suportados podem ser usados ​​-

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

Requisitos de sistema

Antes de instalar o Mule em seu sistema, ele deve cumprir os seguintes requisitos de sistema -

• CPU de pelo menos 2 GHz ou 1 CPU virtual em ambientes virtualizados
• Mínimo 1 GB de RAM
• Armazenamento mínimo de 4 GB

Baixar Mule

Para baixar o arquivo binário do Mule 4, clique no link https://www.mulesoft.com/lp/dl/mule-esb-enterprise e isso o levará à página oficial da MuleSoft da seguinte maneira -

Ao fornecer os detalhes necessários, você pode obter o arquivo binário Mule 4 no formato Zip.

Instale e execute o Mule

Agora, depois de baixar o arquivo binário Mule 4, descompacte-o e defina uma variável de ambiente chamada MULE_HOME para o diretório Mule dentro da pasta extraída.

Por exemplo, a variável de ambiente, em ambientes Windows e Linux / Unix, pode ser definida para a versão 4.1.5 no diretório Downloads da seguinte forma -

Ambientes Windows

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

Ambientes Unix / Linux

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

Agora, para testar se o Mule está sendo executado em seu sistema sem nenhum erro, use os seguintes comandos -

Ambientes Windows

$ $MULE_HOME\bin\mule.bat

Ambientes Unix / Linux

$ $MULE_HOME/bin/mule

Os comandos acima irão executar o Mule no modo de primeiro plano. Se o Mule estiver em execução, não podemos emitir nenhum outro comando no terminal. Pressionandoctrl-c comando no terminal, irá parar o Mule.

Iniciar os serviços Mule

Podemos iniciar o Mule como um serviço do Windows e também como um Linux / Unix Daemon.

Mule como um serviço do Windows

Para executar o Mule como um serviço do Windows, precisamos seguir as etapas abaixo -

Step 1 - Primeiro, instale-o com a ajuda do seguinte comando -

$ $MULE_HOME\bin\mule.bat install

Step 2 - Uma vez instalado, podemos executar o mule como um serviço do Windows com a ajuda do seguinte comando:

$ $MULE_HOME\bin\mule.bat start

Mule como um Linux / Unix Daemon

Para executar o Mule como um Linux / Unix Daemon, precisamos seguir os passos abaixo -

Step 1 - Instale-o com a ajuda do seguinte comando -

$ $MULE_HOME/bin/mule install

Step 2 - Uma vez instalado, podemos executar o mule como um serviço do Windows com a ajuda do seguinte comando -

$ $MULE_HOME/bin/mule start

Example

O exemplo a seguir inicia o Mule como um Daemon 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

Implantar aplicativos Mule

Podemos implantar nossos aplicativos Mule com a ajuda das seguintes etapas -

Step 1 - Primeiro, inicie o Mule.

Step 2 - Assim que o Mule for iniciado, podemos implantar nossos aplicativos Mule movendo nossos arquivos de pacote JAR para o apps diretório em $MULE_HOME.

Stop Mule Services

Podemos usar stopcomando para parar o Mule. Por exemplo, o exemplo a seguir inicia o Mule como um Daemon 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.

Também podemos usar removecomando para remover o Mule Service ou Daemon de nosso sistema. O exemplo a seguir remove o Mule como um Daemon 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 da MuleSoft é um software amigável IDE (integration development environment)usado para projetar e testar aplicativos Mule. É um IDE baseado em Eclipse. Podemos facilmente arrastar Conectores da Paleta de Mulas. Em outras palavras, Anypoint Studio é um IDE baseado em Eclipse para desenvolvimento de fluxo, etc.

Pré-requisitos

Precisamos satisfazer os seguintes pré-requisitos antes de instalar o Mule em todos os sistemas operacionais, ou seja, Windows, Mac e Linux / Unix.

Java Development Kit (JDK)- Antes de instalar o Mule, verifique se você tem uma versão compatível do Java em seu sistema. O JDK 1.8.0 é recomendado para instalar o Anypoint com sucesso em seu sistema.

Baixando e instalando o Anypoint Studio

O procedimento para baixar e instalar o Anypoint Studio em diferentes sistemas operacionais pode variar. Em seguida, há etapas a serem seguidas para baixar e instalar o Anypoint Studio em vários sistemas operacionais -

No Windows

Para baixar e instalar o Anypoint Studio no Windows, precisamos seguir as etapas abaixo -

Step 1 - Primeiro, clique no link https://www.mulesoft.com/lp/dl/studio e escolha o sistema operacional Windows na lista de cima para baixo para baixar o estúdio.

Step 2 - Agora, extraia-o no ‘C:\’ pasta raiz.

Step 3 - Abra o Anypoint Studio extraído.

Step 4- Para aceitar o espaço de trabalho padrão, clique em OK. Você receberá uma mensagem de boas-vindas quando ele for carregado pela primeira vez.

Step 5 - Agora, clique no botão Get Started para usar o Anypoint Studio.

No OS X

Para baixar e instalar o Anypoint Studio no OS X, precisamos seguir as etapas abaixo -

Step 1 - Primeiro, clique no link https://www.mulesoft.com/lp/dl/studio e baixe o estúdio.

Step 2- Agora, extraia. Caso você esteja usando a versão do sistema operacional Sierra, certifique-se de mover o aplicativo extraído para/Applications folder antes de lançá-lo.

Step 3 - Abra o Anypoint Studio extraído.

Step 4- Para aceitar o espaço de trabalho padrão, clique em OK. Você receberá uma mensagem de boas-vindas quando ele for carregado pela primeira vez.

Step 5 - Agora clique em Get Started botão para usar o Anypoint Studio.

Se você for usar um caminho personalizado para seu espaço de trabalho, observe que o Anypoint Studio não expande o ~ til usado em sistemas Linux / Unix. Portanto, é recomendável usar o caminho absoluto ao definir a área de trabalho.

Em Linux

Para baixar e instalar o Anypoint Studio no Linux, precisamos seguir as etapas abaixo -

Step 1 - Primeiro, clique no link https://www.mulesoft.com/lp/dl/studio e escolha o sistema operacional Linux na lista de cima para baixo para baixar o estúdio.

Step 2 - Agora, extraia.

Step 3 - Em seguida, abra o Anypoint Studio extraído.

Step 4- Para aceitar o espaço de trabalho padrão, clique em OK. Você receberá uma mensagem de boas-vindas quando ele for carregado pela primeira vez.

Step 5 - Agora, clique no botão Get Started para usar o Anypoint Studio.

Se você for usar um caminho personalizado para seu espaço de trabalho, observe que o Anypoint Studio não expande o ~ til usado em sistemas Linux / Unix. Portanto, é recomendável usar o caminho absoluto ao definir a área de trabalho.

Também é recomendado instalar GTK versão 2 para usar Temas completos do Studio no Linux.

Recursos do Anypoint Studio

A seguir estão alguns recursos do Anypoint Studio que aumentam a produtividade durante a construção de aplicativos Mule -

• Ele fornece uma execução instantânea do aplicativo Mule dentro de um tempo de execução local.

• Anypoint Studio nos dá um editor visual para configurar arquivos de definição de API e domínios Mule.

• Ele tem uma estrutura de teste de unidade incorporada, aumentando a produtividade.

• Anypoint studio nos fornece o suporte integrado para implantar no CloudHub.

• Possui a facilidade de integração com o Exchange para importação de modelos, exemplos, definições e outros recursos de outra organização da Anypoint Platform.

Os editores do Anypoint Studio nos ajudam a projetar nossos aplicativos, APIs, propriedades e arquivos de configuração. Junto com o design, também nos ajuda a editá-los. Temos o editor de arquivos de configuração Mule para este propósito. Para abrir este editor, clique duas vezes no arquivo XML do aplicativo em/src/main/mule.

Para trabalhar com nosso aplicativo, temos as três guias a seguir no editor de arquivo de configuração do Mule.

A guia Fluxo de Mensagens

Esta guia fornece uma representação visual do fluxo de trabalho. Ele basicamente contém uma tela que nos ajuda a verificar nossos fluxos visualmente. Se você deseja adicionar Processadores de Eventos da Paleta Mula à tela, basta arrastar e soltar e isso refletirá na tela.

Ao clicar em um Processador de Eventos, você pode obter a Visualização de Propriedades do Mule com os atributos do processador selecionado. Também podemos editá-los.

A guia Elementos Globais

Esta guia contém os elementos de configuração global do Mule para os módulos. Nessa guia, podemos criar, editar ou excluir arquivos de configuração.

A guia XML de configuração

Como o nome indica, ele contém o XML que define seu aplicativo Mule. Todas as alterações feitas aqui refletirão na tela, bem como na visualização de propriedades do processador de eventos na guia Fluxo de Mensagens.

Visualizações

Para o editor ativo, Anypoint Studio nos dá a representação gráfica dos metadados do nosso projeto, propriedades com a ajuda de visualizações. O usuário pode mover, fechar e adicionar visualizações no projeto Mule. A seguir estão algumas visualizações padrão no Anypoint Studio -

Package Explorer

A principal tarefa da visualização do Package Explorer é exibir as pastas e arquivos do projeto consistidos em um projeto Mule. Podemos expandir ou contrair a pasta do projeto Mule clicando na seta ao lado dela. Uma pasta ou arquivo pode ser aberto clicando duas vezes nele. Dê uma olhada em sua captura de tela -

Paleta Mula

A visualização Mule Palette mostra os processadores de eventos como escopos, filtros e roteadores de controle de fluxo junto com os módulos e suas operações relacionadas. As principais tarefas da visualização Mule Palette são as seguintes -

• Esta visualização nos ajuda a gerenciar os módulos e conectores em nosso projeto.
• Também podemos adicionar novos elementos do Exchange.

Dê uma olhada em sua captura de tela -

Propriedades da mula

Como o nome indica, ele nos permite editar as propriedades do módulo atualmente selecionado em nossa tela. A visualização das propriedades da mula inclui o seguinte -

• DataSense Explorer que fornece informações em tempo real sobre a estrutura de dados de nossa carga útil.

• Propriedades de entrada e saída, se disponíveis ou variáveis.

Abaixo está a imagem -

Console

Sempre que criamos ou executamos o aplicativo Mule, o servidor Mule embutido exibe uma lista de eventos e problemas, se houver, relatados pelo Studio. A exibição do console contém o console desse servidor Mule integrado. Dê uma olhada em sua captura de tela -

Visão de Problemas

Podemos encontrar muitos problemas enquanto trabalhamos em nosso Projeto Mula. Todos esses problemas são exibidos na visualização Problems. Abaixo está a imagem

Perspectivas

No Anypoint Studio, é uma coleção de visualizações e editores em um arranjo especificado. Existem dois tipos de perspectivas no Anypoint Studio -

Mule Design Perspective - É a perspectiva padrão que obtemos no Studio.

Mule Debug Perspective - Outra perspectiva fornecida pelo Anypoint Studio é a perspectiva Mule Debug.

Por outro lado, também podemos criar nossa própria perspectiva e adicionar ou remover qualquer uma das visualizações padrão.

Neste capítulo, vamos criar nosso primeiro aplicativo Mule no Anypoint Studio da MuleSoft. Para criá-lo, primeiro precisamos iniciar o Anypoint Studio.

Iniciando Anypoint Studio

Clique em Anypoint Studio para iniciá-lo. Se você estiver lançando pela primeira vez, verá a seguinte janela -

Interface do usuário do Anypoint Studio

Depois de clicar no botão Go to Workspace, ele o levará para a interface do usuário do Anypoint Studio da seguinte maneira -

Etapas para criar um aplicativo Mule

Para criar seu aplicativo Mule, siga as etapas abaixo -

Criando Novo Projeto

O primeiro passo para criar um aplicativo Mule é criar um novo projeto. Isso pode ser feito seguindo o caminhoFILE → NEW → Mule Project como mostrado abaixo -

Nomeando o Projeto

Após clicar no novo Projeto Mula, conforme descrito acima, será aberta uma nova janela solicitando o nome do projeto e outras especificações. Dê o nome do projeto, 'TestAPP1'e, a seguir, clique no botão Concluir.

Depois de clicar no botão Concluir, ele abrirá a área de trabalho construída para o seu MuleProject, a saber ‘TestAPP1’. Você pode ver todos osEditors e Views descrito no capítulo anterior.

Configurando o Conector

Aqui, vamos construir um aplicativo Mule simples para HTTP Listener. Para isso, precisamos arrastar o conector HTTP Listener do Mule Palette e soltá-lo na área de trabalho conforme mostrado abaixo -

Agora, precisamos configurá-lo. Clique na cor verde + sinal após a configuração do conector em Configurações básicas, conforme mostrado acima.

Ao clicar em ok, ele o levará de volta à página de propriedades do HTTP Listener. Agora precisamos fornecer o caminho na guia Geral. Neste exemplo específico, fornecemos/FirstAPP como nome do caminho.

Configurando Set Payload Connector

Agora, precisamos pegar um conector Set Payload. Também precisamos fornecer seu valor na guia Configurações da seguinte forma -

This is my first Mule Application, é o nome fornecido neste exemplo.

Aplicação Mula em execução

Agora, salve e clique Run as Mule Application como mostrado abaixo -

Podemos verificá-lo no Console, que implementa o aplicativo da seguinte maneira -

Isso mostra que você construiu com sucesso seu primeiro aplicativo Mule.

Verificando o aplicativo Mule

Agora, precisamos testar se nosso aplicativo está funcionando ou não. Go to POSTMAN, um aplicativo do Chrome e digite o Url: http:/localhost:8081. Ele mostra a mensagem que fornecemos durante a construção do aplicativo Mule, conforme mostrado abaixo -

DataWeave é basicamente uma linguagem de expressão MuleSoft. É usado principalmente para acessar e transformar os dados recebidos por meio de um aplicativo Mule. O tempo de execução Mule é responsável por executar o script e as expressões em nosso aplicativo Mule, o DataWeave é fortemente integrado ao tempo de execução Mule.

Recursos da linguagem DataWeave

A seguir estão alguns recursos importantes da linguagem DataWeave -

Os dados podem ser transformados de um formato para outro com muita facilidade. Por exemplo, podemos transformar application / json em application / xml. A carga útil de entrada é a seguinte -

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

A seguir está o código em DataWeave para transformação -

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

A seguir, o output a carga útil é a seguinte -

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

O componente de transformação pode ser usado para criar scripts que executam transformações de dados simples e complexas.

Podemos acessar e usar as funções principais do DataWeave em partes do evento Mule de que precisamos, pois a maioria dos processadores de mensagem Mule oferece suporte a expressões DataWeave.

Pré-requisitos

Precisamos satisfazer os seguintes pré-requisitos antes de usar scripts DataWeave em nosso computador -

• Anypoint Studio 7 é necessário para usar scripts Dataweave.

• Depois de instalar o Anypoint Studio, precisamos configurar um projeto com um componente Transform Message para usar scripts DataWeave.

Etapas para usar o script DataWeave com exemplo

Para usar o script DataWeave, precisamos seguir as etapas abaixo -

Step 1

Primeiro, precisamos configurar um novo projeto, como fizemos no capítulo anterior, usando File → New → Mule Project.

Step 2

Em seguida, precisamos fornecer o nome do projeto. Para este exemplo, estamos dando o nome,Mule_test_script.

Step 3

Agora, precisamos arrastar o Transform Message component de Mule Palette tab para dentro canvas. É mostrado como abaixo -

Step 4

Em seguida, no Transform Message componentguia, clique em Visualizar para abrir o painel de visualização. Podemos expandir a área do código-fonte clicando no retângulo vazio ao lado de Visualizar.

Step 5

Agora, podemos começar a criar scripts com a linguagem DataWeave.

Exemplo

A seguir está o exemplo simples de concatenar duas strings em uma -

O script DataWeave acima tem um par de valores-chave ({ myString: ("hello" ++ "World") }) que concatenará duas strings em uma.

Os módulos de script facilitam os usuários a usar a linguagem de script no Mule. Em palavras simples, o módulo de script pode trocar lógica personalizada escrita em linguagem de script. Os scripts podem ser usados ​​como implementações ou transformadores. Eles podem ser usados ​​para avaliação de expressão, ou seja, para controlar o roteamento de mensagens.

O Mule tem as seguintes linguagens de script suportadas -

• Groovy
• Python
• JavaScript
• Ruby

Como instalar módulos de script?

Na verdade, Anypoint Studio vem com os módulos de script. Se você não encontrar o módulo no Mule Palette, ele pode ser adicionado usando+Add Module. Depois de adicionar, podemos usar as operações do módulo de script em nosso aplicativo Mule.

Exemplo de implementação

Conforme discutido, precisamos arrastar e soltar o módulo na tela para criar um espaço de trabalho e usá-lo em nosso aplicativo. A seguir está um exemplo disso -

Já sabemos como configurar o componente HTTP Listener; portanto, vamos discutir sobre como configurar os Módulos de Scripting. Precisamos seguir as etapas escritas abaixo para configurar o módulo de script -

Step 1

Procure o módulo Scripting no Mule Palette e arraste o EXECUTE operação do módulo de script em seu fluxo, conforme mostrado acima.

Step 2

Agora, abra a aba Execute configuration clicando duas vezes na mesma.

Step 3

Debaixo de General guia, precisamos fornecer o código no Code text window como mostrado abaixo -

Step 4

Por fim, precisamos escolher o Enginedo componente de execução. A lista de motores é a seguinte -

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

O XML do exemplo de execução acima no editor XML de configuração é o seguinte -

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

Fontes de mensagens

O Mule 4 tem um modelo simplificado do que a mensagem do Mule 3, tornando mais fácil trabalhar com dados de uma forma consistente entre os conectores sem sobrescrever informações. No modelo de mensagem Mule 4, cada evento Mule consiste em duas coisas:a message and variables associated with it.

Uma mensagem do Mule tem carga útil e seus atributos, onde o atributo é principalmente metadados, como o tamanho do arquivo.

E uma variável contém as informações arbitrárias do usuário, como resultado da operação, valores auxiliares, etc.

De entrada

As propriedades de entrada no Mule 3 agora se tornam Atributos no Mule 4. Como sabemos, as propriedades de entrada armazenam informações adicionais sobre a carga obtida por meio de uma fonte de mensagem, mas isso agora é, no Mule 4, feito com a ajuda de atributos. Os atributos têm as seguintes vantagens -

• Com a ajuda de atributos, podemos ver facilmente quais dados estão disponíveis, porque os atributos são fortemente tipados.

• Podemos acessar facilmente as informações contidas nos atributos.

A seguir está o exemplo de uma mensagem típica no Mule 4 -

Saída

As propriedades de saída no Mule 3 devem ser especificadas explicitamente pelos conectores e transportes Mule para enviar dados adicionais. Mas no Mule 4, cada um deles pode ser definido separadamente, usando uma expressão DataWeave para cada um deles. Não produz nenhum efeito colateral no fluxo principal.

Por exemplo, a expressão DataWeave abaixo executará uma solicitação HTTP e gerará cabeçalhos e parâmetros de consulta sem a necessidade de definir as propriedades da mensagem. Isso é mostrado no código abaixo -

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

Processador de Mensagens

Assim que o Mule recebe uma mensagem de uma fonte de mensagem, o trabalho do processador de mensagens começa. O Mule usa um ou mais processadores de mensagem para processar a mensagem por meio de um fluxo. A principal tarefa do processador de mensagens é transformar, filtrar, enriquecer e processar a mensagem conforme ela passa pelo fluxo Mule.

Categorização do processador Mule

A seguir estão as categorias do Processador Mule, com base nas funções -

• Connectors- Esses processadores de mensagens enviam e recebem dados. Eles também conectam dados em fontes de dados externas por meio de protocolos padrão ou APIs de terceiros.

• Components - Esses processadores de mensagens são de natureza flexível e executam lógica de negócios implementada em várias linguagens como Java, JavaScript, Groovy, Python ou Ruby.

• Filters - Eles filtram as mensagens e permitem que apenas mensagens específicas continuem sendo processadas em um fluxo, com base em critérios específicos.

• Routers - Este processador de mensagens é usado para controlar o fluxo de mensagens a serem roteadas, sequenciadas ou divididas.

• Scopes - basicamente empacote trechos de código com o propósito de definir um comportamento de baixa granularidade dentro de um fluxo.

• Transformers - A função dos transformadores é converter o tipo de carga útil da mensagem e o formato de dados para facilitar a comunicação entre os sistemas.

• Business Events - Eles basicamente capturam dados associados a indicadores-chave de desempenho.

• Exception strategies - Esses processadores de mensagens tratam de erros de qualquer tipo que ocorrem durante o processamento da mensagem.

Uma das habilidades mais importantes do Mule é que ele pode executar roteamento, transformação e processamento com os componentes, por isso o arquivo de configuração do aplicativo Mule que combina vários elementos é muito grande.

A seguir estão os tipos de padrões de configuração fornecidos pelo Mule -

• Padrão de serviço simples
• Bridge
• Validator
• Proxy HTTP
• Proxy WS

Configurando o componente

No Anypoint Studio, podemos seguir as etapas abaixo para configurar um componente -

Step 1

Precisamos arrastar o componente que desejamos usar em nosso aplicativo Mule. Por exemplo, aqui usamos o componente ouvinte HTTP da seguinte maneira -

Step 2

Em seguida, clique duas vezes no componente para obter a janela de configuração. Para ouvinte HTTP, é mostrado abaixo -

Step 3

Podemos configurar o componente de acordo com os requisitos do nosso projeto. Digamos, por exemplo, que fizemos para o componente de ouvinte HTTP -

Os componentes principais são um dos blocos de construção importantes do fluxo de trabalho no aplicativo Mule. A lógica para processar um evento Mule é fornecida por esses componentes principais. No Anypoint Studio, para acessar esses componentes principais, você pode clicar no Core da Mule Palette conforme mostrado abaixo -

A seguir estão vários core components and their working in Mule 4 -

Eventos de negócios personalizados

Este componente principal é usado para a coleta de informações sobre fluxos, bem como processadores de mensagens que lidam com as transações de negócios no aplicativo Mule. Em outras palavras, podemos usar o componente Custom Business Event para adicionar o seguinte em nosso fluxo de trabalho -

• Metadata
• Indicadores-chave de desempenho (KPIs)

Como adicionar KPIs?

A seguir estão as etapas para adicionar KPIs em nosso fluxo no aplicativo Mule -

Step 1 - Siga Mula Palette → Core → Components → Custom Business Event, para adicionar o componente Custom Business Event a um fluxo de trabalho em seu aplicativo Mule.

Step 2 - Clique no componente para abri-lo.

Step 3 - Agora, precisamos fornecer valores para Nome de exibição e Nome do evento.

Step 4 - Para capturar informações da carga útil da mensagem, adicione KPIs da seguinte forma -

• Dê um nome (chave) para o KPI ( rastreamento: elemento de metadados ) e um valor. O nome será usado na interface de pesquisa do Runtime Manager.

• Forneça um valor que pode ser qualquer expressão de Mula.

Exemplo

A tabela a seguir consiste na lista de KPIs com nome e valor -

Nome	Expressão / Valor
Student RollNo	# [carga útil ['RollNo']]
Nome do aluno	# [carga útil ['Nome']]

Avaliação Dinâmica

Este componente principal é usado para selecionar dinamicamente um script no aplicativo Mule. Também podemos usar script hardcore por meio do Transform Message Component, mas usar o componente Dynamic Evaluate é a melhor maneira. Este componente principal funciona da seguinte maneira -

• Primeiramente, ele avalia uma expressão que deve resultar em outro script.
• Em seguida, ele avalia esse script para o resultado final.

Dessa forma, ele nos permite selecionar dinamicamente o script em vez de codificá-lo permanentemente.

Exemplo

A seguir está um exemplo de seleção de um script do banco de dados por meio de um parâmetro de consulta Id e armazenamento desse script em uma variável chamada MyScript . Agora, o componente de avaliação dinâmica acessará a variável para invocar os scripts para que possa adicionar uma variável de nome deUName parâmetro de consulta.

A configuração XML do fluxo é fornecida abaixo -

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

O script pode usar variáveis ​​de contexto como mensagem, carga útil, vars ou atributos. No entanto, se você deseja adicionar uma variável de contexto personalizada, você precisa fornecer um conjunto de pares de valores-chave.

Configurando Avaliação Dinâmica

A tabela a seguir fornece uma maneira de configurar o componente Dynamic Evaluate -

Campo	Valor	Descrição	Exemplo
Expressão	Expressão DataWeave	Ele especifica a expressão a ser avaliada no script final.	expression = "# [vars.generateOrderScript]"
Parâmetros	Expressão DataWeave	Ele especifica pares de valores-chave.	# [{joiner: 'e', ​​id: payload.user.id}]

Componente de referência de fluxo

Se você deseja rotear o evento Mule para outro fluxo ou subfluxo e de volta no mesmo aplicativo Mule, o componente de referência de fluxo é a opção certa.

Características

A seguir estão as características deste componente principal -

• Este componente central nos permite tratar todo o fluxo referenciado como um único componente no fluxo atual.

• Ele divide o aplicativo Mule em unidades discretas e reutilizáveis. Por exemplo, um fluxo está listando arquivos regularmente. Ele pode fazer referência a outro fluxo que processa a saída da operação de lista.

• Dessa forma, em vez de anexar todas as etapas de processamento, podemos anexar Referências de Fluxo que apontam para o fluxo de processamento. A captura de tela abaixo mostra que o componente principal de referência de fluxo está apontando para um subfluxo denominadoProcessFiles.

Trabalhando

O funcionamento do componente Flow Ref pode ser compreendido com a ajuda do seguinte diagrama -

O diagrama mostra a ordem de processamento no aplicativo Mule quando um fluxo faz referência a outro fluxo no mesmo aplicativo. Quando o fluxo de trabalho principal no aplicativo Mule é acionado, o evento Mule viaja por completo e executa o fluxo até que o evento Mule alcance a Referência de Fluxo.

Após atingir a Referência de Fluxo, o evento Mule executa o fluxo referenciado do início ao fim. Assim que o evento Mule termina de executar o Ref Flow, ele retorna ao fluxo principal.

Exemplo

Para melhor compreensão, let us use this component in Anypoint Studio. Neste exemplo, estamos levando o ouvinte HTTP para GET uma mensagem, como fizemos no capítulo anterior. Portanto, podemos arrastar e soltar o componente e configurar. Mas, para este exemplo, precisamos adicionar um componente Subfluxo e definir o componente Payload sob ele, conforme mostrado abaixo -

Em seguida, precisamos configurar Set Payload, clicando duas vezes nele. Aqui estamos dando o valor, “Subfluxo executado” conforme mostrado abaixo -

Depois de configurar com êxito o componente de subfluxo, precisamos que o Componente de Referência de Fluxo seja definido após Definir Carga Útil do fluxo principal, que podemos arrastar e soltar da Paleta Mula, conforme mostrado abaixo -

Em seguida, ao configurar o componente de referência de fluxo, precisamos escolher o nome do fluxo na guia genérico, conforme mostrado abaixo -

Agora, salve e execute este aplicativo. Para testar isso, vá para POSTMAN e digitehttp:/localhost:8181/FirstAPP na barra de URL, e você obterá a mensagem Subfluxo executado.

Componente Logger

O componente principal chamado logger nos ajuda a monitorar e depurar nosso aplicativo Mule, registrando informações importantes como mensagens de erro, notificações de status, cargas úteis, etc. No AnyPoint Studio, eles aparecem no Console.

Vantagens

A seguir estão algumas vantagens do Componente Logger -

• Podemos adicionar esse componente central em qualquer lugar do fluxo de trabalho.
• Podemos configurá-lo para registrar uma string especificada por nós.
• Podemos configurá-lo para a saída de uma expressão DataWeave escrita por nós.
• Também podemos configurá-lo para qualquer combinação de strings e expressões.

Exemplo

O exemplo abaixo exibe a mensagem “Hello World” no Set Payload em um navegador e registra a mensagem também.

A seguir está a configuração XML do fluxo no exemplo acima -

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

Transferir componente de mensagem

O Transform Message Component, também chamado de componente Transfer, nos permite converter os dados de entrada em um novo formato de saída.

Métodos para construir a transformação

Podemos construir nossa transformação com a ajuda dos dois métodos a seguir -

Drag-and-Drop Editor (Graphical View)- Este é o primeiro e mais utilizado método para construir nossa transformação. Nesse método, podemos usar o mapeador visual desse componente para arrastar e soltar os elementos da estrutura de dados de entrada. Por exemplo, no diagrama a seguir, duas visualizações em árvore mostram as estruturas de metadados esperadas de entrada e saída. As linhas que conectam a entrada ao campo de saída representam o mapeamento entre duas visualizações em árvore.

Script View- O mapeamento visual da Transformação também pode ser representado com a ajuda do DataWeave, uma linguagem para código Mule. Podemos fazer a codificação para algumas transformações avançadas, como agregação, normalização, agrupamento, junção, particionamento, dinamização e filtragem. O exemplo é dado abaixo -

Este componente principal basicamente aceita metadados de entrada e saída para uma variável, um atributo ou carga útil de mensagem. Podemos fornecer recursos específicos de formato para o seguinte -

• CSV
• Schema
• Esquema de arquivo simples
• JSON
• Classe de objeto
• Tipo Simples
• Esquema XML
• Nome e tipo da coluna do Excel
• Nome e tipo da coluna de largura fixa

Os terminais incluem basicamente aqueles componentes que acionam ou iniciam o processamento em um fluxo de trabalho do aplicativo Mule. Eles são chamadosSource no Anypoint Studio e Triggersno Centro de Design de Mule. Um ponto final importante no Mule 4 éScheduler component.

Endpoint do agendador

Este componente funciona em condições baseadas no tempo, ou seja, nos permite acionar um fluxo sempre que uma condição baseada no tempo é atendida. Por exemplo, um planejador pode acionar um evento para iniciar um fluxo de trabalho do Mule a cada, digamos 10 segundos. Também podemos usar a expressão Cron flexível para acionar um Endpoint do Scheduler.

Pontos importantes sobre o Scheduler

Ao usar o evento Scheduler, precisamos cuidar de alguns pontos importantes, conforme fornecido abaixo -

• O Scheduler Endpoint segue o fuso-horário da máquina onde o tempo de execução do Mule está sendo executado.

• Suponha que se um aplicativo Mule estiver em execução no CloudHub, o Scheduler seguirá o fuso horário da região em que o trabalhador CloudHub está sendo executado.

• A qualquer momento, apenas um fluxo acionado pelo Endpoint do Scheduler pode estar ativo.

• No cluster de tempo de execução Mule, o Scheduler Endpoint é executado ou disparado apenas no nó primário.

Maneiras de configurar um Scheduler

Conforme discutido acima, podemos configurar um endpoint do agendador para ser acionado em um intervalo fixo ou também podemos fornecer uma expressão Cron.

Parâmetros para configurar um Scheduler (para intervalo fixo)

A seguir estão os parâmetros para definir um planejador para acionar um fluxo em intervalos regulares -

Frequency- Basicamente, descreve a frequência com que o Endpoint do Agendador acionará o fluxo Mule. A unidade de tempo para isso pode ser selecionada no campo Unidade de tempo. Caso você não forneça nenhum valor para isso, ele usará o valor padrão que é 1000. Por outro lado, se você fornecer 0 ou um valor negativo, então também usará o valor padrão.

Start Delay- É a quantidade de tempo que devemos esperar antes de acionar o fluxo Mule pela primeira vez, uma vez que o aplicativo é iniciado. O valor do atraso de início é expresso na mesma unidade de tempo que a frequência. Seu valor padrão é 0.

Time Unit- Descreve a unidade de tempo para Freqüência e Atraso de início. Os valores possíveis da unidade de tempo são Milissegundos, Segundos, Minuto, Horas, Dias. O valor padrão é Milissegundos.

Parâmetros para configurar um Scheduler (para Expressão Cron)

Na verdade, Cron é um padrão usado para descrever informações de hora e data. Caso você use a expressão Cron flexível para fazer o Scheduler disparar, o Scheduler Endpoint monitora cada segundo e cria um evento Mule sempre que a expressão Quartz Cron corresponde à configuração de data e hora. Com a expressão Cron, o evento pode ser disparado apenas uma vez ou em intervalos regulares.

A tabela a seguir fornece a expressão de data e hora de seis configurações necessárias -

Atributo	Valor
Segundos	0-59
Minutos	0-59
Horas	0-23
Dia do mês	1-31
Mês	1-12 ou JAN-DEC
Dia da semana	1-7 ou SUN-SAT

Alguns exemplos de expressões Quartz Cron suportadas pelo Scheduler Endpoint são fornecidos abaixo -

• ½ * * * * ? - significa que o planejador é executado a cada 2 segundos do dia, todos os dias.

• 0 0/5 16 ** ? - significa que o agendador é executado a cada 5 minutos, começando às 16h e terminando às 16h55, todos os dias.

• 1 1 1 1, 5 * ? - significa que o agendador funciona no primeiro dia de janeiro e no primeiro dia de abril de cada ano.

Exemplo

O código a seguir registra a mensagem “hi” a 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>

Controle de fluxo (roteadores)

A principal tarefa do componente Flow Control é pegar o evento Mule de entrada e encaminhá-lo para uma ou mais sequências separadas de componentes. É basicamente rotear o evento de entrada do Mule para outra (s) sequência (s) de componentes. Portanto, também é chamado de Roteadores. Os roteadores Choice e Scatter-Gather são os roteadores mais usados ​​no componente Flow Control.

Roteador Choice

Como o nome sugere, este roteador aplica a lógica DataWeave para escolher uma de duas ou mais rotas. Conforme discutido anteriormente, cada rota é uma sequência separada de processadores de eventos Mule. Podemos definir roteadores de escolha como o roteador que roteia mensagens dinamicamente por meio de um fluxo de acordo com um conjunto de expressões DataWeave usadas para avaliar o conteúdo da mensagem.

Diagrama esquemático do roteador de escolha

O efeito de usar o roteador Choice é como adicionar processamento condicional a um fluxo ou if/then/elsebloco de código na maioria das linguagens de programação. A seguir está o diagrama esquemático de um roteador de escolha, com três opções. Entre eles, um é o roteador padrão.

Roteador Scatter-Gather

Outro processador de evento de roteamento mais usado é Scatter-Gather component. Como o próprio nome indica, ele funciona nos fundamentos de scatters (copiar) e Gather (consolida). Podemos entender seu funcionamento com a ajuda de dois pontos a seguir -

• Primeiro, este roteador copia (Scatter) um evento Mule para duas ou mais rotas paralelas. A condição é que cada rota deve ser uma sequência de um ou mais processadores de eventos que é como um subfluxo. Cada rota, neste caso, criará um evento Mule usando um thread separado. Cada evento do Mule terá sua própria carga útil, atributos e também variáveis.

• Em seguida, este roteador reúne os eventos Mule criados de cada rota e os consolida em um novo evento Mule. Depois disso, ele passa esse evento Mule consolidado para o próximo processador de eventos. Aqui, a condição é que o roteador SG passe um evento Mule consolidado para o próximo processador de evento somente quando todas as rotas forem concluídas com sucesso.

Diagrama Esquemático do Roteador Scatter-Gather

A seguir está o diagrama esquemático de um Roteador Scatter-Gather com quatro processadores de eventos. Ele executa todas as rotas em paralelo e não sequencialmente.

Tratamento de erros por roteador Scatter-Gather

Primeiro, devemos ter conhecimento do tipo de erro que pode ser gerado no componente Scatter-Gather. Qualquer erro pode ser gerado nos processadores de eventos, levando o componente Scatter-Gather a lançar um erro do tipoMule: COMPOSITE_ERROR. Este erro será lançado pelo componente SG somente após cada rota falhar ou ser concluída.

Para lidar com esse tipo de erro, um try scopepode ser usado em cada rota do componente Scatter-Gather. Se o erro for tratado com sucesso portry scope, então a rota será capaz de gerar um evento Mule, com certeza.

Transformadores

Suponha que se quisermos definir ou remover uma parte de qualquer evento Mule, o componente Transformer é a melhor escolha. Os componentes do transformador são dos seguintes tipos -

Remova o transformador variável

Como o nome indica, este componente recebe um nome de variável e remove essa variável do evento Mule.

Configurando a remoção do transformador de variável

A tabela abaixo mostra o nome dos campos e sua descrição a serem considerados durante a configuração do transformador de remoção de variável -

Sr. Não	Campo e Explicação
1	Display Name (doc:name) Podemos personalizar isso para exibir um nome exclusivo para este componente em nosso fluxo de trabalho do Mule.
2	Name (variableName) Ele representa o nome da variável a ser removida.

Definir transformador de carga útil

Com a ajuda de set-payloadcomponente, podemos atualizar a carga útil, que pode ser uma string literal ou expressão DataWeave, da mensagem. Não é recomendado usar este componente para expressões ou transformações complexas. Pode ser usado para simples comoselections.

A tabela abaixo mostra o nome dos campos e sua descrição a serem considerados ao configurar o transformador de carga útil definido -

Campo	Uso	Explicação
Valor (valor)	Obrigatório	O valor arquivado é necessário para definir uma carga útil. Ele aceitará uma string literal ou expressão DataWeave definindo como definir a carga útil. Os exemplos são como “alguma string”
Tipo Mime (mimeType)	Opcional	É opcional, mas representa o tipo MIME do valor atribuído à carga útil da mensagem. Os exemplos são como texto / simples.
Codificação (codificação)	Opcional	Também é opcional, mas representa a codificação do valor atribuído à carga útil da mensagem. Os exemplos são como UTF-8.

Podemos definir uma carga útil por meio do código de configuração XML -

With Static Content - Seguir o código de configuração XML definirá a carga útil usando conteúdo estático -

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

With Expression Content - Seguir o código de configuração XML definirá a carga útil usando o conteúdo de expressão -

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

O exemplo acima anexará a data de hoje com a carga útil da mensagem “Hi”.

Definir transformador de variável

Com a ajuda de set variablecomponente, podemos criar ou atualizar uma variável para armazenar valores que podem ser valores literais simples, como strings, cargas úteis de mensagens ou objetos de atributos, para uso no fluxo do aplicativo Mule. Não é recomendado usar este componente para expressões ou transformações complexas. Pode ser usado para simples comoselections.

Configurando o transformador de variável definida

A tabela abaixo mostra o nome dos campos e sua descrição a serem considerados ao configurar o transformador de carga útil definido -

Campo	Uso	Explicação
Nome da variável (nome da variável)	Obrigatório	É um campo obrigatório e representa o nome da variável. Ao fornecer o nome, siga a convenção de nomenclatura, pois ele deve conter números, caracteres e sublinhados.
Valor (valor)	Obrigatório	O valor arquivado é necessário para definir uma variável. Ele aceitará uma string literal ou expressão DataWeave.
Tipo Mime (mimeType)	Opcional	É opcional, mas representa o tipo MIME da variável. Os exemplos são como texto / simples.
Codificação (codificação)	Opcional	Também é opcional, mas representa a codificação da variável. Os exemplos são como ISO 10646 / Unicode (UTF-8).

Exemplo

O exemplo abaixo definirá a variável para a carga útil da mensagem -

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

Da mesma forma, o exemplo abaixo definirá a variável para a carga útil da mensagem -

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

Serviço da Web REST

A forma completa de REST é Representational State Transfer, que é vinculada ao HTTP. Portanto, se você deseja projetar um aplicativo para ser usado exclusivamente na web, REST é a melhor opção.

Consumindo serviços da Web RESTful

No exemplo a seguir, estaremos usando o componente REST e um serviço público RESTful fornecido pela Mule Soft chamado American Flights details. Tem vários detalhes, mas vamos usar GET:http://training-american-ws.cloudhub.io/api/flightsque retornará todos os detalhes do voo. Conforme discutido anteriormente, REST é vinculado ao HTTP, portanto, precisamos de dois componentes HTTP - um é Listener e outro é Request, para este aplicativo também. A captura de tela abaixo mostra a configuração do ouvinte HTTP -

Configurando e passando argumentos

A configuração para solicitação HTTP é fornecida abaixo -

Agora, de acordo com o fluxo do nosso espaço de trabalho, pegamos o logger para que ele possa ser configurado conforme abaixo -

Na guia de mensagem, escrevemos código para converter a carga útil em strings.

Testando o aplicativo

Agora, salve e execute o aplicativo e vá para o POSTMAN para verificar o resultado final, conforme mostrado abaixo -

Você pode ver que fornece os detalhes do voo usando o componente REST.

Componente SOAP

A forma completa de SOAP é Simple Object Access Protocol. É basicamente uma especificação de protocolo de mensagens para troca de informações na implementação de serviços da web. A seguir, vamos usar a API SOAP no Anypoint Studio para acessar as informações usando serviços da web.

Consumindo serviços da Web baseados em SOAP

Para este exemplo, usaremos o serviço SOAP público cujo nome é Country Info Service, que retém os serviços relacionados às informações do país. Seu endereço WSDL é:http://www.oorsprong.org/websamples.countryinfo/countryinfoservice.wso?WSDL

Primeiro, precisamos arrastar o consumo de SOAP em nossa tela do Mule Palette, conforme mostrado abaixo -

Configurando e transmitindo argumentos

Em seguida, precisamos configurar a solicitação HTTP como feito no exemplo acima, conforme fornecido abaixo -

Agora, também precisamos configurar o Consumidor de serviço da web, conforme mostrado abaixo -

No local do WSDL Location, precisamos fornecer o endereço da web do WSDL, que é fornecido acima (para este exemplo). Depois de fornecer o endereço da web, o Studio pesquisará por serviço, porta e endereço por conta própria. Você não precisa fornecê-lo manualmente.

Resposta de transferência do serviço da web

Para isso, precisamos adicionar um logger no fluxo do Mule e configurá-lo para fornecer a carga útil conforme mostrado abaixo -

Testando o aplicativo

Salve e execute o aplicativo e vá para o Google Chrome para verificar o resultado final. Tipohttp://localhist:8081/helloSOAP (para este exemplo) e mostrará o nome do país por código, conforme mostrado na imagem abaixo -

O novo tratamento de erros do Mule é uma das maiores e principais mudanças feitas no Mule 4. O novo tratamento de erros pode parecer complexo, mas é melhor e mais eficiente. Neste capítulo, vamos discutir sobre os componentes do erro Mule, tipos de erro, categorias de erro Mule e componentes para lidar com erros Mule.

Componentes do erro de mula

O erro de mula é o resultado de uma falha de exceção de mula com os seguintes componentes -

Descrição

É um componente importante do erro Mule que fornecerá a descrição do problema. Sua expressão é a seguinte -

#[error.description]

Tipo

O componente Tipo do erro Mula é usado para caracterizar o problema. Também permite o roteamento dentro de um manipulador de erros. Sua expressão é a seguinte -

#[error.errorType]

Causa

O componente de Causa do erro Mule fornece o java subjacente descartável que causa a falha. Sua expressão é a seguinte -

#[error.cause]

mensagem

O componente Mensagem do erro Mule mostra uma mensagem opcional sobre o erro. Sua expressão é a seguinte -

#[error.errorMessage]

Erros Filhos

O componente Child Errors de Mule error fornece uma coleção opcional de erros internos. Esses erros internos são usados ​​principalmente por elementos como Scatter-Gather para fornecer erros de rota agregados. Sua expressão é a seguinte -

#[error.childErrors]

Exemplo

Em caso de falha de solicitação HTTP com um código de status 401, os Erros Mule são os seguintes -

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." }

Sr. Não	Tipo e descrição do erro
1	TRANSFORMATION Este tipo de erro indica que ocorreu um erro ao transformar um valor. A transformação é a transformação interna do Mule Runtime e não as transformações DataWeave.
2	EXPRESSION Este tipo de tipo de erro indica que ocorreu um erro ao avaliar uma expressão.
3	VALIDATION Este tipo de tipo de erro indica que ocorreu um erro de validação.
4	DUPLICATE_MESSAGE Um tipo de erro de validação que ocorre quando uma mensagem é processada duas vezes.
5	REDELIVERY_EXHAUSTED Esse tipo de tipo de erro ocorre quando o número máximo de tentativas de reprocessar uma mensagem de uma origem foi esgotado.
6	CONNECTIVITY Este tipo de erro indica um problema ao estabelecer uma conexão.
7	ROUTING Este tipo de erro indica que ocorreu um erro ao encaminhar uma mensagem.
8	SECURITY Este tipo de erro indica que ocorreu um erro de segurança. Por exemplo, credenciais inválidas recebidas.
9	STREAM_MAXIMUM_SIZE_EXCEEDED Este tipo de erro ocorre quando o tamanho máximo permitido para um fluxo se esgota.
10	TIMEOUT Indica o tempo limite durante o processamento de uma mensagem.
11	UNKNOWN Este tipo de erro indica que ocorreu um erro inesperado.
12	SOURCE Representa a ocorrência de um erro na origem do fluxo.
13	SOURCE_RESPONSE Ele representa a ocorrência de um erro na origem do fluxo durante o processamento de uma resposta bem-sucedida.

No exemplo acima, você pode ver o componente de mensagem de erro de mula.

Tipos de Erro

Vamos entender os tipos de erro com a ajuda de suas características -

• As primeiras características dos tipos de erro Mule é que ele consiste em ambos, a namespace and an identifier. Isso nos permite distinguir os tipos de acordo com seu domínio. No exemplo acima, o tipo de erro éHTTP: UNAUTHORIZED.

• A segunda e importante característica é que o tipo de erro pode ter um tipo pai. Por exemplo, o tipo de erroHTTP: UNAUTHORIZED tem MULE:CLIENT_SECURITY como pai, que por sua vez também tem um pai chamado MULE:SECURITY. Esta característica estabelece o Tipo de Erro como especificação de item mais global.

Tipos de tipos de erro

A seguir estão as categorias nas quais todos os erros se enquadram -

QUALQUER

Os erros nesta categoria são os erros que podem ocorrer em um Fluxo. Eles não são tão graves e podem ser manuseados facilmente.

CRÍTICO

Os erros nesta categoria são os erros graves que não podem ser tratados. A seguir está a lista de tipos de erro nesta categoria -

Sr. Não	Tipo e descrição do erro
1	OVERLOAD Este tipo de erro indica que ocorreu um erro devido ao problema de sobrecarga. Nesse caso, a execução será rejeitada.
2	FATAL_JVM_ERROR Este tipo de tipo de erro indica a ocorrência de um erro fatal. Por exemplo, estouro de pilha.

Tipo de erro PERSONALIZADO

Os tipos de erro CUSTOM são os erros que são definidos por nós. Eles podem ser definidos ao mapear ou ao levantar os erros. Devemos fornecer um namespace personalizado específico para esses tipos de erro para distingui-los dos outros tipos de erro existentes no aplicativo Mule. Por exemplo, no aplicativo Mule usando HTTP, não podemos usar HTTP como o tipo de erro personalizado.

Categorias de erro de mula

Em sentido amplo, os erros no Mule podem ser divididos em duas categorias, a saber, Messaging Errors and System Errors.

Erro de mensagem

Esta categoria de erro de Mula está relacionada ao fluxo de Mula. Sempre que ocorre um problema dentro de um fluxo Mule, Mule lança um erro de mensagem. Podemos configurarOn Error componente dentro do componente manipulador de erros para lidar com esses erros do Mule.

Erro no sistema

O erro do sistema indica uma exceção ocorrendo no nível do sistema. Se não houver evento Mule, o erro do sistema é tratado por um manipulador de erros do sistema. O seguinte tipo de exceção é tratado por um gerenciador de erros do sistema -

• Exceção que ocorre durante a inicialização do aplicativo.
• Exceção que ocorre quando uma conexão com um sistema externo falha.

No caso de ocorrer um erro de sistema, o Mule envia uma notificação de erro para os ouvintes registrados. Ele também registra o erro. Por outro lado, o Mule executa uma estratégia de reconexão se o erro foi causado por uma falha de conexão.

Tratamento de erros de mula

Mule tem os seguintes dois manipuladores de erro para lidar com os erros -

Manipuladores de erros por erro

O primeiro manipulador de erros Mule é o componente On-Error, que define os tipos de erros que eles podem manipular. Conforme discutido anteriormente, podemos configurar componentes On-Error dentro do componente Error Handler semelhante ao escopo. Cada fluxo Mule contém apenas um manipulador de erro, mas esse manipulador de erro pode conter tantos escopos On-Error quantos forem necessários. As etapas para lidar com o erro Mule dentro do fluxo, com a ajuda do componente On-Error, são as seguintes -

• Primeiro, sempre que um fluxo de Mula gera um erro, a execução do fluxo normal para.

• Em seguida, o processo será transferido para o Error Handler Component que já tem On Error component para corresponder aos tipos e expressões de erro.

• Por fim, o componente Error Handler encaminha o erro para o primeiro On Error scope que corresponde ao erro.

A seguir estão os dois tipos de componentes On-Error suportados pelo Mule -

Propagação em caso de erro

O componente On-Error Propagate executa, mas propaga o erro para o próximo nível e interrompe a execução do proprietário. A transação será revertida se for tratada porOn Error Propagate componente.

Em caso de erro continuar

Como o componente On-Error Propagate, o componente On-Error Continue também executa a transação. A única condição é que, se o proprietário tiver concluído a execução com êxito, este componente usará o resultado da execução como resultado de seu proprietário. A transação será confirmada se for tratada pelo componente On-Error Continue.

Experimente o componente de escopo

Try Scope é uma das muitas novidades disponíveis no Mule 4. Funciona de forma semelhante ao bloco try do JAVA no qual costumávamos encerrar o código tendo a possibilidade de ser uma exceção, para que possa ser tratado sem quebrar todo o código.

Podemos envolver um ou mais processadores de evento Mule em Try Scope e, a partir daí, try scope irá capturar e tratar qualquer exceção lançada por esses processadores de evento. O principal trabalho do escopo try gira em torno de sua própria estratégia de tratamento de erros, que oferece suporte ao tratamento de erros em seu componente interno, em vez de no fluxo inteiro. É por isso que não precisamos extrair o fluxo em um fluxo separado.

Example

A seguir está um exemplo do uso do escopo try -

Configurando o escopo de teste para lidar com transações

Como sabemos, uma transação é uma série de ações que nunca devem ser executadas parcialmente. Todas as operações dentro do escopo de uma transação são executadas no mesmo encadeamento e se ocorrer um erro, ele deve levar a uma reversão ou confirmação. Podemos configurar o escopo try, da seguinte maneira, para que ele trate as operações filho como uma transação.

• INDIFFERENT [Default]- Se escolhermos esta configuração no bloco try, então as ações filho não serão tratadas como uma transação. Neste caso, o erro não causa rollback nem commits.

• ALWAYS_BEGIN - Indica que uma nova transação será iniciada toda vez que o escopo for executado.

• BEGIN_OR_JOIN- Indica que se o processamento atual do fluxo já iniciou uma transação, participe dela. Caso contrário, comece um novo.

No caso de todo projeto, o fato das exceções é que elas estão destinadas a acontecer. É por isso que é importante capturar, categorizar e tratar as exceções para que o sistema / aplicativo não fique em um estado inconsistente. Existe uma estratégia de exceção padrão que é implicitamente aplicada a todos os aplicativos Mule. Reverter qualquer transação pendente automaticamente é a estratégia de exceção padrão.

Exceções em Mule

Antes de nos aprofundarmos no tratamento de exceções, devemos entender que tipo de exceções podem ocorrer junto com três questões básicas que um desenvolvedor deve ter ao projetar manipuladores de exceção.

Qual transporte é importante?

Esta questão tem ampla relevância antes de projetar manipuladores de exceção porque todos os transportes não suportam transnacionalidade.

File ou HTTPnão suporta transações. Por isso, se ocorrer uma exceção nesses casos, devemos gerenciá-la manualmente.

Databasestransações de suporte. Ao projetar manipuladores de exceção neste caso, devemos ter em mente que as transações do banco de dados podem ser revertidas automaticamente (se necessário).

No caso de REST APIs, devemos ter em mente que eles devem retornar os códigos de status HTTP corretos. Por exemplo, 404 para um recurso não encontrado.

Qual padrão de troca de mensagens deve ser usado?

Ao projetar manipuladores de exceção, devemos tomar cuidado com o padrão de troca de mensagens. Pode haver um padrão de mensagem síncrona (solicitação-resposta) ou assíncrona (fogo-esquecer).

Synchronous message pattern é baseado no formato de solicitação-resposta, o que significa que esse padrão esperará uma resposta e será bloqueado até que uma resposta seja retornada ou o tempo limite ocorra.

Asynchronous message pattern é baseado no formato Fire-forget, o que significa que esse padrão assume que as solicitações serão processadas.

Que tipo de exceção é?

A regra muito simples é que você tratará a exceção com base em seu tipo. É muito importante saber se a exceção é causada por um problema de sistema / técnico ou um problema de negócios.

Uma exceção ocorreu por system/technical issue (como queda de rede) deve ser tratada automaticamente por um mecanismo de nova tentativa.

Por outro lado, ocorreu uma exceção by a business issue (como dados inválidos) não deve ser resolvido aplicando o mecanismo de repetição, porque não é útil tentar novamente sem corrigir a causa subjacente.

Por que categorizar exceções?

Como sabemos que todas as exceções não são iguais, é muito importante categorizar as exceções. Em alto nível, as exceções podem ser classificadas nos seguintes dois tipos -

Exceções de negócios

Os principais motivos para a ocorrência de exceções de negócios são dados incorretos ou fluxo de processo incorreto. Esses tipos de exceções são normalmente de natureza irreparável e, portanto, não é bom configurar umrollback. Mesmo aplicandoretrymecanismo não faria nenhum sentido porque não é útil tentar novamente sem corrigir a causa subjacente. Para lidar com essas exceções, o processamento deve parar imediatamente e a exceção enviada de volta como uma resposta a uma fila de devoluções. Uma notificação também deve ser enviada às operações.

Exceções não comerciais

Os principais motivos para a ocorrência de exceções não comerciais são problemas de sistema ou problemas técnicos. Esses tipos de exceções podem ser recuperados por natureza e, portanto, é bom configurar umretry mecanismo para resolver essas exceções.

Estratégias de tratamento de exceções

Mule tem as seguintes cinco estratégias de tratamento de exceção -

Estratégia de exceção padrão

O Mule aplica implicitamente essa estratégia aos fluxos do Mule. Ele pode lidar com todas as exceções em nosso fluxo, mas também pode ser substituído adicionando uma estratégia de exceção catch, Choice ou Rollback. Essa estratégia de exceção reverterá todas as transações pendentes e registrará as exceções também. Uma característica importante dessa estratégia de exceção é que ela também registrará a exceção se não houver transação.

Por ser a estratégia padrão, o Mule implementa isso quando ocorre algum erro no fluxo. Não podemos configurar no AnyPoint Studio.

Estratégia de exceção de reversão

Suponha que se não houver uma solução possível para corrigir o erro, o que fazer? Uma solução é usar a Estratégia de Exceção de Rollback, que reverterá a transação junto com o envio de uma mensagem para o conector de entrada do fluxo pai para reprocessar a mensagem. Essa estratégia também é muito útil quando queremos reprocessar uma mensagem.

Example

Essa estratégia pode ser aplicada a transações bancárias em que os fundos são depositados em uma conta corrente / poupança. Podemos configurar uma estratégia de exceção de rollback aqui porque caso ocorra um erro durante a transação, essa estratégia reverte a mensagem para o início do fluxo para tentar novamente o processamento.

Estratégia de exceção de captura

Essa estratégia captura todas as exceções que são lançadas em seu fluxo pai. Ele substitui a estratégia de exceção padrão do Mule, processando todas as exceções lançadas pelo fluxo pai. Podemos usar uma estratégia de captura de exceções para evitar a propagação de exceções para conectores de entrada e fluxos pai também.

Essa estratégia também garante que uma transação processada pelo fluxo não seja revertida quando ocorrer uma exceção.

Example

Esta estratégia pode ser aplicada ao sistema de reserva de voos em que temos um fluxo de processamento de mensagens de uma fila. Um incrementador de mensagem adiciona uma propriedade à mensagem para atribuição de lugar e, em seguida, envia a mensagem para outra fila.

Agora, se ocorrer algum erro neste fluxo, a mensagem lançará uma exceção. Aqui, nossa estratégia de captura de exceção pode incluir um cabeçalho com uma mensagem apropriada e pode enviar essa mensagem do fluxo para a próxima fila.

Estratégia de exceção de escolha

Caso você queira tratar a exceção com base no conteúdo da mensagem, a estratégia de exceção de escolha seria a melhor escolha. O funcionamento desta estratégia de exceção será o seguinte -

• Primeiro, ele captura todas as exceções lançadas no fluxo pai.
• Em seguida, ele verifica o conteúdo da mensagem e o tipo de exceção.
• E, por fim, ele encaminha a mensagem para a estratégia de exceção apropriada.

Haveria mais de uma estratégia de exceção como Catch ou Rollback, definida na estratégia de exceção de escolha. Caso não haja estratégia definida sob esta estratégia de exceção, então ele irá rotear a mensagem para a estratégia de exceção padrão. Ele nunca executa nenhuma confirmação, reversão ou atividades de consumo.

Estratégia de exceção de referência

Isso se refere a uma estratégia de exceção comum que é definida em um arquivo de configuração separado. No caso de uma mensagem lançar uma exceção, esta estratégia de exceção se referirá aos parâmetros de tratamento de erros definidos em uma estratégia global de captura, reversão ou exceção de escolha. Como a estratégia de exceção de escolha, ele nunca executa nenhuma atividade de confirmação, reversão ou consumo.

Entendemos que o teste de unidade é um método pelo qual unidades individuais de código-fonte podem ser testadas para determinar se são adequadas para uso ou não. Os programadores Java podem usar a estrutura Junit para escrever casos de teste. Da mesma forma, a MuleSoft também possui uma estrutura chamada MUnit, que nos permite escrever casos de teste automatizados para nossas APIs e integrações. É um ajuste perfeito para um ambiente de integração / implantação contínua. Uma das maiores vantagens do framework MUnit é que podemos integrá-lo com Maven e Surefire.

Características do MUnit

A seguir estão alguns dos recursos muito úteis da estrutura de teste Mule MUnit -

• Na estrutura MUnit, podemos criar nosso teste Mule usando o código Mule, bem como código Java.

• Podemos projetar e testar nossos aplicativos Mule e APIs, graficamente ou em XML, no Anypoint Studio.

• O MUnit nos permite integrar facilmente o teste ao processo CI / CD existente.

• Ele fornece testes gerados automaticamente e relatórios de cobertura; portanto, o trabalho manual é mínimo.

• Também podemos usar servidores locais de banco de dados / FTP / correio para tornar os testes mais portáteis por meio do processo de CI.

• Isso nos permite habilitar ou desabilitar os testes.

• Também podemos estender a estrutura MUnit com plug-ins.

• Ele nos permite verificar as chamadas do processador de mensagens.

• Com a ajuda da estrutura de teste MUnit, podemos desabilitar conectores de endpoint, bem como endpoints de entrada de fluxo.

• Podemos verificar relatórios de erros com o rastreamento de pilha do Mule.

Versão mais recente do Mule MUnit Testing Framework

MUnit 2.1.4 é a versão mais recente da estrutura de teste Mule MUnit. Requer os seguintes requisitos de hardware e 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

É compatível com Mule 4.1.4 e Anypoint Studio 7.3.0.

MUnit e Anypoint Studio

Conforme discutido, MUnit é totalmente integrado no Anypoint Studio e podemos projetar e testar nossos aplicativos Mule e APIs graficamente ou em XML dentro do Anypoint Studio. Em outras palavras, podemos usar a interface gráfica do Anypoint Studio para fazer o seguinte -

• Para criar e projetar testes MUnit
• Para executar nossos testes
• Para visualizar os resultados do teste, bem como o relatório de cobertura
• Para depurar os testes

Portanto, vamos começar a discutir cada tarefa, uma por uma.

Criação e projeto de testes MUnit

Depois de iniciar um novo projeto, ele adicionará automaticamente uma nova pasta, a saber src/test/munitao nosso projeto. Por exemplo, começamos um novo projeto Mule, nomeadamentetest_munit, você pode ver na imagem abaixo, adiciona a pasta acima mencionada em nosso projeto.

Agora, depois de iniciar um novo projeto, existem duas maneiras básicas de criar um novo teste MUnit no Anypoint Studio -

• By Right-Clicking the Flow - Neste método, precisamos clicar com o botão direito do mouse no fluxo específico e selecionar MUnit no menu suspenso.

• By Using the Wizard- Neste método, precisamos usar o assistente para criar um teste. Ele nos permite criar um teste para qualquer fluxo na área de trabalho.

Usaremos a forma 'Clique com o botão direito do mouse no fluxo' para criar um teste para um fluxo específico.

Primeiro, precisamos criar um fluxo no espaço de trabalho da seguinte maneira -

Agora, clique com o botão direito neste fluxo e selecione MUnit para criar um teste para este fluxo, conforme mostrado abaixo -

Ele criará um novo conjunto de testes com o nome do arquivo XML em que o fluxo reside. Nesse caso,test_munit-test-suite é o nome do novo conjunto de testes conforme mostrado abaixo -

A seguir está o editor XML para o fluxo de mensagens acima -

Agora, podemos adicionar um MUnit processador de mensagens para o conjunto de testes arrastando-o do Mule Palette.

Se você deseja criar um teste por meio do Assistente, siga File → New → MUnit e isso o levará ao seguinte conjunto de testes MUnit -

Configurando o teste

No Mule 4, temos duas novas seções, a saber MUnit e MUnit Tools, tendo coletivamente todos os processadores de mensagens MUnit. Você pode arrastar qualquer um dos processadores de mensagem em sua área de teste MUnit. É mostrado na imagem abaixo -

Agora, se você deseja editar a configuração do seu traje ou teste no Anypoint Studio, você precisa seguir os passos abaixo -

Step 1

Vou ao Package Explorer e clique com o botão direito no .xml filepara sua suíte ou teste. Em seguida, selecione oProperties.

Step 2

Agora, na janela Propriedades, precisamos clicar Run/Debug Settings. Após este cliqueNew.

Step 3

Na última etapa, clique em MUnit debaixo Select Configuration Type janela e clique em OK.

Executando o Teste

Podemos executar um conjunto de testes, bem como um teste. Primeiro, veremos como executar um conjunto de testes.

Executando um pacote de testes

Para executar um conjunto de testes, clique com o botão direito do mouse na parte vazia do Mule Canvas onde o seu conjunto de testes reside. Isso abrirá um menu suspenso. Agora, clique noRun MUnit suite como mostrado abaixo -

Mais tarde, podemos ver a saída no console.

Executando um Teste

Para executar um teste específico, precisamos selecionar o teste específico e clicar com o botão direito nele. Teremos o mesmo menu suspenso que obtivemos durante a execução do conjunto de testes. Agora, clique noRun MUnit Test opção como mostrado abaixo -

Depois disso, a saída pode ser vista no console.

Ver e analisar o resultado do teste

Anypoint Studio exibe o resultado do teste MUnit no MUnit tabdo painel esquerdo do explorador. Você pode encontrar testes bem-sucedidos na cor verde e os testes reprovados em vermelho, conforme mostrado abaixo -

Podemos analisar o resultado do nosso teste visualizando o relatório de cobertura. O principal recurso do Relatório de Cobertura é fornecer uma métrica de quanto de um aplicativo Mule foi executado com sucesso por um conjunto de testes MUnit. A cobertura do MUnit é basicamente baseada na quantidade de processadores de mensagens MUnit executados. O relatório de cobertura do MUnit fornece métricas para o seguinte -

• Cobertura geral do aplicativo
• Cobertura de recursos
• Cobertura de fluxo

Para obter o relatório de cobertura, precisamos clicar em 'Gerar Relatório' na guia MUnit conforme mostrado abaixo -

Depurando o teste

Podemos depurar um conjunto de testes, bem como um teste. Primeiro, veremos como depurar um conjunto de testes.

Depurando um conjunto de testes

Para depurar um conjunto de testes, clique com o botão direito do mouse na parte vazia do Mule Canvas onde o seu conjunto de testes reside. Isso abrirá um menu suspenso. Agora, clique noDebug MUnit Suite como mostrado na imagem abaixo -

Então, podemos ver a saída no console.

Depurando um Teste

Para depurar um teste específico, precisamos selecionar o teste específico e clicar com o botão direito nele. Obteremos o mesmo menu suspenso que obtivemos durante a suíte de teste de depuração. Agora, clique noDebug MUnit Testopção. Isso é mostrado na captura de tela abaixo.