MuleSoft - Guida rapida

ESB sta per Enterprise Service Busche è fondamentalmente uno strumento middleware per l'integrazione di varie applicazioni insieme su un'infrastruttura simile a un bus. Fondamentalmente, è un'architettura progettata per fornire un mezzo uniforme per spostare il lavoro tra applicazioni integrate. In questo modo, con l'aiuto dell'architettura ESB, possiamo collegare diverse applicazioni tramite un bus di comunicazione e consentire loro di comunicare senza dipendere l'una dall'altra.

Implementazione di ESB

L'obiettivo principale dell'architettura ESB è disaccoppiare i sistemi l'uno dall'altro e consentire loro di comunicare in modo stabile e controllabile. L'implementazione di ESB può essere eseguita con l'aiuto di‘Bus’ e ‘Adapter’ nel modo seguente:

• Il concetto di "bus", che si ottiene tramite un server di messaggistica come JMS o AMQP, viene utilizzato per disaccoppiare diverse applicazioni l'una dall'altra.

• Il concetto di "adattatore", responsabile della comunicazione con l'applicazione di backend e della trasformazione dei dati dal formato dell'applicazione al formato del bus, viene utilizzato tra le applicazioni e il bus.

I dati o il messaggio che passano da un'applicazione all'altra tramite il bus sono in un formato canonico, il che significa che ci sarebbe un formato di messaggio coerente.

L'adattatore può anche eseguire altre attività come sicurezza, monitoraggio, gestione degli errori e gestione del routing dei messaggi.

Principi guida di ESB

Possiamo chiamare questi principi come principi fondamentali di integrazione. Sono i seguenti:

• Orchestration - Integrazione di due o più servizi per ottenere la sincronizzazione tra dati e processo.

• Transformation - Trasformazione dei dati dal formato canonico al formato specifico dell'applicazione.

• Transportation - Gestione della negoziazione del protocollo tra formati come FTP, HTTP, JMS, ecc.

• Mediation - Fornire più interfacce per supportare più versioni di un servizio.

• Non-functional consistency - Fornire meccanismo per la gestione delle transazioni e anche la sicurezza.

Necessità di ESB

L'architettura ESB ci consente di integrare diverse applicazioni in cui ciascuna applicazione può comunicare attraverso di essa. Di seguito sono riportate alcune linee guida su quando utilizzare ESB:

• Integrating two or more applications - L'uso dell'architettura ESB è vantaggioso quando è necessario integrare due o più servizi o applicazioni.

• Integration of more applications in future - Supponiamo di voler aggiungere più servizi o applicazioni in futuro, allora può essere fatto facilmente con l'aiuto dell'architettura ESB.

• Using multiple protocols - Nel caso in cui dovessimo utilizzare più protocolli come HTTP, FTP, JMS ecc., ESB è l'opzione giusta.

• Message routing - Possiamo utilizzare ESB nel caso in cui richiediamo il routing dei messaggi in base al contenuto del messaggio e ad altri parametri simili.

• Composition and consumption - ESB può essere utilizzato se abbiamo bisogno di pubblicare servizi per la composizione e il consumo.

Integrazione P2P vs. integrazione ESB

Con l'aumento del numero di applicazioni, una grande domanda davanti agli sviluppatori era come collegare le diverse applicazioni? La situazione è stata gestita codificando manualmente una connessione tra varie applicazioni. Questo è chiamatopoint-to-point integration.

Rigidityè l'inconveniente più ovvio dell'integrazione punto a punto. La complessità aumenta con l'aumentare del numero di connessioni e interfacce. Gli svantaggi dell'integrazione P-2-P ci portano all'integrazione ESB.

ESB è un approccio più flessibile all'integrazione delle applicazioni. Incapsula ed espone ogni funzionalità dell'applicazione come un insieme di capacità riutilizzabili discrete. Nessuna applicazione si integra direttamente con altre, invece si integrano tramite un ESB come mostrato di seguito -

Per la gestione dell'integrazione, ESB ha i seguenti due componenti:

• Service Registry- Mule ESB dispone di registro / repository dei servizi in cui vengono pubblicati e registrati tutti i servizi esposti nell'ESB. Agisce come un punto di scoperta da cui è possibile utilizzare i servizi e le capacità di altre applicazioni.

• Centralized Administration - Come suggerisce il nome, fornisce una visione dei flussi transazionali delle prestazioni delle interazioni che si verificano all'interno dell'ESB.

ESB Functionality- L'abbreviazione VETRO viene generalmente utilizzata per riassumere la funzionalità di ESB. È il seguente:

• V(Convalida) - Come suggerisce il nome, convalida la convalida dello schema. Richiede un parser di convalida e uno schema aggiornato. Un esempio è un documento XML che conferma uno schema aggiornato.

• E(Arricchisci) - Aggiunge dati aggiuntivi a un messaggio. Lo scopo è rendere il messaggio più significativo e utile per un servizio di destinazione.

• T(Trasforma) - Converte la struttura dei dati in un formato canonico o da un formato canonico. Esempi sono la conversione di data / ora, valuta, ecc.

• R(Routing): instraderà il messaggio e fungerà da gatekeeper dell'endpoint di un servizio.

• O(Operate): il compito principale di questa funzione è richiamare il servizio di destinazione o interagire con l'app di destinazione. Corrono nel backend.

Il modello VETRO fornisce una flessibilità complessiva all'integrazione e garantisce che solo i dati coerenti e convalidati vengano instradati in tutto l'ESB.

Cos'è Mule ESB?

Mule ESB è un bus di servizi aziendali (ESB) basato su Java leggero e altamente scalabile e una piattaforma di integrazione fornita da MuleSoft. Mule ESB consente allo sviluppatore di connettere le applicazioni facilmente e rapidamente. Indipendentemente dalle varie tecnologie utilizzate dalle applicazioni, Mule ESB consente una facile integrazione delle applicazioni, consentendo loro di scambiare dati. Mule ESB ha le seguenti due edizioni:

• Edizione comunitaria
• Enterprise Edition

Un vantaggio di Mule ESB è che possiamo facilmente passare dalla community Mule ESB all'azienda Mule ESB perché entrambe le edizioni sono costruite su una base di codice comune.

Caratteristiche e capacità di Mule ESB

Le seguenti caratteristiche sono possedute da Mule ESB:

• Ha un semplice design grafico drag-and-drop.
• Mule ESB è in grado di mappare e trasformare visivamente i dati.
• L'utente può ottenere la struttura di centinaia di connettori certificati pre-costruiti.
• Monitoraggio e amministrazione centralizzati.
• Fornisce solide capacità di applicazione della sicurezza aziendale.
• Fornisce la funzione di gestione delle API.
• È disponibile un gateway dati sicuro per la connettività cloud / on-premise.
• Fornisce il registro dei servizi in cui vengono pubblicati e registrati tutti i servizi esposti nell'ESB.
• Gli utenti possono avere il controllo tramite una console di gestione basata sul web.
• Il debug rapido può essere eseguito utilizzando l'analizzatore del flusso di servizio.

Le motivazioni alla base del progetto Mule erano:

• per rendere le cose più semplici per i programmatori,

• la necessità di una soluzione leggera e modulare in grado di scalare da un framework di messaggistica a livello di applicazione a un framework altamente distribuibile a livello aziendale.

Mule ESB è progettato come framework basato su eventi e programmatico. È guidato dagli eventi perché è combinato con una rappresentazione unificata dei messaggi e può essere espandibile con moduli collegabili. È programmatico perché i programmatori possono facilmente impiantare alcuni comportamenti aggiuntivi come l'elaborazione di messaggi specifici o la trasformazione personalizzata dei dati.

Storia

La prospettiva storica del progetto Mule è la seguente:

Progetto SourceForge

Il progetto Mule è stato avviato come progetto SourceForge nell'aprile 2003, e dopo 2 anni la sua prima versione è stata rilasciata e spostata in CodeHaus. L'API UMO (Universal Message Object) era il fulcro della sua architettura. L'idea alla base dell'API UMO era di unificare la logica mantenendola isolata dai trasporti sottostanti.

Versione 1.0.0

È stato rilasciato nell'aprile 2005 contenente numerosi trasporti. L'obiettivo principale di molte altre versioni seguite da esso era il debug e l'aggiunta di nuove funzionalità.

Versione 2.0 (adozione della primavera 2)

La Spring 2 come struttura di configurazione e cablaggio è stata adottata in Mule 2 ma si è rivelata una grande revisione a causa della mancanza di espressività della configurazione XML richiesta. Questo problema è stato risolto quando la configurazione basata su XML Schema è stata introdotta nella primavera 2.

Costruire con Maven

Il più grande miglioramento che ha semplificato l'utilizzo di Mule, sia in fase di sviluppo che di distribuzione, è stato l'uso di Maven. Dalla versione 1.3, ha iniziato a essere costruito con Maven.

MuleSource

Nel 2006, MuleSource è stata incorporata "per aiutare a supportare e abilitare la comunità in rapida crescita che utilizza Mule in applicazioni aziendali mission-critical". Si è rivelata la pietra miliare chiave per Mule Project.

Concorrenti di Mule ESB

Di seguito sono riportati alcuni dei principali concorrenti di Mule ESB:

• WSO2 ESB
• Oracle Service Bus
• WebSphere Message Broker
• Piattaforma Aurea CX
• Fiorano ESB
• WebSphere DataPower Gateway
• Framework dei processi aziendali di Workday
• Talend Enterprise Service Bus
• JBoss Enterprise Service Bus
• iWay Service Manager

Il concetto di base di Mule

Come discusso, Mule ESB è un bus di servizi aziendali (ESB) basato su Java e una piattaforma di integrazione leggera e altamente scalabile. Indipendentemente dalle varie tecnologie utilizzate dalle applicazioni, Mule ESB consente una facile integrazione delle applicazioni, consentendo loro di scambiare dati. In questa sezione, discuteremo del concetto fondamentale di Mule che entra in gioco per realizzare tale integrazione.

Per questo, abbiamo bisogno di capire la sua architettura e gli elementi costitutivi.

Architettura

L'architettura di Mule ESB ha tre livelli, ovvero livello di trasporto, livello di integrazione e livello di applicazione, come mostrato nel diagramma seguente:

In generale, ci sono i seguenti tre tipi di attività che possono essere eseguite per configurare e personalizzare la distribuzione di Mule:

Sviluppo di componenti di servizio

Questa attività implica lo sviluppo o il riutilizzo dei POJO esistenti, o Spring Beans. POJOs è una classe con attributi che genera i metodi get e set, connettori cloud. D'altra parte, Spring Beans contiene la logica di business per arricchire i messaggi.

Orchestrazione dei servizi

Questa attività fornisce fondamentalmente la mediazione del servizio che implica la configurazione del processore di messaggi, router, trasformatori e filtri.

