Comment transformer vos intégrations en levier d’innovation avec MuleSoft ?

Un projet MuleSoft repose sur des principes d’architecture robustes, assurant une solution évolutive, extensible et contrôlée de manière intégrale. Voici les principes essentiels à connaître.

Les composants essentiels de l’Anypoint Platform 

Anypoint Platform rassemble tous les outils nécessaires pour la conception, le déploiement, la surveillance et la sécurisation des intégrations.

Anypoint Design Center

• Studio : Environnement de développement intégré (IDE). Nous réalisons les intégrations ici, nous paramétrons les flux et nous effectuons des tests en local. Interface utilisateur, avec accès au code source intégral.

• API Designer : Outil d’édition pour les spécifications API. Nous utilisons RAML ou OAS, deux formats standards qui décrivent comment l’API fonctionne : ses ressources, ses méthodes, ses paramètres. La documentation est générée automatiquement au fur et à mesure, ce qui facilite la collaboration entre équipes.

• Connector DevKit : Atelier de création de connecteurs sur mesure. Lorsqu’il y a une lacune dans le standard, DevKit fournit un complément.

Anypoint Exchange

Le catalogue centralisé d’actifs de réutilisation (connecteurs préconstruits, fragments d’API, etc.). Les API y sont publiées, documentées, testées. Il encourage la collaboration et la réutilisabilité des composants au sein de l’organisation MuleSoft et de la communauté, réduisant l’effort de développement.

Anypoint Management Center

• API Manager : La console de gestion des APIs, fournissant une maîtrise totale sur leur cycle de vie. Il est possible d’y déployer des API, de mettre en œuvre des politiques de sécurité (ex : OAuth2, limitation de taux), de gérer les accès (clés/contrats) et d’effectuer des analyses de performance en temps réel. Pour garantir la gouvernance des services exposés et maintenir un haut niveau de qualité, l’API Manager s’avère être un outil indispensable.

• Runtime Manager : L’outil pour déployer et orchestrer les applications Mule. Il facilite la gestion des déploiements dans le cloud (CloudHub) ou on-premise (Mule Runtime standalone ou Runtime Fabric), la supervision de l’état des applications et permet de simplifier l’augmentation de capacité en ajoutant facilement de nouveaux workers ou nœuds Mule.

Mule Runtime Engine

Le moteur central qui fait tourner les applications et les flux d’intégration. Il traite les événements, route les messages et orchestre les interactions entre les différents systèmes. Avec DataWeave (le langage de transformation de données de MuleSoft), il transforme les données et applique la logique métier définie dans Studio. Il gère les erreurs, suit les performances et assure la résilience des processus. Déployable sur site, dans le cloud ou via Runtime Fabric, il reste flexible et extensible.

Anypoint Connectors

Passerelles prêtes à l’emploi vers des systèmes tels que SAP, Salesforce, AWS ou des bases de données. Ils sont conformes aux normes, certifiés et entretenus de manière régulière. L’avantage : moins de code à écrire, des intégrations plus rapides et plus fiables.

Runtime Services

C’est la couche qui travaille en coulisse pour que tout tourne bien. Elle gère les logs, surveille les applications et applique des règles de sécurité. On ne la voit pas directement, mais sans elle, aucune exécution ne serait stable ni fiable.

Hybrid Cloud

L’Hybrid Cloud dans Anypoint Platform offre une flexibilité totale de déploiement. Les applications Mule peuvent tourner sur site (on-premise), dans un cloud public (CloudHub, AWS, Azure) ou dans un cloud privé via Runtime Fabric. Cette approche hybride permet de rapprocher les traitements des systèmes internes tout en exploitant l’élasticité du cloud.

Les outils de gestion et les règles de sécurité restent les mêmes, quel que soit l’endroit où tournent les applications. Techniquement, MuleSoft garde le pilotage dans son cloud, mais l’entreprise choisit librement où exécuter ses flux. En résumé, la gouvernance reste simple et centralisée, même si l’exécution est répartie.

MuleSoft promeut une approche API-led Connectivity, c’est-à-dire une architecture multicouches organisée autour d’APIs réutilisables répondant chacune à un rôle bien défini. Elle se décline en trois types d’API :

System APIs

Les System APIs exposent de manière standardisée les données et les fonctions des applications existantes, comme un ERP, un CRM ou une base de données. Elles permettent d’accéder à l’information sans modifier le fonctionnement de ces systèmes, et rendent la donnée disponible pour d’autres usages.

Process APIs

Les Process APIs récupèrent et combinent les données de plusieurs System APIs, puis appliquent la logique métier nécessaire. Elles jouent le rôle d’orchestrateurs et de transformateurs, afin de fournir une vue consolidée adaptée à un besoin précis.

