02 • 34 • 09 • 31 • 70
L'intégration moderne ne se contente plus de déplacer des fichiers la nuit. Les entreprises exigent du temps réel : une commande passée sur le web doit être visible instantanément dans l'ERP et le WMS. Pour répondre à ce besoin, l'Architecture Orientée Événements ou EDA (Event-Driven Architecture) est devenue incontournable.
Dans l'écosystème Boomi, la question du "transport" de ces événements est centrale. Si la plateforme Boomi dispose de connecteurs natifs pour les grands standards du marché (Kafka, RabbitMQ, Solace, Azure Service Bus), Boomi propose également sa propre solution : Boomi Event Streams.
Dans cet article, nous allons voir comment implémenter un pattern "Pub/Sub" classique.
Nous aborderons d'abord l'approche traditionnelle avec un broker externe, puis nous détaillerons la mise en œuvre via Boomi Event Streams, de la configuration du Topic jusqu'au design du processus consommateur.
Enfin, nous évoquerons la gestion des erreurs (Dead Letter Queues), point critique d'une architecture résiliente.
Étape 1 : Analyse des options d'architecture
Avant de développer, un architecte doit choisir le bon outil pour le bon usage.
L'approche "Broker Externe" (JMS, Kafka, RabbitMQ, Azure…)
Boomi est agnostique. Si votre entreprise possède déjà une architecture EDA existante (ex: un cluster Kafka), il est logique de l'utiliser. Via les connecteurs RabbitMQ ou Kafka, Boomi agit comme un simple "point de terminaison".
- Le Processus Producteur : Utilise un connecteur "Send"/"Produce" pour pousser votre format d’entrée dans un Topic externe.
- Le Processus Consommateur : Utilise un "Start Shape" de type Listener qui écoute ce même Topic pour "Consume" les messages.
Limites techniques : Cette approche impose une double maintenance. Il faut administrer le broker (souvent complexe) d'un côté, et les flux Boomi de l'autre. Le monitoring est fragmenté : si un message est perdu, est-ce la faute du réseau, du broker, ou de l'Atom Boomi ?
L'approche Intégrée : Boomi Event Streams
Boomi Event Streams est un broker de messages hébergé et géré par Boomi, directement intégré à la plateforme AtomSphere.
L'avantage immédiat : Une console unique ("Single Pane of Glass"). La création des files d'attente, la sécurité et le monitoring se font au même endroit que vos développements d'intégration.
Étape 2 : Configuration du Broker (Event Streams)
Pour notre exemple, nous allons simuler un cas classique : La mise à jour d'une fiche client. Lorsqu'un client change d'adresse dans le CRM, nous devons publier cet événement pour que l'ERP et le Marketing le reçoivent.
Avant de toucher aux processus, nous devons configurer l'infrastructure logique dans le menu Event Streams de la plateforme. Contrairement à des solutions comme Kafka qui demandent une expertise pointue pour le dimensionnement, Boomi a fait le choix de la simplicité radicale.
Création de l'Environnement et du Topic
Dans la console, nous créons le canal de communication.
- Topic Name : CLIENT_UPDATES
- Configuration : C'est tout ! Nul besoin de définir manuellement le nombre de partitions ou la stratégie de réplication. Boomi gère le scaling horizontal et l'infrastructure en arrière-plan de manière transparente.
Création des Subscriptions (Abonnements)
Toujours dans la console, nous déclarons les "portes de sortie" du Topic. Nous en créons deux pour nos deux consommateurs distincts :
- Nom : SUB_ERP_U_CLIENT (sera utilisé par le flux ERP)
- Nom : SUB_MKT_U_CLIENT (sera utilisé par le flux Marketing)
Note : À ce stade, nous ne définissons pas encore le comportement (FIFO ou Parallèle). Cette intelligence est déportée au niveau du processus, ce qui offre une grande flexibilité.
Étape 3 : Création du Processus Producteur (Publisher)
L'objectif est simple : Capturer l'événement et l'envoyer dans le tuyau.
Le Design du flux :
- Start Shape : Réception de la donnée (ex: Webhook Salesforce ou API Listener).
- Map Shape : Transformation du format source vers un format canonique JSON léger.
- Connector Shape (Boomi Event Streams) :
- Connection : On sélectionne la connexion configurée (n'oubliez pas de générer le Token dans la console Event Streams pour authentifier l'environnement).
- Action : Produce.
- Operation :
- Topic : C'est ici que l'on saisit le nom du topic, par exemple CLIENT_UPDATES.
- Access Mode : Nous laissons généralement Shared pour permettre à plusieurs exécutions simultanées de publier des messages.
Point d'attention sur les métadonnées : Il est possible d'ajouter des "User Properties" dynamiques dans l'opération du connecteur (ex: client_type=VIP). Cela permettra aux consommateurs de filtrer les messages sans même avoir à désérialiser le payload JSON, économisant ainsi des ressources de calcul.
Étape 4 : Création du Processus Consommateur (Subscriber)
C'est ici que la magie du temps réel opère. Contrairement aux flux ETL classiques planifiés, le Start Shape est configuré en mode Connector avec Boomi Event Streams. C'est dans la configuration de l'Opération que nous allons définir le comportement exact du consommateur.
Configurez le connecteur Boomi Event Streams avec l'opération LISTEN.
(Cela permet au processus de se déclencher automatiquement à l'arrivée de chaque nouvel événement dans le Topic.)
Le Ciblage (Topic & Subscription)
La première règle est de lier le processus au bon canal.
- Topic : Nous saisissons le nom du topic défini plus tôt "CLIENT_UPDATES".
- Subscription : Nous indiquons le nom précis de l'abonnement "SUB_ERP_U_CLIENT".
Le Comportement de Consommation (Subscription Type)
C'est le paramètre critique pour votre architecture. Comme évoqué précédemment, Boomi propose trois modes :
- Exclusive (FIFO) : Un seul consommateur actif. Idéal pour garantir l'ordre strict des opérations.
- Shared (Load Balancing) : Distribution des messages sur plusieurs nœuds en parallèle. C'est le choix de la performance pure.
- Failover : Mode Actif/Passif pour garantir l'ordre tout en assurant la haute disponibilité.
Fiabilisation du flux (Transacted Acknowledgement)
Sur l'opération, vous verrez une case décochée par défaut : Transacted Acknowledgement. Cochez-la systématiquement pour les flux de production.
- À quoi ça sert ? Cette option active le mode transactionnel. Le message n'est considéré comme "traité" (et donc supprimé de la file d'attente) que si et seulement si le processus Boomi va jusqu'au bout sans erreur.
- En cas d'erreur : Si votre processus plante au milieu (coupure réseau, erreur de mapping...), Boomi ne renvoie pas l'accusé de réception (Ack). Le message redevient immédiatement disponible dans le Topic pour être traité à nouveau. C'est la garantie "At Least Once".
Contrôle de la Charge (Maximum Concurrent Executions)
Condition : Ce champ n'apparaît que si "Transacted Acknowledgement" est coché.
Ce paramètre (réglé sur 1 par défaut) est votre levier de performance :
- Pour respecter l'ordre (FIFO) : Laissez la valeur sur 1. Cela oblige l'Atom à traiter les messages un par un, garantissant que la commande A est finie avant que la commande B ne commence.
- Pour la vitesse (Parallélisme) : Si l'ordre n'importe pas, augmentez ce chiffre (ex: 5 ou 10). L'Atom ouvrira alors plusieurs "voies" pour traiter plusieurs messages en même temps.
Attention : En mode Exclusive Subscription, ce paramètre est techniquement bridé pour garantir l'exclusivité. En mode Shared, c'est là que vous débloquez la puissance du traitement parallèle.
Étape 5 : Gestion des Erreurs et Dead Letter Queues (DLQ)
Dans un monde asynchrone, que se passe-t-il si l'ERP est en maintenance lors de la réception du message ? Si nous ne gérons pas l'erreur, le message est perdu à jamais.
Le mécanisme de Retry
Dans l'opération du connecteur "Listen", nous pouvons configurer :
- Maximum Retries : Définit le nombre de nouvelles tentatives,
- Retry Timeout : Définit le temps d'attente entre chaque tentative
Si le processus échoue (ex: erreur réseau), le message reste dans la file et sera représenté au processus après un délai exponentiel (Backoff).
La Dead Letter Queue (DLQ)
Si, après N tentatives, le message ne passe toujours pas (par exemple à cause d'un format de données invalide), il ne doit pas bloquer les autres messages. Boomi Event Streams place automatiquement ce message dans une DLQ (Dead Letter Queue).
Comment consommer la DLQ ?
Ces messages en erreur ne doivent pas être ignorés. Pour les traiter (analyser l'erreur, alerter ou rejouer la donnée), il faut créer un processus spécifique. La configuration est identique à un consommateur classique, à une seule différence près :
- Dans l'opération du connecteur, il suffit d'activer la case Consume From Dead Letter.
Ce paramètre indique au processus d'aller lire uniquement les messages mis en quarantaine sur cette souscription, permettant ainsi de mettre en place une stratégie de remédiation efficace.
Bonus : Exploration du Backlog et de la Dead Letter Queue
Avoir des métriques est utile, mais en cas de blocage, vous avez besoin de voir le contenu réel des messages (le payload) pour comprendre le problème. Boomi permet cette introspection directement depuis la console, sans outil tiers.
Comment accéder aux messages bloqués ?
- Accédez à votre Topic (ex: CLIENT_UPDATES).
- Descendez jusqu'à la liste des Subscriptions.
- Cliquez sur les trois petits points (Actions) à droite de la souscription concernée.
- Sélectionnez View Backlog Messages.
L'interface de gestion des Backlogs
Une fois dans cette vue détaillée, vous avez accès à deux onglets cruciaux :
- Subscription Backlog : C'est la file d'attente "normale". Vous y verrez les messages en attente de traitement (utile pour vérifier si un consommateur est trop lent).
- Dead Letter Backlog : C'est la "zone de quarantaine". En cliquant sur cet onglet, vous retrouvez tous les messages qui ont échoué définitivement.
Pourquoi est-ce puissant ? Depuis cet écran, vous pouvez cliquer sur un Message ID pour lire son contenu. C'est l'outil ultime pour le débogage : vous verrez immédiatement si le message contient une donnée invalide (ex: un caractère spécial non supporté par l'ERP) sans avoir à fouiller dans les logs serveur. Vous pouvez également supprimer manuellement des messages obsolètes ("Delete Selected") pour nettoyer la file.
Conclusion
Nous avons vu comment mettre en place une architecture découplée robuste avec Boomi Event Streams. L'utilisation d'un broker interne présente un avantage décisif sur les brokers externes pour les équipes Boomi : la simplicité opérationnelle.
Tout est géré depuis la même interface, les tokens de sécurité sont unifiés, et la latence est minimisée car le broker réside au plus près de l'Atom Cloud. Cependant, pour des architectures très haute performance nécessitant une persistance longue durée (plusieurs jours) ou une consommation par des systèmes tiers non-Boomi, l'usage d’un broker externe reste pertinent. Le choix dépendra, comme toujours, de vos contraintes de gouvernance et de volumétrie.
Vous souhaitez auditer votre architecture d'intégration ou mettre en place vos premiers flux événementiels ? Nos consultants sont là pour vous accompagner. Contactez-nous !