Integrazione

Il compito più importante di Mule ESB è l'integrazione di varie applicazioni indipendentemente dai protocolli che stanno utilizzando. A tale scopo, Mule fornisce metodi di trasporto che consentono di ricevere e inviare i messaggi su vari connettori di protocollo. Mule supporta molti metodi di trasporto esistenti, oppure possiamo anche utilizzare un metodo di trasporto personalizzato.

Costruzioni

La configurazione di Mule ha i seguenti elementi costitutivi:

Fagioli primaverili

L'utilizzo principale dei bean Spring è la creazione di componenti di servizio. Dopo aver costruito il componente del servizio primaverile, possiamo definirlo tramite un file di configurazione o manualmente, nel caso non abbiate un file di configurazione.

Agenti

È fondamentalmente un servizio creato in Anypoint Studio prima di Mule Studio. Un agente viene creato una volta avviato un server e verrà distrutto una volta arrestato il server.

Connettore

È un componente software configurato con i parametri specifici dei protocolli. Viene utilizzato principalmente per controllare l'utilizzo di un protocollo. Ad esempio, un connettore JMS è configurato con un fileConnection e questo connettore sarà condiviso tra i vari soggetti incaricati della comunicazione effettiva.

Configurazione globale

Come suggerisce il nome, questo blocco predefinito viene utilizzato per impostare le proprietà e le impostazioni globali.

Endpoint globali

Può essere utilizzato nella scheda Elementi globali che può essere utilizzata tante volte in un flusso -

Elaboratore di messaggi globale

Come suggerisce il nome, osserva o modifica un messaggio o un flusso di messaggi. Transformers e filtri sono gli esempi di Global Message Processor.

Transformers- Il compito principale di un trasformatore è convertire i dati da un formato all'altro. Può essere definito globalmente e può essere utilizzato in più flussi.

Filters- È il filtro che deciderà quale messaggio Mule deve essere elaborato. Il filtro specifica fondamentalmente le condizioni che devono essere soddisfatte affinché un messaggio venga elaborato e instradato a un servizio.

Modelli

A differenza degli agenti, è un raggruppamento logico di servizi che vengono creati in studio. Abbiamo la libertà di avviare e interrompere tutti i servizi all'interno di un modello specifico.

Services- I servizi sono quelli che avvolgono la nostra logica o i nostri componenti aziendali. Inoltre configura router, endpoint, trasformatori e filtri specificamente per quel servizio.

Endpoints- Può essere definito come un oggetto su cui i servizi invieranno messaggi in entrata (riceveranno) e in uscita (invieranno). I servizi sono connessi tramite endpoint.

Flusso

L'elaboratore di messaggi utilizza i flussi per definire un flusso di messaggi tra un'origine e una destinazione.

Struttura del messaggio del mulo

Un messaggio Mule, completamente racchiuso in Mule Message Object, è il dato che passa attraverso le applicazioni tramite i flussi Mule. Il messaggio della struttura Mule è mostrato nello schema seguente:

Come si vede nel diagramma sopra, Mule Message è composto da due parti principali:

Intestazione

Non è altro che i metadati del messaggio che sono ulteriormente rappresentati dalle seguenti due proprietà:

Inbound Properties- Queste sono le proprietà che vengono impostate automaticamente dall'origine del messaggio. Non possono essere manipolati o impostati dall'utente. In natura, le proprietà in entrata sono immutabili.

Outbound Properties- Queste sono le proprietà che contengono metadati come una proprietà in entrata e possono essere impostate durante il corso del flusso. Possono essere impostati automaticamente da Mule o manualmente da un utente. In natura, le proprietà in uscita sono mutabili.

Le proprietà in uscita diventano proprietà in entrata quando il messaggio passa dall'endpoint in uscita di un flusso all'endpoint in entrata di un flusso diverso tramite un trasporto.

Le proprietà in uscita rimangono proprietà in uscita quando il messaggio viene passato a un nuovo flusso tramite un flusso di riferimento anziché un connettore.

Carico utile

Il messaggio commerciale effettivo trasportato dall'oggetto messaggio è chiamato payload.

Variabili

Può essere definito come metadati definiti dall'utente su un messaggio. Fondamentalmente, le variabili sono informazioni temporanee su un messaggio utilizzato dall'applicazione che lo sta elaborando. Non è pensato per essere passato insieme ai messaggi alla sua destinazione. Sono di tre tipi come indicato di seguito:

Flow variables - Queste variabili si applicano solo al flusso in cui esistono.

Session variables - Queste variabili si applicano a tutti i flussi all'interno della stessa applicazione.

Record variables - Queste variabili si applicano solo ai record elaborati come parte di un batch.

Allegati e carico utile extra

Questi sono alcuni metadati extra sul payload del messaggio che non sono necessariamente visualizzati ogni volta nell'oggetto messaggio.

Nei capitoli precedenti, abbiamo imparato le basi di Mule ESB. In questo capitolo impariamo come installarlo e configurarlo.

Prerequisiti

Dobbiamo soddisfare i seguenti prerequisiti prima di installare Mule sul nostro computer:

Java Development Kit (JDK)

Prima di installare MULE, verifica di avere la versione supportata di Java sul tuo sistema. Si consiglia JDK 1.8.0 per installare con successo Mule sul proprio sistema.

Sistema operativo

I seguenti sistemi operativi sono supportati da Mule:

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

Banca dati

Un server delle applicazioni o un database non è richiesto poiché Mule Runtime viene eseguito come server autonomo. Ma se è necessario accedere a un archivio dati o si desidera utilizzare un server delle applicazioni, è possibile utilizzare i seguenti server o database delle applicazioni supportati:

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

Requisiti di sistema

Prima di installare Mule sul tuo sistema, deve soddisfare i seguenti requisiti di sistema:

• Almeno 2 GHz CPU o 1 CPU virtuale in ambienti virtualizzati
• Almeno 1 GB di RAM
• Spazio di archiviazione minimo di 4 GB

Scarica Mule

Per scaricare il file binario di Mule 4, fare clic sul collegamento https://www.mulesoft.com/lp/dl/mule-esb-enterprise e ti porterà alla pagina web ufficiale di MuleSoft come segue -

Fornendo i dettagli necessari, è possibile ottenere il file binario Mule 4 in formato Zip.

Installa ed esegui Mule

Ora dopo aver scaricato il file binario di Mule 4, decomprimilo e imposta una variabile d'ambiente chiamata MULE_HOME per la directory Mule all'interno della cartella estratta.

Ad esempio, la variabile di ambiente, su ambienti Windows e Linux / Unix, può essere impostata per la versione 4.1.5 nella directory Download come segue:

Ambienti Windows

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

Ambienti Unix / Linux

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

Ora, per verificare se Mule è in esecuzione nel tuo sistema senza errori, usa i seguenti comandi:

Ambienti Windows

$ $MULE_HOME\bin\mule.bat

Ambienti Unix / Linux

$ $MULE_HOME/bin/mule

I comandi precedenti eseguiranno Mule in modalità in primo piano. Se Mule è in esecuzione, non possiamo emettere altri comandi sul terminale. Premendoctrl-c comando nel terminale, fermerà Mule.

Avvia Mule Services

Possiamo avviare Mule come servizio Windows e anche come Daemon Linux / Unix.

Mule come servizio Windows

Per eseguire Mule come servizio Windows, dobbiamo seguire i passaggi seguenti:

Step 1 - Innanzitutto, installalo con l'aiuto del seguente comando -

$ $MULE_HOME\bin\mule.bat install

Step 2 - Una volta installato, possiamo eseguire mule come servizio Windows con l'aiuto del seguente comando:

$ $MULE_HOME\bin\mule.bat start

Mule come demone Linux / Unix

Per eseguire Mule come daemon Linux / Unix, dobbiamo seguire i passaggi seguenti:

Step 1 - Installalo con l'aiuto del seguente comando -

$ $MULE_HOME/bin/mule install

Step 2 - Una volta installato, possiamo eseguire mule come servizio Windows con l'aiuto del seguente comando -

$ $MULE_HOME/bin/mule start

Example

Il seguente esempio avvia Mule come 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

Distribuisci le app Mule

Possiamo distribuire le nostre app Mule con l'aiuto dei seguenti passaggi:

Step 1 - Per prima cosa, avvia Mule.

Step 2 - Una volta avviato Mule, possiamo distribuire le nostre applicazioni Mule spostando i file del pacchetto JAR nel file apps directory in $MULE_HOME.

Stop Mule Services

Possiamo usare stopcomando di fermare Mule. Ad esempio, il seguente esempio avvia Mule come 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.

Possiamo anche usare removecomando per rimuovere il servizio Mule o il demone dal nostro sistema. Il seguente esempio rimuove Mule come 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 di MuleSoft è facile da usare IDE (integration development environment)utilizzato per progettare e testare le applicazioni Mule. È un IDE basato su Eclipse. Possiamo facilmente trascinare i connettori dalla tavolozza Mule. In altre parole, Anypoint Studio è un IDE basato su Eclipse per lo sviluppo di flussi, ecc.

Prerequisiti

Dobbiamo soddisfare i seguenti prerequisiti prima di installare Mule su tutti i sistemi operativi, ovvero Windows, Mac e Linux / Unix.

Java Development Kit (JDK)- Prima di installare Mule, verifica di avere la versione supportata di Java sul tuo sistema. Si consiglia JDK 1.8.0 per installare correttamente Anypoint sul sistema.

Download e installazione di Anypoint Studio

La procedura per scaricare e installare Anypoint Studio su diversi sistemi operativi può variare. Successivamente, ci sono i passaggi da seguire per scaricare e installare Anypoint Studio su vari sistemi operativi -

Su Windows

Per scaricare e installare Anypoint Studio su Windows, è necessario seguire i passaggi seguenti:

Step 1 - Innanzitutto, fare clic sul collegamento https://www.mulesoft.com/lp/dl/studio e scegli il sistema operativo Windows dall'elenco a discesa per scaricare lo studio.

Step 2 - Ora, estrailo nel file ‘C:\’ cartella root.

Step 3 - Apri Anypoint Studio estratto.

Step 4- Per accettare lo spazio di lavoro predefinito, fare clic su OK. Riceverai un messaggio di benvenuto quando verrà caricato per la prima volta.

Step 5 - Ora, fai clic sul pulsante Inizia per utilizzare Anypoint Studio.

Su OS X

Per scaricare e installare Anypoint Studio su OS X, dobbiamo seguire i passaggi seguenti:

Step 1 - Innanzitutto, fare clic sul collegamento https://www.mulesoft.com/lp/dl/studio e scarica lo studio.

Step 2- Ora estrailo. Se stai utilizzando la versione del sistema operativo Sierra, assicurati di spostare l'app estratta in/Applications folder prima di avviarlo.