Experience APIs

Les Experience APIs sont conçues pour un canal ou une expérience spécifique. Elles consomment les Process APIs sous-jacentes et formatent les données selon les besoins d’une audience particulière (application mobile, portail web, application interne, etc.)

Cette approche de stratification facilite la séparation des systèmes sources des expériences utilisateurs. Effectivement, chaque couche peut progresser de manière totalement autonome : les System APIs assurent un accès stable aux systèmes legacy, les Process APIs regroupent des processus métiers réutilisables, et les Experience APIs fournissent la souplesse requise pour ajuster ou concevoir de nouveaux canaux numériques. En agissant ainsi, cela accélère le développement (je réutilise au lieu de recréer), réduit les coûts de maintenance et offre au SI un temps précieux pour répondre aux changements.

Pour illustrer concrètement ces principes, prenons le cas d’une banque qui a utilisé MuleSoft pour intégrer son système bancaire central (core banking) avec Salesforce. L’objectif était de synchroniser en quasi-temps réel les données client et comptes bancaires du système cœur vers Salesforce, afin d’offrir aux banquiers une vision 360° actualisée.

L’architecture mise en place

• Plusieurs System APIs pour exposer les données du core banking (clients, comptes, transactions), accéder à certains référentiels techniques et tables métiers, récupérer ou déposer des documents liés aux dossiers clients (contrats, pièces KYC, etc.)

• Au-dessus, plusieurs Process APIs orchestrent ces données. Certaines se concentrent sur l’agrégation des informations clients, d’autres sur l’accès et la normalisation des documents. Chaque service encapsule sa logique propre, mais tous assurent un rôle commun : transformer, enrichir et orchestrer les données en sortie des System APIs pour qu’elles soient exploitables par les couches supérieures.

• Enfin, une Experience API spécifique à Salesforce a été exposée : Salesforce vient la consommer pour, par exemple, afficher dans des composants Lightning les données consolidées du client (avoirs, dernières transactions, alertes) ou initier des mises à jour vers le core banking.

Les défis

• Sécurité : La connexion entre systèmes devait être totalement sécurisée : VPN pour le tunnel privé, espaces isolés pour limiter l’exposition, OAuth2 pour l’authentification. Toutes les données échangées étaient systématiquement chiffrées.

• Transformation : Les formats de données n’étaient pas homogènes : XML côté systèmes historiques, JSON côté SaaS comme Salesforce. DataWeave a permis de faire le mapping, les conversions et d’intégrer la logique métier dans les flux.

• SLA : L’intégration devait rester fiable même en cas de forte charge. Grâce à CloudHub, la répartition de charge entre plusieurs workers d’une même application est gérée automatiquement par la plateforme, ce qui garantit disponibilité et continuité de service sans configuration supplémentaire.

• Erreurs métier : Certaines règles pouvaient bloquer un flux. Les exceptions étaient gérées finement, avec des retries automatiques. Pour les cas persistants, une notification était envoyée directement à l’équipe support.

• Volumétrie : Plusieurs batchs ont été nécessaires pour migrer l’ensemble de la base existante. Les flux événementiels assurent ensuite la synchronisation au quotidien.

Les résultats

L’intégration utilisant MuleSoft est une réussite. Aujourd’hui, Salesforce consomme en quasi-temps réel les données du core bancaire : les banquiers ont ainsi une vision client unifiée et à jour, comprenant même les données de comptes bancaires, sans qu’il soit nécessaire de passer d’une application à une autre. Cela a considérablement amélioré la réactivité et la qualité du service rendu au client (conseils mieux personnalisés, prise en charge des demandes plus rapide).

Sur le plan de la technique, la Banque a su s’appuyer sur MuleSoft pour bâtir une architecture d’intégration robuste et évolutive. Des APIs réutilisables ont été exposées derrière les contrats d’API et pourront alimenter d’autres chantiers, contribuant ainsi à accélérer la dynamique d’innovation. La fiabilité dans le temps de la solution a été démontrée : depuis la mise en production, aucun incident majeur n’est venu perturber l’exploitation au quotidien, et le système a su encaisser plusieurs pics de charge.

En dernier lieu, cette victoire a eu un relai en interne : constatant la qualité de service et la rapidité accessibles grâce à l’intégration MuleSoft, les équipes métiers et IT collaborent désormais pour étendre la plateforme à d’autres couches du SI.

En conclusion, ce chantier d’intégration a permis à la Banque de rénover son SI, en associant harmonieusement son legacy et son digital, et a confirmé l’option de l’architecture MuleSoft sur des systèmes financiers complexes