Développement Mule 4 avancé (Course #advanced-mule4)
For développeurs.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de concevoir, profiler et fiabiliser des applications Mule 4 à haut débit — DataWeave en streaming, batch à watermarks, retries en couches — afin de tenir 2 000 msg/s avec un p99 sous 500 ms.
Cas fil rouge
Meridian Bank ouvre son cœur bancaire aux fintechs : les API d'initiation de paiement exigent un p99 < 500 ms, des lots de règlement à 2 000 TPS et zéro double débit — chaque appel porte une clé d'idempotence. Les adaptateurs COBOL patrimoniaux lâchent sous charge, ce qui dicte les patterns de résilience. Chaque module durcit une couche de ce patrimoine open banking.
Programme chaque ligne est quelque chose que vous faites
8 modules · 24 sujets · dans l'ordre du cours
-
Module 1
DataWeave à l'échelle mémoire
Objectif. Refactorer le mapper de règlement en fonctions et modules DataWeave 2.x en streaming maintenant le heap sous 512 Mo (cible).
- Écrire fonctions et modules DataWeave 2.x réutilisables, éprouvés hors Mule avant intégration aux flows
- Streamer les payloads volumineux au lieu de les bufferiser, mémoire plate prouvée sur un fichier ISO 20022 de 50 Mo
- Réduire la pression heap : comparer mapping streamé vs bufferisé dans VisualVM (cible : heap < 512 Mo)
-
Module 2
Batch, async et cache : les leviers
Objectif. Construire un job Batch à watermarks réglant 1 M de transactions par nuit, plus des voies async VM/Anypoint MQ et des cache scopes dimensionnés.
- Assembler des jobs Batch : scope, steps, aggregate-report, on-complete, watermarks persistés en Object Store v2
- Découpler les systèmes lents : files VM pour l'async interne, Anypoint MQ pour une livraison durable multi-workers
- Dimensionner les cache scopes (TTL, clé) autour du référentiel (cible : 60 % d'appels aval en moins)
-
Module 3
Connecteurs custom et Java
Objectif. Arbitrer quand un connecteur SDK custom se justifie, puis encapsuler la bibliothèque de signature HSM de Meridian en un connecteur opérationnel.
- Arbitrer build vs reuse : connecteur SDK custom contre wrapper HTTP contre module de scripting, coûts de maintenance compris
- Générer un connecteur Mule SDK sur Java 17 : @Operations, @Configuration, gestion des @Connection
- Invoquer du Java depuis les flows : module Java, méthodes statiques, payloads POJO, pièges de classloader
-
Module 4
Du profiling au débit
Objectif. Diagnostiquer le goulot d'étranglement des paiements avec JFR et VisualVM, puis retuner les workers vers 2 000 msg/s sous 70 % de CPU (cible).
- Profiler avec Java Flight Recorder et VisualVM : pools bloqués, pauses GC, coût du logging
- Alléger les chemins de production : readers en streaming, politique d'éviction Object Store, marge de heap
- Tuner le débit : max-concurrency, dimensionnement workers/vCores sur CloudHub et RTF, profondeur de files
-
Module 5
La résilience par conception
Objectif. Concevoir une topologie de retry — until-successful à backoff exponentiel + jitter, circuit breaker, DLQ — qui encaisse les pannes du cœur bancaire.
- Modéliser types et propagation d'erreurs : erreurs CUSTOM, sémantique de rethrow, handlers globaux vs locaux
- Envelopper les appels COBOL capricieux dans until-successful à backoff exponentiel + jitter et reconnexion configurée
- Basculer les messages toxiques vers une DLQ Anypoint MQ et les rejouer sans doublon grâce au magasin de clés d'idempotence
-
Module 6
MUnit au-delà du happy path
Objectif. Produire une suite MUnit simulant tous les systèmes aval, éprouvant les chemins d'erreur, et bloquant le build sous 85 % de couverture (cible).
- Simuler les systèmes aval : mock-when avec réponses générées en DataWeave, spy-verify sur les appels sortants
- Fixer des gates de couverture utiles (cible : 85 %) et brancher les rapports dans le build Maven comme garde dure
- Injecter timeouts et HTTP 500 simulés pour éprouver backoff, circuit breaker et DLQ en CI
-
Module 7
Temps réel à grande échelle
Objectif. Concevoir un canal WebSocket diffusant les alertes fraude à 5 000 clients partenaires simultanés, réparti sur plusieurs workers.
- Opérer le connecteur WebSocket : sockets serveur vs client, cycle de session, heartbeat et reconnexion
- Diffuser en pub/sub : pont entre souscriptions Anypoint MQ d'alertes fraude et sessions WebSocket connectées
- Planifier le scale-out : sessions collantes sur 2+ workers CloudHub/RTF et coût des connexions stateful
-
Module 8
La cohérence sous panne
Objectif. Garantir un mouvement de fonds exactly-once entre le grand livre Meridian et les rails de paiement, panne middleware comprise.
- Délimiter scopes transactionnels locaux vs XA sur Database et JMS, et arbitrer quand le two-phase commit mérite sa latence
- Régler les ack modes Anypoint MQ pour que toute réémission frappe le magasin de clés d'idempotence plutôt que de re-débiter un client
- Prouver la reprise : tuer un worker en plein batch, rejouer depuis la DLQ, réconcilier zéro doublon et zéro perte au grand livre
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Le streaming dans les applications MuleDoc MuleSoft
Module 2
- Traitement par lots (Batch)Doc MuleSoft
Module 3
- Présentation des SDK MuleDoc MuleSoft
Module 4
- Back-pressure et MaxConcurrencyDoc MuleSoft
Module 5
- Scope Until SuccessfulDoc MuleSoft
Module 6
- Couverture MUnitDoc MuleSoft
Module 7
- Connecteur WebSocketsDoc MuleSoft
Module 8
- Gestion des transactionsDoc MuleSoft