Ci concentriamo in questo ultimo post della serie Benefici di Mule 4 sulla parte di tooling e di strumenti di sviluppo. Assieme al runtime Mule 4, MuleSoft ha rilasciato una nuova versione dello strumento di sviluppo Anypoint Studio 7.
Supporto per RAML e OAS 3.0.
Prima di tutto, il supporto per il disegno di API specifications in RAML e OpenAPI/Swagger (OAS). Con Studio 7, possiamo scaricare direttamente da Exchange le nostre API Specifications sia in RAML che in OAS, le possiamo modificare in Studio e possiamo mantenere le modifiche sincronizzate con la versione in Exchange. Inoltre, dall'ultimo release di Febbraio, Studio 7.8, è anche possibile fare lo scaffolding e creare automaticamente i flussi delle operazioni REST a partire dalla Specification sia in RAML che in OAS. Inoltre, l'utilizzo di APIkit router consente la validazione delle chiamate entrante.
MuleSoft ha investito tanto nell'interoperabilità di RAML e OAS per garantire che sia possibile utilizzare qualsiasi dei due tipi di Specification nella piattaforma in tutto il ciclo di vita dell'applicazione, non solo nel disegno della Specification ma anche nella parte di deployment e management. Vi lascio in questo link più informazione riguardo il supporto per OAS 3.0.
Dataweave 2.0
Dataweave è il linguaggio di trasformazione di Mule. Ed è L'UNICO linguaggio utilizzato in Mule 4. Nella versione di Mule 3 era un pò confuso creare queste trasformazioni, poichè c’erano due tipi di trasformazioni. C’era, da una parte il Mule Expression Language (MEL) e, dall'altra, il Dataweave 1.0. Mule Expressioon Language ci costringeva a convertire il payload JSON o XML in oggetti Java. Adesso, con Dataweave 2.0, c’è solo una sintassi di trasformazione, e sopratutto si può fare graficamente. Fare le mappature tra i campi in formati diversi diventa un'esercizio di drag and drop nella maggior parte dei casi con Studio 7. E' anche possibile utilizzare delle espressioni Dataweave su ogni componente del flusso.
Per ultimo, possiamo anche definire e riutilizzare scripts in Dataweave nella nostra applicazione per le trasformazioni di dati più complesse. In questo link vi lascio informazione più in dettaglio sulle novità di Dataweave in Studio 7.8
Error Handling
La gestione degli errori si è semplificata tanto con Mule 4 e Studio 7. Ora, anzichè gestire le eccezioni Java direttamente, esiste proprio il concetto di errore Mule, il che vuol dire che possiamo definire i nostri scopes di try and catch, catturare gli errori e stabilire la nostra strategia di gestione di questi errori.
Se vuoi approfondire su come fare una corretta gestione degli errori su Mule 4 ti consiglio di seguire questa serie di 4 blog posts:
MUnit è l'applicazione del framework di testing per Mule 4 che ci consente di creare tests per le nostre applicazioni e APIs di Mule. Con MUnit possiamo:
- Creare tests per Mule apps dentro dello stesso Studio 7.
- Avere reports di test coverage
- Verificare chiamate di Message Processors
- Avere Mocks per Message Processors
- Avere Mocks per i nostri outbound endpoints
- Abilitare/disabilitare endpoints
- Fare il debug dei nostri tests
- Creare delle assertions per verificare i payloads
Nell'area di testing, MUnit ha avuto anche dei profondi miglioramenti, sopratutto con la nuova funzionalità di Test Recording. Test Recording ci consente di fare la creazione di Unit tests di forma automatica, catturando dati e creando il test a partire solo della esecuzione di un flusso in real time, senza dover scrivere questo test manualmente. Questo significa, di conseguenza, un'aumento nella velocità di sviluppo e, sopratutto, una migliore user experience per i nostri developers. Ti lascio qua un tutorial di MUnit Test Recorder per esplorare questa nuova funzionalità.
Connettori
Per ultimo, Mule 4 e Studio 7 portano anche dei miglioramenti nei connettori. Da una parte, il numero di connettori che supporta Mule 4 e maggiore poichè lo sviluppo di ogni nuovo connettore si fa solo per la versione 4. Dovete considerare anche che le updates dei connettori esistenti si faranno esclusivamente per la versione 4, quindi un'altro motivo per migrare a Mule 4. Alcuni esempi dei nuovi MuleSoft Certified Connectors per Mule 4 sono:
- SAP BusinessObjects BI Connector
- Docker Connector
- Microsoft Office 365 Connector
- Google DFP Connector
- Edifecs XEngine Server Connector
- Zoho Books Connector
- Amazon Dynamo DB Connector
- Amazon SQS and SNS Connector
Dall’altra parte, esistono con Mule 4 e Studio 7 nuovi triggers per alcuni connettori come Salesforce, FTP o il connettore di database. Questo vuol dire che non dobbiamo più creare la logica nei nostri flussi per controllare le modifiche su questi sistemi o implementare un polling continuo. Con questi triggers il runtime rimane ascoltando queste modifiche e sparando i flussi quando ci sono nuovi dati o modifiche.