Step 3 - Apri Anypoint Studio estratto.

Step 4- Per accettare lo spazio di lavoro predefinito, fare clic su OK. Riceverai un messaggio di benvenuto quando verrà caricato per la prima volta.

Step 5 - Ora fai clic su Get Started pulsante per utilizzare Anypoint Studio.

Se intendi utilizzare un percorso personalizzato per il tuo spazio di lavoro, tieni presente che Anypoint Studio non espande la ~ tilde utilizzata nei sistemi Linux / Unix. Pertanto, si consiglia di utilizzare il percorso assoluto durante la definizione dell'area di lavoro.

Su Linux

Per scaricare e installare Anypoint Studio su Linux, dobbiamo seguire i passaggi seguenti:

Step 1 - Innanzitutto, fare clic sul collegamento https://www.mulesoft.com/lp/dl/studio e scegli il sistema operativo Linux dall'elenco a discesa per scaricare lo studio.

Step 2 - Ora estrailo.

Step 3 - Quindi, apri Anypoint Studio estratto.

Step 4- Per accettare lo spazio di lavoro predefinito, fare clic su OK. Riceverai un messaggio di benvenuto quando verrà caricato per la prima volta.

Step 5 - Ora, fai clic sul pulsante Inizia per utilizzare Anypoint Studio.

Se intendi utilizzare un percorso personalizzato per il tuo spazio di lavoro, tieni presente che Anypoint Studio non espande la ~ tilde utilizzata nei sistemi Linux / Unix. Pertanto, si consiglia di utilizzare il percorso assoluto durante la definizione dell'area di lavoro.

Si consiglia inoltre di installare GTK versione 2 per utilizzare i temi Studio completi in Linux.

Caratteristiche di Anypoint Studio

Di seguito sono riportate alcune funzionalità di Anypoint studio che migliorano la produttività durante la creazione di applicazioni Mule:

• Fornisce un'esecuzione istantanea dell'applicazione Mule all'interno di un runtime locale.

• Anypoint studio ci offre un editor visuale per la configurazione dei file di definizione API e dei domini Mule.

• Ha un framework di unit test integrato che migliora la produttività.

• Anypoint studio ci fornisce il supporto integrato per la distribuzione su CloudHub.

• Ha la possibilità di integrarsi con Exchange per l'importazione di modelli, esempi, definizioni e altre risorse da altre organizzazioni Anypoint Platform.

Gli editor di Anypoint Studio ci aiutano a progettare le nostre applicazioni, API, proprietà e file di configurazione. Insieme alla progettazione, ci aiuta anche a modificarli. Abbiamo l'editor dei file di configurazione di Mule per questo scopo. Per aprire questo editor, fare doppio clic sul file XML dell'applicazione in/src/main/mule.

Per lavorare con la nostra applicazione, abbiamo le seguenti tre schede nell'editor del file di configurazione di Mule.

La scheda Flusso di messaggi

Questa scheda offre una rappresentazione visiva del flusso di lavoro. Fondamentalmente contiene una tela che ci aiuta a controllare visivamente i nostri flussi. Se desideri aggiungere processori di eventi dalla tavolozza Mule alla tela, trascina e rilascia e si rifletterà nella tela.

Facendo clic su un processore di eventi, è possibile ottenere la vista delle proprietà del mulo con gli attributi per il processore selezionato. Possiamo anche modificarli.

La scheda Elementi globali

Questa scheda contiene gli elementi di configurazione globale di Mule per i moduli. In questa scheda possiamo creare, modificare o eliminare i file di configurazione.

La scheda Configurazione XML

Come suggerisce il nome, contiene l'XML che definisce la tua applicazione Mule. Tutte le modifiche apportate qui si rifletteranno nell'area di disegno e nella visualizzazione delle proprietà del processore di eventi nella scheda Flusso di messaggi.

Visualizzazioni

Per l'editor attivo, Anypoint studio ci fornisce la rappresentazione grafica dei metadati del nostro progetto, le proprietà con l'aiuto delle viste. Un utente può spostare, chiudere e aggiungere visualizzazioni nel progetto Mule. Di seguito sono riportate alcune visualizzazioni predefinite in Anypoint studio:

Esplora pacchetti

Il compito principale della vista Esplora pacchetti è visualizzare le cartelle ei file del progetto costituiti da un progetto Mule. Possiamo espandere o contrarre la cartella del progetto Mule facendo clic sulla freccia accanto ad essa. È possibile aprire una cartella o un file facendo doppio clic su di esso. Dai un'occhiata al suo screenshot -

Tavolozza Mule

La visualizzazione Mule Palette mostra i processori di eventi come ambiti, filtri e router di controllo del flusso insieme ai moduli e alle operazioni correlate. I compiti principali della vista Palette Mule sono i seguenti:

• Questa visualizzazione ci aiuta a gestire i moduli e connettori nel nostro progetto.
• Possiamo anche aggiungere nuovi elementi da Exchange.

Dai un'occhiata al suo screenshot -

Proprietà del mulo

Come suggerisce il nome, ci permette di modificare le proprietà del modulo attualmente selezionato nella nostra tela. La visualizzazione delle proprietà del mulo include quanto segue:

• DataSense Explorer che fornisce informazioni in tempo reale sulla struttura dei dati del nostro payload.

• Proprietà in entrata e in uscita, se disponibili o variabili.

Di seguito è riportato lo screenshot:

Console

Ogni volta che creiamo o eseguiamo l'applicazione Mule, il server Mule incorporato visualizza un elenco di eventi e problemi, se presenti, segnalati da Studio. La vista console contiene la console di quel server Mule incorporato. Dai un'occhiata al suo screenshot -

Visualizzazione dei problemi

Possiamo incontrare molti problemi mentre lavoriamo al nostro progetto Mule. Tutti questi problemi vengono visualizzati nella vista Problemi. Di seguito è riportato lo screenshot

Prospettive

In Anypoint Studio, è una raccolta di visualizzazioni ed editor in una disposizione specificata. Esistono due tipi di prospettive in Anypoint Studio:

Mule Design Perspective - È la prospettiva predefinita che otteniamo in Studio.

Mule Debug Perspective - Un'altra prospettiva fornita da Anypoint Studio è Mule Debug Perspective.

D'altra parte, possiamo anche creare la nostra prospettiva e aggiungere o rimuovere qualsiasi visualizzazione predefinita.

In questo capitolo creeremo la nostra prima applicazione Mule in Anypoint Studio di MuleSoft. Per crearlo, prima dobbiamo avviare Anypoint Studio.

Avvio di Anypoint Studio

Fare clic su Anypoint Studio per avviarlo. Se lo lanci per la prima volta, vedrai la seguente finestra:

Interfaccia utente di Anypoint Studio

Dopo aver fatto clic sul pulsante Vai all'area di lavoro, ti condurrà all'interfaccia utente di Anypoint Studio come segue:

Passaggi per la creazione dell'applicazione Mule

Per creare la tua applicazione Mule, segui i passaggi seguenti:

Creazione di un nuovo progetto

Il primo passo per creare l'applicazione Mule è creare un nuovo progetto. Può essere fatto seguendo il percorsoFILE → NEW → Mule Project come mostrato di seguito -

Denominazione del progetto

Dopo aver cliccato sul nuovo Progetto Mule, come descritto sopra, si aprirà una nuova finestra chiedendo il nome del progetto e altre specifiche. Dai il nome del progetto, "TestAPP1'e quindi fare clic sul pulsante Fine.

Dopo aver fatto clic sul pulsante Fine, si aprirà l'area di lavoro creata per il tuo MuleProject, ovvero ‘TestAPP1’. Puoi vedere tutti i fileEditors e Views descritto nel capitolo precedente.

Configurazione del connettore

Qui creeremo una semplice applicazione Mule per HTTP Listener. Per questo, dobbiamo trascinare il connettore Listener HTTP da Mule Palette e rilasciarlo nell'area di lavoro come mostrato di seguito -

Ora dobbiamo configurarlo. Fare clic sul segno + di colore verde dopo la configurazione del connettore in Impostazioni di base come mostrato sopra.

Facendo clic su ok, tornerai alla pagina delle proprietà del listener HTTP. Ora dobbiamo fornire il percorso nella scheda Generale. In questo particolare esempio, abbiamo fornito/FirstAPP come nome del percorso.

Configurazione di Set Payload Connector

Ora, dobbiamo prendere un connettore Set Payload. Dobbiamo anche dare il suo valore nella scheda Impostazioni come segue:

This is my first Mule Application, è il nome fornito in questo esempio.

Esecuzione dell'applicazione Mule

Ora salvalo e fai clic Run as Mule Application come mostrato di seguito -

Possiamo controllarlo in Console che distribuisce l'applicazione come segue:

Mostra che hai creato con successo la tua prima applicazione Mule.

Verifica dell'applicazione Mule

Ora, dobbiamo verificare se la nostra app è in esecuzione o meno. Go to POSTMAN, un'app Chrome e inserisci l'URL: http:/localhost:8081. Mostra il messaggio che abbiamo fornito durante la creazione dell'applicazione Mule come mostrato di seguito:

DataWeave è fondamentalmente un linguaggio di espressione MuleSoft. Viene utilizzato principalmente per accedere e trasformare i dati ricevuti tramite un'applicazione Mule. Il runtime di Mule è responsabile dell'esecuzione dello script e delle espressioni nella nostra applicazione Mule, DataWeave è fortemente integrato con il runtime di Mule.

Caratteristiche di DataWeave Language

Di seguito sono riportate alcune importanti caratteristiche del linguaggio DataWeave:

I dati possono essere trasformati da un formato all'altro molto facilmente. Ad esempio, possiamo trasformare application / json in application / xml. Il carico utile in ingresso è il seguente:

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

Di seguito è riportato il codice in DataWeave per la trasformazione:

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

Successivamente, il output il carico utile è il seguente:

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

Il componente di trasformazione può essere utilizzato per creare script che eseguono trasformazioni di dati sia semplici che complesse.

Possiamo accedere e utilizzare le funzioni principali di DataWeave su parti dell'evento Mule di cui abbiamo bisogno poiché la maggior parte dei processori di messaggi Mule supporta le espressioni DataWeave.

Prerequisiti

Dobbiamo soddisfare i seguenti prerequisiti prima di utilizzare gli script DataWeave sul nostro computer:

• Anypoint Studio 7 è necessario per utilizzare gli script Dataweave.

• Dopo aver installato Anypoint Studio, è necessario impostare un progetto con un componente Transform Message per poter utilizzare gli script DataWeave.

Passaggi per l'utilizzo di DataWeave Script con Example

Per utilizzare lo script DataWeave, dobbiamo seguire i passaggi seguenti:

Step 1

