Architecture 3 days

Architecture Solution MuleSoft : les fondamentaux (Course #architecture-fundamentals)

For architectes solution (découvrant MuleSoft).

S'inscrire à ce cours Toutes les formations
Réf#architecture-fundamentals
Durée3 jours
Formats4 modalités
Certif—
PrérequisAucun

À la fin, vous saurez

À l'issue de cette formation, vous serez capable de concevoir une architecture de référence API-led complète — couches, topologie, sécurité, dimensionnement — afin de tenir les cibles de p99, de disponibilité et de budget dès la V1.

Cas fil rouge

Terravia Group, fabricant d'équipements industriels implanté dans 14 pays, exploite 320 flux point-à-point entre SAP ECC, un WMS et de l'EDI historique ; la consolidation mondiale de l'ERP démarre dans 12 mois. La direction exige 99,9 % de disponibilité sur les flux commandes, un p99 < 500 ms et un budget runtime plafonné à 24 vCores en année 1. L'architecture doit tenir la migration comme l'audit.

Programme chaque ligne est quelque chose que vous faites

6 modules · 18 sujets · dans l'ordre du cours

  1. Module 1

    Des frontières avant les schémas

    Objectif. Concevoir la découpe System/Process/Experience du SI Terravia et poser des principes opposables en revue d'architecture.

    • Appliquer les trois couches à la chaîne SAP ECC → orchestration commandes → portail partenaires, en nommant la responsabilité unique de chaque API
    • Répartir les rôles : API System = wrappers BAPI/IDoc SAP, API Process = orchestration, API Experience = payloads UI
    • Poser des principes qui mesurent la réutilisation : schémas canoniques en fragments RAML 1.0, une seule source de vérité par objet maître
  2. Module 2

    Hybride, cloud ou on-premise ?

    Objectif. Évaluer les compromis hybride/cloud/on-premise et arrêter une topologie réseau joignant sûrement les systèmes d'atelier.

    • Comparer hybride, full-cloud et on-premise sur latence, résidence des données et maturité ops, dans une matrice pondérée, p. ex. résidence à 40 %
    • Accorder le pattern aux contraintes : VPN site-à-site ou interconnexion dédiée, IP egress statiques pour les allow-lists partenaires
    • Esquisser la topologie de bout en bout sur un schéma unique : Anypoint VPC et CIDR (p. ex. /24), VPN vers l'on-premise, load balancers
  3. Module 3

    Un outil, une responsabilité

    Objectif. Relier chaque composant Anypoint à sa responsabilité et trancher la propriété outillage entre équipe plateforme et équipes produit.

    • Relier Runtime Manager (opérer), API Manager (gouverner), Exchange (réutiliser), Design Center (concevoir) aux étapes du cycle de vie et au RACI
    • Partager la propriété : l'équipe plateforme administre policies et environnements d'API Manager, les squads possèdent leurs projets Design Center
    • Suivre une intégration spec-first : RAML 1.0 dans Design Center → mocking service → scaffolding Studio → déploiement via Runtime Manager
  4. Module 4

    Défense en profondeur, par politiques

    Objectif. Sécuriser chaque point d'exposition par des politiques appliquées à l'edge et choisir le flux OAuth 2.0 adapté à chaque profil de consommateur.

    • Placer chaque contrôle à sa place : terminaison TLS 1.3 à l'edge, politiques client-enforcement et throttling dans API Manager
    • Choisir le flux OAuth 2.0 par scénario : client credentials pour le M2M, authorization code + PKCE pour mobile et SPA
    • Planifier le chiffrement au repos et en transit : JCE/PGP pour les payloads sensibles, secure properties pour les secrets, rotation à 90 jours
  5. Module 5

    Le bon runtime, à la bonne taille

    Objectif. Dimensionner workers, clusters et mode d'hébergement pour tenir 99,9 % de disponibilité dans une enveloppe de 24 vCores année 1, preuves à l'appui.

    • Comparer CloudHub, Runtime Fabric et hébergement client sur finesse de contrôle, temps de démarrage et coût d'infrastructure par vCore
    • Dimensionner selon la charge : 2 workers de 0,5 vCore par API critique sur CloudHub, autoscaling RTF à 70 % CPU, Anypoint MQ absorbant les pointes
    • Passer en revue les scénarios de panne : perte de zone à deux workers, retries en backoff exponentiel + jitter, DLQ Anypoint MQ, RTO < 15 min
  6. Module 6

    Revue d'architecture : défendre la cible

    Objectif. Défendre l'architecture cible Terravia devant un jury qui note chaque compromis à l'aune des NFR.

    • Présenter la topologie trois couches face aux chiffres de Terravia : p99 < 500 ms, 99,9 % de disponibilité, plafond 24 vCores année 1
    • Répondre aux objections en direct — runtimes partagés vs dédiés, dimensionnement VPC, construire vs réutiliser — avec des chiffres
    • Convertir les constats de revue en backlog priorisé, noté par risque retiré par jour-d'architecte investi

Références & documentation officielle chaque affirmation ci-dessus a une source

Module 1

Module 2

Module 3

Module 4

Module 5

Dans la filière Architecture

#advanced-architecture-c4e · Architecture d'intégration avancée & animation du C4E#eda-mq · Architecture événementielle avec Anypoint MQ#cloud-native-gateway · Praticien des gateways API cloud-native#b2b-edi · Intégration B2B avec Anypoint Partner Manager & X12 EDI#omni-gateway · Omni Gateway & gestion des API multi-protocoles#api-governance · Gouvernance des API à l'échelle & API Experience Hub#ai-capabilities · Capacités IA de MuleSoft#agent-fabric · Agent Fabric et gouvernance des réseaux d'agents

Une formation pour votre équipe ?

Chaque session est adaptée à vos cas d'usage, vos données et votre planning.

Demander un devis