Architecture événementielle avec Anypoint MQ (Course #eda-mq)
For développeurs d'intégration, architectes de solutions, ingénieurs plateforme.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de concevoir et d'exploiter une couche événementielle sur Anypoint MQ — topologie de queues et de message exchanges, consommateurs idempotents, acquittement calibré, chemin de dead letter queue et de rejeu documenté — pour qu'une panne aval de six heures coûte une fenêtre de rejeu et non du chiffre d'affaires perdu.
Cas fil rouge
Brightgrid Energy relève 4,2 millions de foyers dans 7 pays, et chaque compteur communicant émet des événements de consommation, de fraude et de coupure vers un paysage fait de la facturation SAP IS-U, d'une console de service Salesforce, d'un lac analytique et d'un système historique de gestion des coupures qui n'accepte qu'un appel à la fois. Les jours de tempête poussent 18 000 événements/seconde contre 2 500/seconde en régime normal ; la facturation ne doit jamais facturer deux fois le même kWh, les événements d'un compteur doivent arriver dans l'ordre, et une panne aval de 6 heures ne doit perdre aucun relevé — rejouer une journée complète, soit 210 millions d'événements, doit tenir dans une fenêtre de 4 heures. Chaque module rend l'une de ces garanties explicite et vérifiable.
Programme chaque ligne est quelque chose que vous faites
5 modules · 15 sujets · dans l'ordre du cours
-
Module 1
Le couplage est la vraie décision
Objectif. Arbitrer le couplage de chaque intégration Brightgrid — Anypoint MQ, JMS ou callback HTTP — et produire une matrice de décision couvrant les 7 flux pays.
- Distinguer commande et événement : réécrire 6 intégrations requête-réponse en faits publiés, en nommant producteur, consommateurs et rétention par flux
- Noter Anypoint MQ, les brokers JMS et les callbacks HTTP sur la garantie de livraison, la propriété du broker et l'exploitabilité, une ligne par intégration
- Dimensionner l'enveloppe face aux plafonds durs — 10 Mo de payload maximum, TTL de message de deux semaines au plus — et basculer en claim-check vers Object Store v2 au-delà
-
Module 2
Une publication, plusieurs consommateurs
Objectif. Concevoir la topologie de queues et de message exchanges qui diffuse un événement compteur vers facturation, analytique et gestion des coupures sans toucher au producteur.
- Tracer la topologie : queues point-à-point pour répartir le travail, message exchanges pour diffuser vers 3 groupes de consommateurs indépendants
- Lier et router en connaissance de cause — jusqu'à 450 queues par message exchange, mais 25 seulement dès que des règles de routage intelligent entrent en jeu
- Raccorder un quatrième consommateur sans aucun déploiement du producteur : lier une nouvelle queue, prouver que le binaire publieur reste intact, mesurer le retard de livraison
-
Module 3
Au moins une fois, donc des doublons
Objectif. Prouver l'idempotence des consommateurs sous redélivraison forcée, puis évaluer ce que coûte réellement l'ordre strict FIFO aux volumes de Brightgrid.
- Construire des consommateurs idempotents indexés sur meter-id et horodatage de relevé dans Object Store v2, en prouvant zéro double facturation sur 10 000 redélivraisons forcées
- Peser l'ordre exactement-une-fois du FIFO face à ses plafonds : 10 messages en vol par message group et 300 TPS, 3 000 TPS uniquement en lots de 10 par opération
- Cantonner l'ordre là où il est vraiment requis — un message group par compteur, maxConcurrency à 1 — puis remesurer face au pic de tempête de 18 000 événements/seconde
-
Module 4
Acquitter, sinon le message revient
Objectif. Construire un subscriber Anypoint MQ calibré — mode d'acquittement, délai, préchargement — qui tient la charge de pointe sans déclencher de tempête de redélivraisons.
- Apparier le mode d'acquittement au rayon d'impact sur les 3 modes — AUTO, MANUAL, IMMEDIATE — et chiffrer la perte de messages que chacun autorise
- Fixer le délai d'acquittement d'après le temps de traitement mesuré, en traitant 12 heures comme un plafond et non un défaut, pour que les consommateurs lents cessent de retraiter du travail déjà fait
- Calibrer le subscriber : bufferisation par préchargement contre polling à 10 messages par seconde, rapportés au plafond de 120 000 messages en vol d'une queue standard
-
Module 5
Les messages empoisonnés ne s'évaporent pas
Objectif. Construire le chemin dead letter queue et rejeu — politique de DLQ, runbook de triage, flow de redrive — et prouver qu'un arriéré de six heures se retraite sans doublon.
- Définir une politique de dead letter queue par queue : 10 tentatives de livraison par défaut, réglables de 1 à 1000, dimensionnées sur le temps de rétablissement réel de l'aval
- Trier avant de rejouer — inspecter jusqu'à 50 messages sur une queue standard, 10 sur une queue FIFO — et séparer défauts de schéma et défauts transitoires
- Écrire le flow de redrive qu'Anypoint MQ ne fournit pas : rejouer 210 millions d'événements dans une fenêtre de 4 heures, débit maîtrisé et clés d'idempotence préservées
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Glossaire Anypoint MQDoc MuleSoft
- Présentation d'Anypoint MQDoc MuleSoft
Module 2
Module 3
- FAQ : Anypoint MQDoc MuleSoft
Module 4
- Opérations ACK et NACK d'Anypoint MQDoc MuleSoft
- Source Subscriber Anypoint MQDoc MuleSoft
Module 5
- Configurer et utiliser les files d'attenteDoc MuleSoft