Cette version s’attaque à trois obstacles qui ralentissent quotidiennement les développeurs Mule : un canevas (canvas) qui nécessite de multiples clics pour être compris, des exécutions locales limitées à un seul projet, et un débogueur (debugger) qui compliquait souvent la tâche au lieu de l’aider.
Disposition descriptive de l’interface utilisateur, exécution multi-applicative et améliorations du débogueur
La disposition descriptive de l’interface utilisateur (Descriptive UI Layout) attribue à chaque composant une description en langage clair afin que vous puissiez lire un flux comme une recette de cuisine. Les configurations d’exécution multi-applicatives (Multi-App Run Configurations) vous permettent de déployer plusieurs projets sur un seul runtime local grâce à une compétence IA qui les configure de manière conversationnelle. Enfin, une série de correctifs apportés au débogueur élimine la navigation vers le mauvais fichier, les charges utiles (payloads) illisibles et le manque de suivi de l’exécution sur le canevas.
Disposition descriptive de l’interface utilisateur : Lisez vos flux comme une recette
Le canevas traditionnel des flux Mule vous indique quels composants se trouvent dans un flux, mais pas ce qu’ils font. Vous finissez par cliquer sur chacun d’eux pour comprendre la logique – en particulier lorsque de nombreux nœuds affichent simplement « Transform Message ». La disposition descriptive de l’interface utilisateur remplace le modèle mental de graphe de nœuds par un canevas vertical de style recette. Chaque composant s’affiche sous forme de carte dotée d’une description lisible par l’homme et générée par IA, expliquant ce qu’il fait concrètement en termes métier.
Un processeur Transform Message ne se contente plus de dire « Transform Message » ; il indique désormais : « Stocke les champs d’opportunité principaux dans une variable pour un traitement ultérieur dans NetSuite. » Une référence de flux (Flow Reference) ne montre pas seulement le nom du flux cible ; elle explique ce qui se passe lorsque ce flux s’exécute.
Comment ça marche
MuleSoft Vibes utilise le type de composant, l’opération, les valeurs de configuration et le contexte du flux de données environnant pour générer des descriptions. Pour les connecteurs, il lit l’opération et le type d’objet. Pour les transformations DataWeave, il inspecte les schémas d’entrée/sortie. Pour les routeurs Choice, il traduit les conditions en règles métier en langage clair.
La disposition elle-même suit un flux vertical de haut en bas. Les séquences linéaires s’affichent sous forme de liste d’étapes. Les branchements (Choice, Scatter-Gather) apparaissent comme des sous-recettes indentées sous l’étape parente. Les gestionnaires d’erreurs (error handlers) s’affichent en ligne avec un arrière-plan distinct. Les sous-flux (sub-flows) sont réductibles.
Le compromis : La disposition descriptive de l’interface utilisateur privilégie la lisibilité par rapport à la densité. Si vous avez un flux contenant plus de 30 processeurs et que vous préférez visualiser l’intégralité de la topologie d’un seul coup d’œil, la disposition classique du canevas reste disponible. L’interface descriptive est idéale pour les flux où la compréhension de ce qui se passe est plus importante que la vue d’ensemble instantanée.
Configurations d’exécution multi-applicatives : Exécutez votre stack orientée API localement
Les projets Mule ne fonctionnent pas de manière isolée. Les API appellent des bases de données, les événements s’enchaînent entre les applications et les agents invoquent des outils MCP. Mais jusqu’à présent, tester ces interactions localement impliquait de jongler avec des runtimes distincts, des terminaux séparés et une coordination manuelle entre chacun d’eux. Prenons l’exemple courant de la connectivité orientée API (API-led connectivity) : vos applications experience-api, process-api et system-api doivent toutes s’exécuter simultanément pour valider une requête de bout en bout. Cela représente trois runtimes, trois ensembles de journaux (logs) et d’innombrables changements de contexte.
Cette version introduit les configurations d’exécution (Run Configurations) dans ACB : des configurations nommées et réutilisables qui définissent quels projets déployer ensemble, quel runtime Mule et quelle version de JDK utiliser, ainsi que les arguments de programme/VM à passer.
Ce qu’une configuration d’exécution définit :
- Projets à exécuter : sélectionnez plusieurs projets Mule de votre espace de travail (workspace)
- Mode Débogage ou Exécution (Debug or Run Mode)
- Version du runtime Mule : menu déroulant des runtimes installés localement (ex : 4.6.0)
- Version de Java : alignée sur les exigences du projet
- Arguments de programme et de VM : champs distincts avec des valeurs par défaut extraites de vos paramètres existants
Modèle d’exécution : Lorsque vous lancez une configuration multi-projet, ACB package chaque projet via Maven, copie les fichiers JAR dans le dossier apps/ du runtime et démarre une instance unique de runtime partagé qui déploie toutes les applications au démarrage. Un seul runtime, plusieurs applications, un seul clic.
La compétence (skill) Vibes : Plutôt que de cliquer dans un formulaire de l’interface utilisateur, vous pouvez créer et gérer vos configurations d’exécution de manière conversationnelle via le Dev Agent. Dites simplement « Crée une configuration de débogage pour mule-ref-db-sapi et customer-api sur le runtime 4.6.0 » et l’agent génère la configuration, la stocke dans votre fichier .code-workspace (multi-racine) ou launch.json (projet unique), et propose de l’exécuter immédiatement.
Les configurations sont également disponibles via le menu déroulant « Run and Debug » de VS Code et le menu contextuel de l’Explorateur sous la section « Mule ».
Améliorations du débogueur pour un dépannage fiable
Le débogueur d’ACB possède la bonne architecture : protocole DAP, proxy transparent, intégration standard dans VS Code. Cette version améliore l’affichage des données, la navigation et l’intégration avec le canevas.
Affichage des données
Le panneau des variables (Variables) affiche désormais ce que vous vous attendez à voir, et non ce que la JVM choisit de sérialiser. Les charges utiles (payloads) JSON se copient sous forme de JSON valide que vous pouvez coller directement dans Postman sans avoir à supprimer manuellement les séquences d’échappement. Les types MIME non-Java (application/json, text/xml, text/plain) s’affichent sous forme de texte lisible plutôt que sous forme de tableaux d’octets bruts (byte arrays).
En cas de pause au sein d’un gestionnaire d’erreurs, un espace dédié aux erreurs (error scope) fait remonter le type d’exception, le message et la cause au premier niveau – plus besoin de fouiller dans des nœuds Java imbriqués pour comprendre l’origine de la panne. Les valeurs des variables sont modifiables en cours de session (double-clic, saisie, reprise), et les messages d’exception sur les points d’arrêt d’erreur (error breakpoints) sont désormais immédiatement lisibles sans avoir à les développer. Le système évalue non seulement les payloads et les variables, mais il peut également évaluer les expressions DataWeave. Il s’agit d’une capacité essentielle que les développeurs peuvent exploiter pour déboguer leurs expressions écrites en DataWeave.
Navigation
Le débogage de projets avec des configurations multiples fonctionne désormais correctement. L’activation d’un point d’arrêt dans config-b.xml ouvre bien config-b.xml – et non le fichier qui se trouvait être actif par hasard. Le passage à l’étape suivante dans un <flow-ref> navigue vers le fichier de configuration qui déclare le flux référencé, et non vers un fichier aléatoire du projet. Les commandes Step-over, Step-in et Step-out maintiennent toutes le focus sur le fichier contenant le processeur actif. Les points d’arrêt situés dans des fichiers de configuration sous des sous-répertoires (par exemple, src/main/mule/subdir/) ne manquent plus de se déclencher en silence.
Intégration au canevas
Le canevas participe désormais activement à la session de débogage. Lorsque l’exécution est suspendue, le processeur actif est mis en évidence par un contour en pointillés distinct. Vous pouvez voir où vous en êtes sans avoir à faire de correspondance croisée avec les numéros de ligne. Si le composant mis en pause se trouve en dehors de l’écran, la zone de visualisation (viewport) se déplace automatiquement pour le faire apparaître. Les deux indicateurs s’effacent lors de la reprise ou de la fin de la session. Plus besoin de chercher dans un grand flux pour trouver l’endroit où l’exécution s’est arrêtée.
Prise en main des dernières mises à jour d’ACB
Téléchargez dès aujourd’hui votre dernier pack d’extensions ACB (ACB Extension pack) depuis la marketplace de Visual Studio. N’hésitez pas à regarder la vidéo de démonstration pour examiner de plus près tout ce qui a été présenté ci-dessus.