Architecture d'intégration avancée & animation du C4E (Course #advanced-architecture-c4e)

Programme chaque ligne est quelque chose que vous faites

5 modules · 15 sujets · dans l'ordre du cours

1. Module 1

   Livraison fédérée, vraies gates

   Objectif. Arbitrer le modèle de livraison fédérée d'Altaris et instaurer des gates automatisées dont les métriques prouvent la valeur du C4E chaque trimestre.

   • Choisir le modèle fédéré par domaine — hub-and-spoke ou aligné produit — et le doter en effectifs, p. ex. 2 facilitateurs pour 12 squads
   • Encoder les standards en gates automatisées : rulesets de gouvernance sur les specs, coverage MUnit plancher en CI, policies socle dans API Manager
   • Bâtir le tableau de bord du C4E avec responsables nommés : taux de réutilisation, time-to-first-API < 6 semaines, satisfaction consommateurs
2. Module 2

   Maîtriser le cycle complet

   Objectif. Évaluer les stratégies de versioning au regard du risque de rupture et conduire dépréciation et retrait sur des dates annoncées aux consommateurs.

   • Trancher versioning par URI ou header par famille d'API et codifier la rupture via diff des specs OAS 3.x
   • Industrialiser la dépréciation : headers Sunset, fenêtres de 180 jours, coexistence de versions majeures, notification automatique des consommateurs
   • Conduire les transitions d'état — conçue, publiée, dépréciée, retirée — dans Exchange et API Manager, critères de sortie par étape
3. Module 3

   Disponibilité : une décision de conception

   Objectif. Dimensionner HA et PRA pour tenir 99,95 % avec RPO 15 min / RTO 4 h et arbitrer les leviers de tuning sous enveloppe de vCores fixe.

   • Appliquer les patterns HA/PRA : clusters multi-workers multi-zones, DLQ Anypoint MQ avec redelivery, DR actif-passif répété deux fois l'an
   • Actionner les leviers qui font bouger le p99 : streaming plutôt qu'in-memory, pooling de connexions, cache scopes, profils de threads ajustés
   • Planifier la capacité sur des mesures : p99 et TPS par API, prévisions de croissance, p. ex. +2 vCores par +50 % de volume, revue trimestrielle
4. Module 4

   DataWeave sous gouvernance

   Objectif. Diagnostiquer les risques mémoire et streaming des mappings critiques et imposer bibliothèques partagées et seuils de revue aux squads.

   • Publier sur Exchange des modules DataWeave 2.x partagés — schémas canoniques, formats d'échange — et les versionner comme tout actif
   • Filtrer les traitements lourds sur des chiffres : fichiers > 100 Mo streamés sans pic heap, 2 M de lignes réconciliées en < 40 min mesuré
   • Ajouter des points de contrôle DataWeave en revue : pas de logique dupliquée sans module partagé, pas de collect() sur liste non bornée
5. Module 5

   Platform Architect I : cap sur l'examen

   Objectif. Cartographier les domaines Platform Architect I au regard de vos projets livrés et convertir les lacunes diagnostiquées en plan de révision daté.

   • Rapporter les domaines et pondérations de l'examen à vos projets ; marquer les zones faibles, p. ex. < 50 % au test blanc
   • Driller des scénarios chronométrés : défendre chaque réponse à voix haute, repérer les distracteurs confondant limites CloudHub et Runtime Fabric
   • Repartir avec un plan daté : blocs d'étude hebdomadaires, deux tests blancs réservés, date d'examen calée sous 8 semaines

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

Module 1

• Présentation d'Anypoint API GovernanceDoc MuleSoft
• Couverture MUnitDoc MuleSoft

Module 2

• RFC 8594 — Le champ d'en-tête HTTP SunsetSpécification
• Gérer les états du cycle de vie d'un assetDoc MuleSoft

Module 3

• Haute disponibilité et reprise après sinistre CloudHub 2.0Doc MuleSoft
• Haute disponibilité et reprise après sinistreDoc MuleSoft

Module 4

• Gestion mémoire de DataWeaveDoc MuleSoft
• Streaming dans DataWeaveDoc MuleSoft

Dans la filière Architecture