Per prima cosa, dobbiamo impostare un nuovo progetto, come abbiamo fatto nel capitolo precedente, utilizzando File → New → Mule Project.

Step 2

Successivamente, dobbiamo fornire il nome del progetto. Per questo esempio, stiamo dando il nome,Mule_test_script.

Step 3

Ora, dobbiamo trascinare il file Transform Message component a partire dal Mule Palette tab in canvas. È mostrato come di seguito -

Step 4

Successivamente, in Transform Message componentscheda, fare clic su Anteprima per aprire il riquadro Anteprima. Possiamo espandere l'area del codice sorgente facendo clic sul rettangolo vuoto accanto a Anteprima.

Step 5

Ora possiamo iniziare a creare script con il linguaggio DataWeave.

Esempio

Di seguito è riportato il semplice esempio di concatenare due stringhe in una:

Lo script DataWeave sopra ha una coppia chiave-valore ({ myString: ("hello" ++ "World") }) che concatenerà due stringhe in una.

I moduli di scripting facilitano agli utenti l'utilizzo del linguaggio di scripting in Mule. In parole semplici, il modulo di scripting può scambiare logica personalizzata scritta in linguaggio di scripting. Gli script possono essere utilizzati come implementazioni o trasformatori. Possono essere usati per la valutazione delle espressioni, cioè per controllare l'instradamento dei messaggi.

Mule ha i seguenti linguaggi di scripting supportati:

• Groovy
• Python
• JavaScript
• Ruby

Come installare i moduli di scripting?

In realtà, Anypoint Studio viene fornito con i moduli di scripting. Se non trovi il modulo in Mule Palette, puoi aggiungerlo usando+Add Module. Dopo l'aggiunta, possiamo utilizzare le operazioni del modulo di scripting nella nostra applicazione Mule.

Esempio di implementazione

Come discusso, dobbiamo trascinare e rilasciare il modulo nell'area di disegno per creare lo spazio di lavoro e utilizzarlo nella nostra applicazione. Di seguito è riportato un esempio:

Sappiamo già come configurare il componente Listener HTTP; quindi discuteremo della configurazione dei moduli di scripting. Dobbiamo seguire i passaggi scritti di seguito per configurare il modulo di scripting -

Step 1

Cerca il modulo Scripting da Mule Palette e trascina il file EXECUTE funzionamento del modulo di scripting nel flusso come mostrato sopra.

Step 2

Ora, apri la scheda Esegui configurazione facendo doppio clic sulla stessa.

Step 3

Sotto il General scheda, dobbiamo fornire il codice nel file Code text window come mostrato di seguito -

Step 4

Infine, dobbiamo scegliere il file Enginedal componente di esecuzione. L'elenco dei motori è il seguente:

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

L'XML dell'esempio di esecuzione precedente nell'editor XML di configurazione è il seguente:

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

Origini dei messaggi

Mule 4 ha un modello semplificato rispetto al messaggio Mule 3 che semplifica il lavoro con i dati in modo coerente tra i connettori senza sovrascrivere le informazioni. Nel modello di messaggio Mule 4, ogni evento Mule consiste di due cose:a message and variables associated with it.

Un messaggio di Mule ha un payload e i suoi attributi, dove l'attributo è principalmente metadati come la dimensione del file.

E una variabile contiene le informazioni utente arbitrarie come il risultato dell'operazione, i valori ausiliari, ecc.

In entrata

Le proprietà in entrata in Mule 3 ora diventano Attributi in Mule 4. Come sappiamo che le proprietà in entrata memorizzano informazioni aggiuntive sul payload ottenuto tramite un'origine del messaggio, ma questo ora, in Mule 4, è fatto con l'aiuto degli attributi. Gli attributi hanno i seguenti vantaggi:

• Con l'aiuto degli attributi, possiamo facilmente vedere quali dati sono disponibili, perché gli attributi sono fortemente tipizzati.

• Possiamo accedere facilmente alle informazioni contenute negli attributi.

Di seguito è riportato l'esempio di un messaggio tipico in Mule 4:

In uscita

Le proprietà in uscita in Mule 3 devono essere specificate esplicitamente dai connettori e dai trasporti Mule per poter inviare dati aggiuntivi. Ma in Mule 4, ognuno di questi può essere impostato separatamente, utilizzando un'espressione DataWeave per ciascuno di essi. Non produce alcun effetto collaterale nel flusso principale.

Ad esempio, l'espressione DataWeave di seguito eseguirà una richiesta HTTP e genererà intestazioni e parametri di query senza la necessità di impostare le proprietà del messaggio. Questo è mostrato nel codice sottostante -

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

Elaboratore di messaggi

Quando Mule riceve un messaggio da un'origine del messaggio, inizia il lavoro dell'elaboratore di messaggi. Il Mule utilizza uno o più processori di messaggi per elaborare il messaggio attraverso un flusso. Il compito principale dell'elaboratore di messaggi è trasformare, filtrare, arricchire ed elaborare il messaggio mentre passa attraverso il flusso Mule.

Classificazione di Mule Processor

Di seguito sono riportate le categorie di Mule Processor, in base alle funzioni:

• Connectors- Questi processori di messaggi inviano e ricevono dati. Inoltre collegano i dati a origini dati esterne tramite protocolli standard o API di terze parti.

• Components - Questi processori di messaggi sono di natura flessibile ed eseguono la logica di business implementata in vari linguaggi come Java, JavaScript, Groovy, Python o Ruby.

• Filters - Filtrano i messaggi e consentono solo a messaggi specifici di continuare a essere elaborati in un flusso, in base a criteri specifici.

• Routers - Questo elaboratore di messaggi viene utilizzato per controllare il flusso di messaggi da instradare, risequenziare o dividere.

• Scopes - Ehi fondamentalmente racchiudi frammenti di codice allo scopo di definire un comportamento a grana fine all'interno di un flusso.

• Transformers - Il ruolo dei trasformatori è convertire il tipo di payload del messaggio e il formato dei dati per facilitare la comunicazione tra i sistemi.

• Business Events - Fondamentalmente acquisiscono i dati associati agli indicatori chiave di prestazione.

• Exception strategies - Questi processori di messaggi gestiscono errori di qualsiasi tipo che si verificano durante l'elaborazione dei messaggi.

Una delle capacità più importanti di Mule è che può eseguire instradamento, trasformazione ed elaborazione con i componenti, per questo motivo il file di configurazione dell'applicazione Mule che combina vari elementi è di dimensioni molto grandi.

Di seguito sono riportati i tipi di modelli di configurazione forniti da Mule:

• Modello di servizio semplice
• Bridge
• Validator
• Proxy HTTP
• Proxy WS

Configurazione del componente

In Anypoint studio, possiamo seguire i passaggi seguenti per configurare un componente:

Step 1

Dobbiamo trascinare il componente che desideriamo utilizzare nella nostra applicazione Mule. Ad esempio, qui utilizziamo il componente listener HTTP come segue:

Step 2

Quindi, fare doppio clic sul componente per visualizzare la finestra di configurazione. Per il listener HTTP, è mostrato di seguito:

Step 3

Possiamo configurare il componente secondo il requisito del nostro progetto. Supponiamo, ad esempio, che abbiamo fatto per il componente listener HTTP:

I componenti principali sono uno degli elementi costitutivi importanti del flusso di lavoro nell'app Mule. La logica per l'elaborazione di un evento Mule è fornita da questi componenti principali. In Anypoint studio, per accedere a questi componenti principali, è possibile fare clic su Core da Mule Palette come mostrato di seguito -

Di seguito sono vari core components and their working in Mule 4 -

Eventi aziendali personalizzati

Questo componente principale viene utilizzato per la raccolta di informazioni sui flussi e sui processori di messaggi che gestiscono le transazioni aziendali nell'app Mule. In altre parole, possiamo utilizzare il componente Evento aziendale personalizzato per aggiungere quanto segue nel nostro flusso di lavoro:

• Metadata
• Indicatori chiave di prestazione (KPI)

Come aggiungere i KPI?

Di seguito sono riportati i passaggi per aggiungere KPI nel nostro flusso nell'app Mule:

Step 1 - Segui Mule Palette → Core → Components → Custom Business Event, per aggiungere il componente Evento aziendale personalizzato a un flusso di lavoro nella tua app Mule.

Step 2 - Fare clic sul componente per aprirlo.

Step 3 - Ora, dobbiamo fornire valori per Nome visualizzato e Nome evento.

Step 4 - Per acquisire informazioni dal payload del messaggio, aggiungi i KPI come segue:

• Assegna un nome (chiave) al KPI ( tracking: elemento metadati ) e un valore. Il nome verrà utilizzato nell'interfaccia di ricerca di Runtime Manager.

• Assegna un valore che può essere qualsiasi espressione di Mule.

Esempio

La tabella seguente è composta dall'elenco di KPI con nome e valore -

Nome	Espressione / valore
Student RollNo	# [payload ['RollNo']]
Nome dello studente	# [payload ['Name']]

Valutazione dinamica

Questo componente principale viene utilizzato per selezionare dinamicamente uno script nell'app Mule. Possiamo anche utilizzare lo script hardcore tramite il componente Transform Message, ma l'utilizzo del componente Dynamic Evaluate è un modo migliore. Questo componente principale funziona come segue:

• In primo luogo, valuta un'espressione che dovrebbe risultare in un altro script.
• Quindi valuta quello script per il risultato finale.

In questo modo, ci permette di selezionare dinamicamente lo script piuttosto che codificarlo.

Esempio

Di seguito è riportato un esempio di selezione di uno script dal database tramite un parametro di query Id e memorizzazione di tale script in una variabile denominata MyScript . Ora, il componente di valutazione dinamica accederà alla variabile per richiamare gli script in modo che possa aggiungere una variabile di nome daUName parametro di query.

La configurazione XML del flusso è fornita di seguito:

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

Lo script può utilizzare variabili di contesto come messaggio, payload, vars o attributi. Tuttavia, se desideri aggiungere una variabile di contesto personalizzata, devi fornire una serie di coppie chiave-valore.

Configurazione della valutazione dinamica

La tabella seguente fornisce un modo per configurare il componente di valutazione dinamica:

Campo	Valore	Descrizione	Esempio
Espressione	DataWeave espressione	Specifica l'espressione da valutare nello script finale.	espressione = "# [vars.generateOrderScript]"
Parametri	DataWeave espressione	Specifica le coppie chiave-valore.	# [{joiner: 'and', id: payload.user.id}]

Componente di riferimento del flusso

Se desideri instradare l'evento Mule a un altro flusso o sotto-flusso e di nuovo all'interno della stessa app Mule, il componente di riferimento del flusso è l'opzione giusta.

Caratteristiche

Di seguito sono riportate le caratteristiche di questo componente principale:

