Développement Anypoint Platform : les fondamentaux (Course #dev-fundamentals)
For développeurs juniors, nouvelles recrues.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de concevoir, tester et déployer une API REST Mule 4 spec-first — erreurs typées, suite MUnit verte, propriétés par environnement — afin de tenir la cible p95 < 300 ms sur CloudHub.
Cas fil rouge
Lumen Retail, enseigne alimentaire omni-canal, pousse encore ses commandes e-commerce vers l'ERP SAP en lots CSV nocturnes, pendant que les magasins interrogent un service SOAP vieillissant pour le stock. Le click-and-collect annoncé en 15 minutes impose des API temps réel : cible p95 < 300 ms sur la disponibilité, SLA 99,9 % en pointe, zéro commande perdue. Vous bâtissez ce chemin API-led module après module.
Programme chaque ligne est quelque chose que vous faites
8 modules · 25 sujets · dans l'ordre du cours
-
Module 1
L'API-led avant la première ligne
Objectif. Situer chaque flow à construire dans le paysage trois couches de Lumen avant d'écrire la moindre ligne de code.
- Tracer une commande click-and-collect à travers les API Experience → Process → System, chaque saut chronométré face au p95 < 300 ms
- Assigner une responsabilité par couche : Experience façonne les canaux, Process orchestre, System encapsule caisse et stock
- Chiffrer l'anti-pattern point-à-point : compter les consommateurs par interface, mesurer l'impact d'un changement de schéma
-
Module 2
Événements, flows et connecteurs
Objectif. Construire une application de prise de commande fonctionnelle dans Anypoint Studio 7.x/Mule 4.x, assemblée en flows et subflows démontrables de bout en bout.
- Configurer un workspace Anypoint Studio 7.x et générer un projet Mule 4.x avec son pom.xml Maven
- Composer des événements Mule 4.x à travers flows et subflows : payload, attributes, variables vs record variables, flow-ref
- Câbler les connecteurs vers les systèmes : HTTP Listener sur le port 8081, Database connector en JDBC, polling de fichiers
- Versionner le projet sur Git dès la première heure : commit initial, branche par user story, PR relues avant fusion
-
Module 3
Mapping DataWeave 2.x : l'essentiel
Objectif. Construire des mappings DataWeave 2.x typés par métadonnées qui transforment le JSON de commande Lumen en enregistrement plat prêt pour l'ERP.
- Écrire des mappings DataWeave 2.x typés par métadonnées (input/output headers), avec filtrage, partition et réduction sur 10 k enregistrements
- Exploiter le DataSense : charger des échantillons JSON/CSV comme métadonnées d'entrée et prévisualiser chaque transform avant déploiement
- Factoriser la logique récurrente en fonctions et en module .dwl personnalisé réutilisé entre flows
-
Module 4
Le contrat RAML 1.0 d'abord
Objectif. Modéliser l'API de disponibilité en RAML 1.0 dans Design Center et en dériver des flows APIkit exécutables depuis la spec publiée.
- Modéliser ressources, méthodes, resourceTypes, traits et exemples de l'API de stock en RAML 1.0
- Publier la spec sur Anypoint Exchange et générer dans Studio les flows APIkit (router + handlers)
- Boucler dans Design Center : édition, mocking service, retours des consommateurs, versionnage de la spec
-
Module 5
Spec-first avec OAS 3.x
Objectif. Générer une implémentation directement depuis un document OAS 3.x et arbitrer RAML vs OAS pour chaque nouvelle API Lumen.
- Importer un document OAS 3.x et convertir RAML 1.0 <-> OAS sans perdre exemples ni security schemes
- Générer les flows APIkit depuis l'OAS pour lier chaque opération à son handler flow dédié
- Naviguer les écarts 2.0 vs 3.x : requestBody/responses, components, servers, types nullables, callbacks
-
Module 6
Erreurs, logs et MUnit vert
Objectif. Durcir l'API de commande avec une stratégie d'erreurs typée et livrer une suite MUnit verte à 80 % de couverture (cible).
- Architecturer la gestion d'erreurs : on-error-continue vs on-error-propagate, types raise-error personnalisés, handler global
- Corréler les requêtes via une variable correlation-ID et des loggers structurés lisibles dans Runtime Manager
- Couvrir chaque branche avec MUnit : mock-when, spy-verify, assert-equals sur chemins nominaux et cas d'erreur
-
Module 7
Livrer : déploiements CloudHub
Objectif. Packager l'application avec Maven et opérer son premier déploiement CloudHub avec propriétés par environnement.
- Packager avec Maven et déployer sur un worker CloudHub 1 vCore, en lisant l'impact vCore-hour
- Externaliser les propriétés par environnement avec placeholders et secure properties chiffrées
- Vérifier le déploiement réel : smoke tests des endpoints, dashboards Runtime Manager, rollback si régression
-
Module 8
Projet fil rouge : click-and-collect de bout en bout
Objectif. Livrer la chaîne Lumen complète — contrat, implémentation, suite MUnit verte, API déployée — dans le budget de latence.
- Concevoir le contrat RAML 1.0 des commandes, le valider via le mocking service, puis générer les handler flows APIkit
- Orchestrer sur des stubs System : erreurs typées, correlationId bout en bout, mappings streamés au heap stable
- Verrouiller la mise en production : couverture MUnit ≥ 80 % routes d'erreur comprises, déploiement CloudHub, smoke test sous p95 300 ms
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Présentation d'Anypoint ExchangeDoc MuleSoft
Module 2
- Structure d'un événement MuleDoc MuleSoft
Module 3
- Scripts DataWeaveDoc MuleSoft
Module 4
- Créer et importer des spécifications d'APIDoc MuleSoft
Module 5
- Spécification OpenAPI v3.1.0Spécification
Module 6
- Gestionnaires d'erreursDoc MuleSoft
Module 7
- Déployer des applications sur CloudHub 2.0Doc MuleSoft
Module 8
- Présentation de MUnitDoc MuleSoft