• Questo componente principale ci consente di trattare l'intero flusso di riferimento come un singolo componente nel flusso di corrente.

• Suddividi l'applicazione Mule in unità discrete e riutilizzabili. Ad esempio, un flusso elenca i file su base regolare. Potrebbe fare riferimento a un altro flusso che elabora l'output dell'operazione di elenco.

• In questo modo, invece di aggiungere tutte le fasi di elaborazione, possiamo aggiungere riferimenti di flusso che puntano al flusso di elaborazione. Lo screenshot seguente mostra che il componente principale di riferimento del flusso punta verso un flusso secondario denominatoProcessFiles.

Lavorando

Il funzionamento del componente Flow Ref può essere compreso con l'aiuto del seguente diagramma:

Il diagramma mostra l'ordine di elaborazione nell'applicazione Mule quando un flusso fa riferimento a un altro flusso nella stessa applicazione. Quando il flusso di lavoro principale nell'applicazione Mule si è attivato, l'evento Mule percorre tutto ed esegue il flusso finché l'evento Mule non raggiunge il riferimento di flusso.

Dopo aver raggiunto Flow Reference, l'evento Mule esegue il flusso di riferimento dall'inizio alla fine. Una volta che l'evento Mule termina l'esecuzione del flusso di riferimento, torna al flusso principale.

Esempio

Per una migliore comprensione, let us use this component in Anypoint Studio. In questo esempio, stiamo portando il listener HTTP per OTTENERE un messaggio, come abbiamo fatto nel capitolo precedente. Quindi, possiamo trascinare e rilasciare il componente e configurare. Ma per questo esempio, dobbiamo aggiungere un componente di flusso secondario e impostare il componente Payload sotto quello, come mostrato di seguito -

Successivamente, dobbiamo configurare Set Payload, facendo doppio clic su di esso. Qui stiamo dando il valore, "Flusso secondario eseguito" come mostrato di seguito -

Una volta configurato correttamente il componente di flusso secondario, è necessario che il componente di riferimento del flusso venga impostato dopo Imposta carico utile del flusso principale, che possiamo trascinare e rilasciare dalla tavolozza Mule come mostrato di seguito -

Successivamente, durante la configurazione del componente di riferimento del flusso, è necessario scegliere Nome flusso nella scheda Generico come mostrato di seguito -

Ora salva ed esegui questa applicazione. Per verificarlo, vai su POSTINO e digitahttp:/localhost:8181/FirstAPP nella barra dell'URL e riceverai il messaggio Sub flow eseguito.

Componente logger

Il componente principale chiamato logger ci aiuta a monitorare ed eseguire il debug della nostra applicazione Mule registrando informazioni importanti come messaggi di errore, notifiche di stato, payload, ecc. In AnyPoint studio, vengono visualizzati nel Console.

Vantaggi

Di seguito sono riportati alcuni vantaggi del componente Logger:

• Possiamo aggiungere questo componente principale ovunque nel flusso di lavoro.
• Possiamo configurarlo per registrare una stringa specificata da noi.
• Possiamo configurarlo sull'output di un'espressione DataWeave scritta da noi.
• Possiamo anche configurarlo su qualsiasi combinazione di stringhe ed espressioni.

Esempio

L'esempio seguente mostra il messaggio "Hello World" nel Set Payload in un browser e registra anche il messaggio.

Di seguito è riportata la configurazione XML del flusso nell'esempio precedente:

<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 del messaggio di trasferimento

Transform Message Component, chiamato anche componente Transfer, ci consente di convertire i dati di input in un nuovo formato di output.

Metodi per costruire la trasformazione

Possiamo costruire la nostra trasformazione con l'aiuto dei seguenti due metodi:

Drag-and-Drop Editor (Graphical View)- Questo è il primo e il più utilizzato metodo per costruire la nostra trasformazione. In questo metodo, possiamo usare il visual mapper di questo componente per trascinare e rilasciare gli elementi della struttura dei dati in entrata. Ad esempio, nel diagramma seguente, due visualizzazioni ad albero mostrano le strutture di metadati previste dell'input e dell'output. Le linee che collegano l'input al campo di output rappresentano la mappatura tra due viste ad albero.

Script View- La mappatura visiva di Transformation può essere rappresentata anche con l'aiuto di DataWeave, un linguaggio per il codice Mule. Possiamo eseguire la codifica per alcune trasformazioni avanzate come aggregazione, normalizzazione, raggruppamento, unione, partizionamento, rotazione e filtraggio. L'esempio è fornito di seguito:

Questo componente principale accetta fondamentalmente i metadati di input e output per una variabile, un attributo o un payload del messaggio. Possiamo fornire risorse specifiche per formato per quanto segue:

• CSV
• Schema
• Schema di file flat
• JSON
• Classe di oggetti
• Tipo semplice
• Schema XML
• Nome e tipo di colonna di Excel
• Nome e tipo di colonna a larghezza fissa

Gli endpoint includono fondamentalmente quei componenti che attivano o avviano l'elaborazione in un flusso di lavoro dell'applicazione Mule. Sono chiamatiSource in Anypoint Studio e Triggersnel Design Center di Mule. Un importante endpoint in Mule 4 èScheduler component.

Endpoint dello scheduler

Questo componente funziona su condizioni basate sul tempo, il che significa che ci consente di attivare un flusso ogni volta che viene soddisfatta una condizione basata sul tempo. Ad esempio, uno scheduler può attivare un evento per avviare un flusso di lavoro di Mule ogni, diciamo 10 secondi. Possiamo anche utilizzare un'espressione Cron flessibile per attivare un endpoint dello scheduler.

Punti importanti su Scheduler

Durante l'utilizzo dell'evento Scheduler, dobbiamo occuparci di alcuni punti importanti come indicato di seguito:

• Scheduler Endpoint segue il fuso orario della macchina su cui è in esecuzione il runtime di Mule.

• Supponiamo che se un'applicazione Mule è in esecuzione in CloudHub, lo Scheduler seguirà il fuso orario della regione in cui è in esecuzione il worker CloudHub.

• In qualsiasi momento, può essere attivo un solo flusso attivato dall'endpoint dello scheduler.

• Nel cluster di runtime Mule, l'endpoint dello scheduler viene eseguito o si attiva solo sul nodo primario.

Modi per configurare uno scheduler

Come discusso in precedenza, possiamo configurare un endpoint dello scheduler in modo che venga attivato a un intervallo fisso o possiamo anche fornire un'espressione Cron.

Parametri per configurare una pianificazione (per intervallo fisso)

Di seguito sono riportati i parametri per impostare uno scheduler per attivare un flusso a intervalli regolari:

Frequency- Descrive fondamentalmente con quale frequenza l'endpoint dello scheduler attiverà il flusso del mulo. L'unità di tempo per questo può essere selezionata dal campo Unità di tempo. Se non si fornisce alcun valore per questo, verrà utilizzato il valore predefinito che è 1000. D'altro lato, se si fornisce 0 o un valore negativo, verrà utilizzato anche il valore predefinito.

Start Delay- È la quantità di tempo che dobbiamo attendere prima di attivare il flusso Mule per la prima volta una volta avviata l'applicazione. Il valore di Start delay è espresso nella stessa unità di tempo della frequenza. Il suo valore predefinito è 0.

Time Unit- Descrive l'unità di tempo sia per la frequenza che per il ritardo di avvio. I possibili valori dell'unità di tempo sono Millisecondi, Secondi, Minuti, Ore, Giorni. Il valore predefinito è Millisecondi.

Parametri per configurare uno scheduler (per l'espressione Cron)

In realtà, Cron è uno standard utilizzato per descrivere le informazioni di data e ora. Se utilizzi l'espressione Cron flessibile per attivare lo Scheduler, l'endpoint dello Scheduler tiene traccia di ogni secondo e crea un evento Mule ogni volta che l'espressione Cron Quartz corrisponde all'impostazione della data e dell'ora. Con l'espressione Cron, l'evento può essere attivato solo una volta o a intervalli regolari.

La tabella seguente fornisce l'espressione data-ora di sei impostazioni richieste:

Attributo	Valore
Secondi	0-59
Minuti	0-59
Ore	0-23
Giorno del mese	1-31
Mese	1-12 o GEN-DIC
Giorno della settimana	1-7 o DOM-SAB

Di seguito sono forniti alcuni esempi di espressioni Quartz Cron supportate dall'endpoint dello scheduler:

• ½ * * * * ? - significa che lo scheduler viene eseguito ogni 2 secondi del giorno, ogni giorno.

• 0 0/5 16 ** ? - significa che lo scheduler viene eseguito ogni 5 minuti a partire dalle 16:00 e termina alle 16:55, tutti i giorni.

• 1 1 1 1, 5 * ? - significa che lo scheduler viene eseguito il primo giorno di gennaio e il primo giorno di aprile di ogni anno.

Esempio

Il codice seguente registra il messaggio "ciao" ogni secondo -

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

Controllo di flusso (router)

Il compito principale del componente Flow Control è prendere l'evento Mule di input e instradarlo a una o più sequenze separate di componenti. Fondamentalmente sta instradando l'evento Mule in ingresso ad altre sequenze di componenti. Pertanto, è anche chiamato router. I router Choice e Scatter-Gather sono i router più utilizzati nel componente Flow Control.

Scelta del router

Come suggerisce il nome, questo router applica la logica DataWeave per scegliere uno tra due o più percorsi. Come discusso in precedenza, ogni route è una sequenza separata di processori di eventi Mule. Possiamo definire router di scelta come il router che instrada dinamicamente il messaggio attraverso un flusso secondo un insieme di espressioni DataWeave utilizzate per valutare il contenuto del messaggio.

Diagramma schematico di Choice Router

L'effetto dell'utilizzo di Choice router è proprio come l'aggiunta di un'elaborazione condizionale a un flusso o un file if/then/elseblocco di codice nella maggior parte dei linguaggi di programmazione. Di seguito è riportato il diagramma schematico di un Choice Router, con tre opzioni. Tra questi, uno è il router predefinito.

Router a dispersione

Un altro processore di eventi di routing più utilizzato è Scatter-Gather component. Come suggerisce il nome, funziona sui fondamenti di scatter (copia) e Gather (consolida). Possiamo capire il suo funzionamento con l'aiuto dei seguenti due punti:

• Innanzitutto, questo router copia (Scatter) un evento Mule su due o più route parallele. La condizione è che ogni percorso deve essere una sequenza di uno o più processori di eventi che è come un flusso secondario. Ogni percorso in questo caso creerà un evento Mule utilizzando un thread separato. Ogni evento Mule avrà il proprio payload, attributi e variabili.

• Successivamente, questo router raccoglie gli eventi Mule creati da ogni percorso e li consolida insieme in un nuovo evento Mule. Successivamente, passa questo evento Mule consolidato al processore di eventi successivo. Qui la condizione è che il router SG passi un evento Mule consolidato al processore di eventi successivo solo quando ogni percorso è stato completato con successo.

Diagramma schematico del router Scatter-Gather

Di seguito è riportato il diagramma schematico di un router Scatter-Gather con quattro processori di eventi. Esegue ogni percorso in parallelo e non in sequenza.

Gestione degli errori da parte del router Scatter-Gather

Innanzitutto, dobbiamo conoscere il tipo di errore che può essere generato all'interno del componente Scatter-Gather. Qualsiasi errore potrebbe essere generato all'interno dei processori di eventi che portano il componente Scatter-Gather a generare un errore di tipoMule: COMPOSITE_ERROR. Questo errore verrà generato dal componente SG solo dopo che ogni route fallisce o viene completata.

Per gestire questo tipo di errore, a try scopepuò essere utilizzato in ogni percorso del componente Scatter-Gather. Se l'errore viene gestito con successo datry scope, quindi il percorso sarà sicuramente in grado di generare un evento Mule.

Transformers

Supponiamo di voler impostare o rimuovere una parte di qualsiasi evento Mule, il componente Transformer è la scelta migliore. I componenti del trasformatore sono dei seguenti tipi:

Rimuovere il trasformatore variabile

Come suggerisce il nome, questo componente prende un nome di variabile e rimuove quella variabile dall'evento Mule.

Configurazione della rimozione del trasformatore variabile

La tabella seguente mostra il nome dei campi e la loro descrizione da considerare durante la configurazione della rimozione del trasformatore variabile -

Suor n	Campo e spiegazione
1	Display Name (doc:name) Possiamo personalizzarlo per visualizzare un nome univoco per questo componente nel nostro flusso di lavoro Mule.
2	Name (variableName) Rappresenta il nome della variabile da rimuovere.

Impostare il trasformatore del carico utile

Con l'aiuto di set-payloadcomponente, possiamo aggiornare il payload, che può essere una stringa letterale o un'espressione DataWeave, del messaggio. Non è consigliabile utilizzare questo componente per espressioni o trasformazioni complesse. Può essere usato per quelli semplici comeselections.

La tabella seguente mostra il nome dei campi e la loro descrizione da considerare durante la configurazione del set payload transformer -

Campo	Utilizzo	Spiegazione
Valore (valore)	Obbligatorio	Il valore archiviato è necessario per impostare un payload. Accetterà una stringa letterale o un'espressione DataWeave che definisce come impostare il payload. Gli esempi sono come "una stringa"
Tipo Mime (mimeType)	Opzionale	È facoltativo ma rappresenta il tipo MIME del valore assegnato al payload del messaggio. Gli esempi sono come testo / semplice.
Codifica (codifica)	Opzionale	È anche facoltativo ma rappresenta la codifica del valore assegnato al payload del messaggio. Gli esempi sono come UTF-8.

Possiamo impostare un payload tramite il codice di configurazione XML -

With Static Content - Il seguente codice di configurazione XML imposterà il payload utilizzando contenuto statico -

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

With Expression Content - Il seguente codice di configurazione XML imposterà il payload utilizzando il contenuto di Expression -

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

L'esempio precedente aggiungerà la data odierna con il payload del messaggio "Ciao".

Imposta trasformatore variabile

Con l'aiuto di set variablecomponente, possiamo creare o aggiornare una variabile per memorizzare valori che possono essere semplici valori letterali come stringhe, payload di messaggi o oggetti attributo, da utilizzare all'interno del flusso dell'applicazione Mule. Non è consigliabile utilizzare questo componente per espressioni o trasformazioni complesse. Può essere usato per quelli semplici comeselections.

Configurazione del trasformatore della variabile impostata

La tabella seguente mostra il nome dei campi e la loro descrizione da considerare durante la configurazione del set payload transformer -

Campo	Utilizzo	Spiegazione
Nome variabile (nomeVariabile)	Obbligatorio	È un campo obbligatorio e rappresenta il nome della variabile. Mentre si assegna il nome, seguire la convenzione di denominazione in quanto deve contenere numero, caratteri e trattini bassi.
Valore (valore)	Obbligatorio	Il valore archiviato è necessario per impostare una variabile. Accetterà una stringa letterale o un'espressione DataWeave.
Tipo Mime (mimeType)	Opzionale	È facoltativo ma rappresenta il tipo MIME della variabile. Gli esempi sono come testo / semplice.
Codifica (codifica)	Opzionale	È anche facoltativo ma rappresenta la codifica della variabile. Gli esempi sono come ISO 10646 / Unicode (UTF-8).

Esempio

L'esempio seguente imposterà la variabile sul payload del messaggio:

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

Allo stesso modo, l'esempio seguente imposterà la variabile sul payload del messaggio:

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

Servizio Web REST

La forma completa di REST è il trasferimento di stato rappresentativo che è associato a HTTP. Quindi, se vuoi progettare un'applicazione da utilizzare esclusivamente sul web, REST è l'opzione migliore.

Consumo di servizi Web RESTful

Nell'esempio seguente, utilizzeremo il componente REST e un servizio RESTful pubblico fornito da Mule Soft chiamato dettagli American Flights. Ha vari dettagli ma useremo GET:http://training-american-ws.cloudhub.io/api/flightsche restituirà tutti i dettagli del volo. Come discusso in precedenza, REST è associato a HTTP, quindi abbiamo bisogno di due componenti HTTP: uno è Listener e l'altro è Request, anche per questa applicazione. La schermata sottostante mostra la configurazione per il listener HTTP:

Configurazione e passaggio di argomenti

La configurazione per la richiesta HTTP è fornita di seguito:

Ora, come da flusso del nostro spazio di lavoro, abbiamo preso il logger in modo che possa essere configurato come di seguito:

Nella scheda del messaggio, scriviamo il codice per convertire il payload in stringhe.

Test dell'applicazione

Ora salva ed esegui l'applicazione e vai su POSTMAN per controllare l'output finale come mostrato di seguito -

Puoi vedere che fornisce i dettagli del volo utilizzando il componente REST.

Componente SOAP

La forma completa di SOAP è Simple Object Access Protocol. È fondamentalmente una specifica del protocollo di messaggistica per lo scambio di informazioni nell'implementazione dei servizi web. Successivamente, utilizzeremo l'API SOAP in Anypoint Studio per accedere alle informazioni utilizzando i servizi web.

Consumo di servizi Web basati su SOAP

Per questo esempio, utilizzeremo il servizio SOAP pubblico il cui nome è Country Info Service che conserva i servizi relativi alle informazioni sul paese. Il suo indirizzo WSDL è:http://www.oorsprong.org/websamples.countryinfo/countryinfoservice.wso?WSDL

Per prima cosa, dobbiamo trascinare il consumo SOAP nella nostra tela da Mule Palette come mostrato di seguito -

Configurazione e passaggio di argomenti

Successivamente, dobbiamo configurare la richiesta HTTP come nell'esempio sopra come indicato di seguito -

Ora, dobbiamo anche configurare il consumatore del servizio Web come mostrato di seguito:

Al posto di WSDL Location, dobbiamo fornire l'indirizzo web di WSDL, fornito sopra (per questo esempio). Una volta fornito l'indirizzo web, Studio cercherà da solo il servizio, la porta e l'indirizzo. Non è necessario fornirlo manualmente.

Trasferisci risposta dal servizio Web

Per questo, dobbiamo aggiungere un logger nel flusso Mule e configurarlo per dare il payload come mostrato di seguito -

Test dell'applicazione

Salva ed esegui l'applicazione e vai su Google Chrome per controllare l'output finale. generehttp://localhist:8081/helloSOAP (per questo esempio) e mostrerà il nome del paese per codice come mostrato nello screenshot qui sotto -

La nuova gestione degli errori di Mule è uno dei più grandi e importanti cambiamenti apportati in Mule 4. La nuova gestione degli errori può sembrare complessa, ma è migliore e più efficiente. In questo capitolo, discuteremo dei componenti dell'errore di Mule, dei tipi di errore, delle categorie dell'errore di Mule e dei componenti per la gestione degli errori di Mule.

Componenti di Mule Error

L'errore Mule è il risultato dell'errore dell'eccezione Mule ha i seguenti componenti:

Descrizione

È una componente importante dell'errore di Mule che fornirà una descrizione del problema. La sua espressione è la seguente:

#[error.description]

genere

Il componente Tipo di errore del mulo viene utilizzato per caratterizzare il problema. Consente inoltre il routing all'interno di un gestore di errori. La sua espressione è la seguente:

#[error.errorType]

Causa

Il componente Cause dell'errore Mule fornisce il lancio java sottostante che causa l'errore. La sua espressione è la seguente:

#[error.cause]

Messaggio

Il componente Messaggio di Mule error mostra un messaggio opzionale relativo all'errore. La sua espressione è la seguente:

#[error.errorMessage]

Errori figlio

Il componente Errori figlio di Mule error fornisce una raccolta facoltativa di errori interni. Questi errori interni vengono utilizzati principalmente da elementi come Scatter-Gather per fornire errori di route aggregati. La sua espressione è la seguente:

#[error.childErrors]

Esempio

In caso di fallimento della richiesta HTTP con un codice di stato 401, gli errori di Mule sono i seguenti:

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.NO	Tipo di errore e descrizione
1	TRANSFORMATION Questo tipo di errore indica che si è verificato un errore durante la trasformazione di un valore. La trasformazione è la trasformazione interna di Mule Runtime e non le trasformazioni DataWeave.
2	EXPRESSION Questo tipo di tipo di errore indica che si è verificato un errore durante la valutazione di un'espressione.
3	VALIDATION Questo tipo di tipo di errore indica che si è verificato un errore di convalida.
4	DUPLICATE_MESSAGE Un tipo di errore di convalida che si verifica quando un messaggio viene elaborato due volte.
5	REDELIVERY_EXHAUSTED Questo tipo di tipo di errore si verifica quando il numero massimo di tentativi per rielaborare un messaggio da un'origine è stato esaurito.
6	CONNECTIVITY Questo tipo di errore indica un problema durante la creazione di una connessione.
7	ROUTING Questo tipo di errore indica che si è verificato un errore durante l'instradamento di un messaggio.
8	SECURITY Questo tipo di errore indica che si è verificato un errore di sicurezza. Ad esempio, credenziali non valide ricevute.
9	STREAM_MAXIMUM_SIZE_EXCEEDED Questo tipo di errore si verifica quando la dimensione massima consentita per un flusso è esaurita.
10	TIMEOUT Indica il timeout durante l'elaborazione di un messaggio.
11	UNKNOWN Questo tipo di errore indica che si è verificato un errore imprevisto.
12	SOURCE Rappresenta il verificarsi di un errore nella sorgente del flusso.
13	SOURCE_RESPONSE Rappresenta il verificarsi di un errore nella sorgente del flusso durante l'elaborazione di una risposta riuscita.

Nell'esempio sopra, puoi vedere il componente messaggio di errore mulo.

Tipi di errore

Cerchiamo di capire i tipi di errore con l'aiuto delle sue caratteristiche:

• La prima caratteristica di Mule Error Types è che consiste in entrambi, a namespace and an identifier. Questo ci permette di distinguere i tipi in base al loro dominio. Nell'esempio precedente, il tipo di errore èHTTP: UNAUTHORIZED.

• La seconda e importante caratteristica è che il tipo di errore può avere un tipo padre. Ad esempio, il tipo di erroreHTTP: UNAUTHORIZED ha MULE:CLIENT_SECURITY come genitore che a sua volta ha anche un genitore di nome MULE:SECURITY. Questa caratteristica stabilisce il tipo di errore come specifica di un elemento più globale.

Tipi di tipi di errore

Di seguito sono riportate le categorie in cui rientrano tutti gli errori:

QUALUNQUE

Gli errori in questa categoria sono gli errori che possono verificarsi in un flusso. Non sono così gravi e possono essere gestiti facilmente.

CRITICO

Gli errori in questa categoria sono gli errori gravi che non possono essere gestiti. Di seguito è riportato l'elenco dei tipi di errore in questa categoria:

Sr.NO	Tipo di errore e descrizione
1	OVERLOAD Questo tipo di errore indica che si è verificato un errore dovuto a un problema di sovraccarico. In questo caso l'esecuzione verrà rifiutata.
2	FATAL_JVM_ERROR Questo tipo di tipo di errore indica il verificarsi di un errore irreversibile. Ad esempio, stack overflow.

Tipo di errore PERSONALIZZATO

I Tipi di errore PERSONALIZZATI sono gli errori che vengono definiti da noi. Possono essere definiti durante la mappatura o quando si segnalano gli errori. Dobbiamo assegnare uno spazio dei nomi personalizzato specifico a questi tipi di errore per distinguerli dagli altri tipi di errore esistenti all'interno dell'applicazione Mule. Ad esempio, nell'applicazione Mule che utilizza HTTP, non possiamo utilizzare HTTP come tipo di errore personalizzato.

Categorie di errore del mulo

In senso lato, gli errori in Mule possono essere suddivisi in due categorie e cioè, Messaging Errors and System Errors.

Errore di messaggistica

Questa categoria di errore del mulo è correlata al flusso del mulo. Ogni volta che si verifica un problema all'interno di un flusso Mule, Mule genera un errore di messaggistica. Possiamo organizzareOn Error componente all'interno del componente gestore degli errori per gestire questi errori di Mule.

Errore di sistema

L'errore di sistema indica un'eccezione che si è verificata a livello di sistema. Se non è presente alcun evento Mule, l'errore di sistema viene gestito da un gestore degli errori di sistema. Il seguente tipo di eccezioni gestite da un gestore degli errori di sistema:

• Eccezione che si verifica durante l'avvio di un'applicazione.
• Eccezione che si verifica quando una connessione a un sistema esterno non riesce.

In caso di errore di sistema, Mule invia una notifica di errore ai listener registrati. Registra anche l'errore. D'altra parte, Mule esegue una strategia di riconnessione se l'errore è stato causato da un errore di connessione.

Gestione degli errori del mulo

Mule ha i seguenti due gestori di errori per la gestione degli errori:

Gestori degli errori in caso di errore

Il primo gestore di errori di Mule è il componente On-Error, che definisce i tipi di errori che possono gestire. Come discusso in precedenza, possiamo configurare i componenti On-Error all'interno del componente Error Handler di tipo scope. Ogni flusso Mule contiene un solo gestore degli errori, ma questo gestore degli errori può contenere tutti gli ambiti On-Error necessari. I passaggi per la gestione dell'errore Mule all'interno del flusso, con l'aiuto del componente On-Error, sono i seguenti:

• Innanzitutto, ogni volta che un flusso Mule genera un errore, la normale esecuzione del flusso si interrompe.

• Successivamente, il processo verrà trasferito al file Error Handler Component che già hanno On Error component per abbinare i tipi di errore e le espressioni.

• Infine, il componente Error Handler instrada l'errore al primo On Error scope che corrisponde all'errore.

Di seguito sono riportati i due tipi di componenti On-Error supportati da Mule:

Propaga in caso di errore

Il componente On-Error Propagate viene eseguito ma propaga l'errore al livello successivo e interrompe l'esecuzione del proprietario. La transazione verrà annullata se viene gestita daOn Error Propagate componente.

Continua in caso di errore

Come il componente Propagazione in caso di errore, anche il componente Continua in caso di errore esegue la transazione. L'unica condizione è che, se il proprietario ha completato correttamente l'esecuzione, questo componente utilizzerà il risultato dell'esecuzione come risultato del suo proprietario. La transazione verrà salvata se viene gestita dal componente Continua in caso di errore.

Prova il componente Scope

Try Scope è una delle tante nuove funzionalità disponibili in Mule 4. Funziona in modo simile al blocco try di JAVA in cui si racchiudeva il codice con la possibilità di essere un'eccezione, in modo che possa essere gestito senza rompere l'intero codice.

Possiamo racchiudere uno o più processori di eventi Mule in Try Scope e, successivamente, try scope catturerà e gestirà qualsiasi eccezione generata da questi processori di eventi. Il funzionamento principale dell'ambito di try ruota attorno alla propria strategia di gestione degli errori che supporta la gestione degli errori sul suo componente interno anziché sull'intero flusso. Ecco perché non abbiamo bisogno di estrarre il flusso in un flusso separato.

Example

Di seguito è riportato un esempio di utilizzo dell'ambito try:

Configurazione dell'ambito di prova per la gestione delle transazioni

Come sappiamo, una transazione è una serie di azioni che non dovrebbero mai essere eseguite parzialmente. Tutte le operazioni nell'ambito di una transazione vengono eseguite nello stesso thread e se si verifica un errore, dovrebbe portare a un rollback o un commit. Possiamo configurare l'ambito try, nel modo seguente, in modo che tratti le operazioni figlio come una transazione.

• INDIFFERENT [Default]- Se scegliamo questa configurazione nel blocco try, le azioni figlio non verranno trattate come una transazione. In questo caso, l'errore non causa né il rollback né il commit.

• ALWAYS_BEGIN - Indica che verrà avviata una nuova transazione ogni volta che viene eseguito l'ambito.

• BEGIN_OR_JOIN- Indica che se l'attuale elaborazione del flusso ha già avviato una transazione, unisciti a essa. Altrimenti, avviane uno nuovo.

In ogni progetto, il fatto sulle eccezioni è che sono destinate a verificarsi. Questo è il motivo per cui è importante rilevare, classificare e gestire le eccezioni in modo che il sistema / applicazione non venga lasciato in uno stato incoerente. Esiste una strategia di eccezione predefinita che viene applicata implicitamente a tutte le applicazioni Mule. Il rollback automatico di qualsiasi transazione in sospeso è la strategia di eccezione predefinita.

Eccezioni in Mule

Prima di immergerci in profondità nella gestione delle eccezioni, dobbiamo capire che tipo di eccezioni possono verificarsi insieme a tre domande fondamentali che uno sviluppatore deve avere durante la progettazione dei gestori di eccezioni.

Quale trasporto è importante?

Questa domanda ha ampia rilevanza prima di progettare gestori di eccezioni perché tutti i trasporti non supportano la transnazionalità.

File o HTTPnon supporta le transazioni. Ecco perché, se in questi casi si verifica un'eccezione, dobbiamo gestirla manualmente.

Databasessostenere le transazioni. Durante la progettazione di gestori di eccezioni in questo caso, dobbiamo tenere presente che le transazioni del database possono automaticamente eseguire il rollback (se necessario).

In caso di REST APIs, dobbiamo tenere presente che dovrebbero restituire i codici di stato HTTP corretti. Ad esempio, 404 per una risorsa non trovata.

Quale modello di scambio di messaggi utilizzare?

Durante la progettazione dei gestori di eccezioni, dobbiamo prestare attenzione al modello di scambio dei messaggi. Può esserci un pattern di messaggio sincrono (richiesta-risposta) o asincrono (fuoco-dimenticare).

Synchronous message pattern si basa sul formato richiesta-risposta, il che significa che questo modello si aspetterà una risposta e verrà bloccato fino a quando non verrà restituita una risposta o si verificherà un timeout.

Asynchronous message pattern è basato sul formato Fire-Forget, il che significa che questo modello presuppone che le richieste verranno elaborate.

Di che tipo di eccezione si tratta?

Una regola molto semplice è che gestirai l'eccezione in base al suo tipo. È molto importante sapere se l'eccezione è causata da un problema tecnico / di sistema o da un problema aziendale?

Si è verificata un'eccezione da system/technical issue (come l'interruzione della rete) dovrebbe essere gestito automaticamente da un meccanismo di ripetizione.

D'altra parte, si è verificata un'eccezione by a business issue (come i dati non validi) non dovrebbero essere risolti applicando il meccanismo di ripetizione perché non è utile riprovare senza correggere la causa sottostante.

Perché classificare le eccezioni?

Poiché sappiamo che tutte le eccezioni non sono uguali, è molto importante classificare le eccezioni. Ad alto livello, le eccezioni possono essere classificate nei seguenti due tipi:

Eccezioni aziendali

I motivi principali per il verificarsi di eccezioni aziendali sono dati errati o flusso di processo errato. Questi tipi di eccezioni sono in genere di natura non modificabile e quindi non è consigliabile configurare un filerollback. Anche applicandoretryIl meccanismo non avrebbe alcun senso perché non è utile riprovare senza risolvere la causa sottostante. Per gestire tali eccezioni, l'elaborazione dovrebbe interrompersi immediatamente e l'eccezione deve essere restituita come risposta a una coda di messaggi non recapitabili. Una notifica dovrebbe anche inviare alle operazioni.

Eccezioni non commerciali

I motivi principali per il verificarsi di eccezioni non aziendali sono problemi di sistema o problemi tecnici. Questi tipi di eccezioni sono ripetibili in natura e quindi è bene configurare un fileretry meccanismo per risolvere queste eccezioni.

Strategie di gestione delle eccezioni

Mule ha le seguenti cinque strategie di gestione delle eccezioni:

Strategia di eccezione predefinita

Mule applica implicitamente questa strategia ai flussi di Mule. Può gestire tutte le eccezioni nel nostro flusso, ma può anche essere sovrascritto aggiungendo una strategia di eccezione catch, Choice o Rollback. Questa strategia di eccezione ripristinerà tutte le transazioni in sospeso e registrerà anche le eccezioni. Una caratteristica importante di questa strategia di eccezione è che registrerà anche l'eccezione se non ci sono transazioni.

Essendo la strategia predefinita, Mule la implementa quando si verifica un errore nel flusso. Non possiamo configurare in AnyPoint studio.

Strategia di eccezione di rollback

Supponiamo che se non esiste una possibile soluzione per correggere l'errore, cosa fare? Una soluzione consiste nell'usare la strategia di eccezione di rollback che eseguirà il rollback della transazione insieme all'invio di un messaggio al connettore in entrata del flusso principale per rielaborare il messaggio. Questa strategia è anche molto utile quando vogliamo rielaborare un messaggio.

Example

Questa strategia può essere applicata alle transazioni bancarie in cui i fondi vengono depositati in un conto corrente / di risparmio. Possiamo configurare una strategia di eccezione di rollback qui perché nel caso in cui si verifichi un errore durante la transazione, questa strategia riporta il messaggio all'inizio nel flusso per ritentare l'elaborazione.

Strategia di cattura delle eccezioni

Questa strategia cattura tutte le eccezioni che vengono generate nel suo flusso padre. Ignora la strategia di eccezione predefinita di Mule elaborando tutte le eccezioni generate dal flusso padre. Possiamo utilizzare una strategia di cattura delle eccezioni per evitare di propagare le eccezioni anche ai connettori in entrata e ai flussi principali.

Questa strategia garantisce inoltre che una transazione elaborata dal flusso non venga annullata quando si verifica un'eccezione.

Example

Questa strategia può essere applicata al sistema di prenotazione dei voli in cui abbiamo un flusso per l'elaborazione dei messaggi da una coda. Un arricchitore di messaggi aggiunge una proprietà al messaggio per l'assegnazione del posto e quindi invia il messaggio a un'altra coda.

Se si verifica un errore in questo flusso, il messaggio genererà un'eccezione. Qui, la nostra strategia di cattura delle eccezioni può aggiungere un'intestazione con un messaggio appropriato e può spingere quel messaggio fuori dal flusso alla coda successiva.

Scelta della strategia di eccezione

Nel caso in cui desideri gestire l'eccezione in base al contenuto del messaggio, la strategia di eccezione di scelta sarebbe la scelta migliore. Il funzionamento di questa strategia di eccezione sarà il seguente:

• Innanzitutto, cattura tutte le eccezioni generate all'interno del flusso padre.
• Successivamente, verifica il contenuto del messaggio e il tipo di eccezione.
• Infine, instrada il messaggio alla strategia di eccezione appropriata.

Ci sarebbe più di una strategia di eccezione come Catch o Rollback, definita nella strategia di eccezione di scelta. Nel caso in cui non sia stata definita alcuna strategia in questa strategia di eccezione, instraderà il messaggio alla strategia di eccezione predefinita. Non esegue mai alcuna attività di commit, rollback o consumo.

Strategia di eccezione di riferimento

Si riferisce a una strategia di eccezione comune definita in un file di configurazione separato. Nel caso in cui un messaggio generi un'eccezione, questa strategia di eccezione farà riferimento ai parametri di gestione degli errori definiti in una strategia globale di cattura, rollback o eccezione di scelta. Come la strategia di eccezione della scelta, non esegue mai alcuna attività di commit, rollback o consumo.

Comprendiamo che il test unitario è un metodo mediante il quale è possibile testare singole unità di codice sorgente per determinare se sono idonee all'uso o meno. I programmatori Java possono utilizzare il framework Junit per scrivere casi di test. Allo stesso modo, MuleSoft ha anche un framework chiamato MUnit che ci consente di scrivere casi di test automatizzati per le nostre API e integrazioni. È perfetto per l'ambiente di integrazione / distribuzione continua. Uno dei maggiori vantaggi del framework MUnit è che possiamo integrarlo con Maven e Surefire.

Caratteristiche di MUnit

Di seguito sono riportate alcune delle funzionalità molto utili del framework di test Mule MUnit:

• Nel framework MUnit, possiamo creare il nostro test Mule utilizzando il codice Mule e il codice Java.

• Possiamo progettare e testare le nostre app e API Mule, graficamente o in XML, all'interno di Anypoint Studio.

• MUnit ci consente di integrare facilmente i test nel processo CI / CD esistente.

• Fornisce test e rapporti di copertura generati automaticamente; quindi il lavoro manuale è minimo.

• Possiamo anche utilizzare DB / FTP / server di posta locali per rendere i test più portabili attraverso il processo CI.

• Ci consente di abilitare o disabilitare i test.

• Possiamo anche estendere il framework MUnit con plugin.

• Ci consente di verificare le chiamate del processore di messaggi.

• Con l'aiuto del framework di test MUnit, possiamo disabilitare i connettori degli endpoint e gli endpoint del flusso in entrata.

• Possiamo controllare i rapporti di errore con la traccia dello stack di Mule.

Ultima versione di Mule MUnit Testing Framework

MUnit 2.1.4 è l'ultima versione del framework di test Mule MUnit. Richiede i seguenti requisiti 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

È compatibile con Mule 4.1.4 e Anypoint Studio 7.3.0.

MUnit e Anypoint Studio

Come discusso, MUnit è completamente integrato in Anypoint studio e possiamo progettare e testare le nostre app e API Mule graficamente o in XML all'interno di Anypoint studio. In altre parole, possiamo utilizzare l'interfaccia grafica di Anypoint Studio per eseguire le seguenti operazioni:

• Per creare e progettare test MUnit
• Per eseguire i nostri test
• Per visualizzare i risultati dei test e il rapporto sulla copertura
• Per eseguire il debug dei test

Quindi, iniziamo a discutere ogni compito uno per uno.

Creazione e progettazione di test MUnit

Una volta avviato un nuovo progetto, verrà automaticamente aggiunta una nuova cartella, ovvero src/test/munital nostro progetto. Ad esempio, abbiamo avviato un nuovo progetto Mule, ovverotest_munit, puoi vedere nell'immagine qui sotto, aggiunge la cartella sopra menzionata sotto il nostro progetto.

Ora, una volta avviato un nuovo progetto, ci sono due modi di base per creare un nuovo test MUnit in Anypoint Studio:

• By Right-Clicking the Flow - In questo metodo, è necessario fare clic con il pulsante destro del mouse sul flusso specifico e selezionare MUnit dal menu a discesa.

• By Using the Wizard- In questo metodo, dobbiamo utilizzare la procedura guidata per creare un test. Ci consente di creare un test per qualsiasi flusso nell'area di lavoro.

Utilizzeremo il metodo "Fare clic con il pulsante destro del mouse sul flusso" per creare un test per un flusso specifico.

Innanzitutto, dobbiamo creare un flusso nell'area di lavoro come segue:

Ora, fai clic con il tasto destro su questo flusso e seleziona MUnit per creare un test per questo flusso, come mostrato di seguito -

Creerà una nuova suite di test denominata in base al file XML in cui risiede il flusso. In questo caso,test_munit-test-suite è il nome della nuova suite di test come mostrato di seguito -

Di seguito è riportato l'editor XML per il flusso di messaggi di cui sopra:

Ora possiamo aggiungere un file MUnit elaboratore di messaggi alla suite di test trascinandolo da Mule Palette.

Se vuoi creare un test tramite la procedura guidata, segui File → New → MUnit e ti porterà alla seguente suite di test MUnit:

Configurazione del test

In Mule 4, abbiamo due nuove sezioni, vale a dire MUnit e MUnit Tools, avendo collettivamente tutti i processori di messaggi MUnit. È possibile trascinare qualsiasi elaboratore di messaggi nell'area di test di MUnit. È mostrato nello screenshot qui sotto -

Ora, se desideri modificare la configurazione della tuta o del test in Anypoint Studio, devi seguire i passaggi seguenti:

Step 1

Vai al Package Explorer e fai clic con il pulsante destro del mouse sul file .xml fileper la tua suite o test. Quindi, seleziona il fileProperties.

Step 2

Ora, nella finestra Proprietà, dobbiamo fare clic Run/Debug SettingS. Dopo questo clicNew.

Step 3

Nell'ultimo passaggio, fare clic su MUnit sotto Select Configuration Type finestra, quindi fare clic su OK.

Esecuzione del test

Possiamo eseguire sia una suite di test che un test. Per prima cosa, vedremo come eseguire una suite di test.

Esecuzione di una suite di test

Per eseguire una suite di test, fare clic con il pulsante destro del mouse sulla parte vuota di Mule Canvas in cui risiede la suite di test. Si aprirà un menu a discesa. Ora fai clic sul fileRun MUnit suite come mostrato di seguito -

Successivamente, possiamo vedere l'output nella console.

Esecuzione di un test

Per eseguire un test specifico, è necessario selezionare il test specifico e fare clic con il pulsante destro del mouse su di esso. Otterremo lo stesso menu a discesa che abbiamo ottenuto durante l'esecuzione della suite di test. Ora fai clic sul fileRun MUnit Test opzione come mostrato di seguito -

Là dopo l'output può essere visto nella console.

Visualizzazione e analisi dei risultati del test

Anypoint studio visualizza il risultato del test MUnit nel file MUnit tabdel riquadro di esplorazione a sinistra. Puoi trovare i test riusciti in colore verde e i test falliti in rosso come mostrato di seguito:

Possiamo analizzare il risultato del nostro test visualizzando il rapporto sulla copertura. La caratteristica principale di Coverage Report è fornire una metrica su quanto un'applicazione Mule è stata eseguita con successo da una serie di test MUnit. La copertura di MUnit si basa fondamentalmente sulla quantità di processori di messaggi MUnit eseguiti. Il rapporto sulla copertura di MUnit fornisce la metrica per quanto segue:

• Copertura complessiva dell'applicazione
• Copertura delle risorse
• Copertura del flusso

Per ottenere il rapporto sulla copertura, dobbiamo fare clic su "Genera rapporto" nella scheda MUnit come mostrato di seguito -

Debug del test

Possiamo eseguire il debug di una suite di test oltre che di un test. Per prima cosa, vedremo come eseguire il debug di una suite di test.

Debug di una suite di test

Per eseguire il debug di una suite di test, fare clic con il pulsante destro del mouse sulla parte vuota di Mule Canvas in cui risiede la suite di test. Si aprirà un menu a discesa. Ora fai clic sul fileDebug MUnit Suite come mostrato nell'immagine qui sotto -

Quindi, possiamo vedere l'output nella console.

Debug di un test

Per eseguire il debug di un test specifico, è necessario selezionare il test specifico e fare clic con il pulsante destro del mouse su di esso. Otterremo lo stesso menu a discesa che abbiamo ottenuto durante il debug della suite di test. Ora fai clic sul fileDebug MUnit Testopzione. È mostrato nella schermata qui sotto.