Control Bus

Le canal admin parallèle au canal métier — gérer les composants à chaud.

Problème

Comment piloter à chaud un hub EDI distribué — relancer un parser, vider une queue, désactiver un partenaire en panne, sans redéployer ?

Forces

• Mélanger contrôle et données pollue les deux flux.
• Le contrôle doit être audité (qui a redémarré quoi ?).
• Le contrôle doit être typé (impossible d'envoyer une commande mal formée).
• Les composants doivent pouvoir refuser une commande (sécurité, état incompatible).

Solution

Définir un Control Bus distinct des canaux métier — typiquement un topic Kafka edi.control ou un broker dédié. Les composants s'y abonnent en plus de leur canal métier. Messages typés (StartCommand, StopCommand, ReloadConfig, HealthCheck, MetricsRequest). RBAC strict — seuls les opérateurs autorisés peuvent publier.

Implémentation EDI

En EDI, le Control Bus est utilisé pour : recharger des mappings sans redémarrage, suspendre/reprendre un partenaire pendant maintenance, déclencher des dumps de métriques, lancer des replays sélectifs. Implémentation : topic Kafka edi.control avec messages JSON typés, abonnés via le même framework (Camel, Spring Cloud Stream) mais avec ACL séparée.

Anti-patterns

• Control Bus ouvert sans authentification — n'importe qui peut tuer le hub.
• Contrôle synchrone à temps long — bloquer la conversation pendant un health-check.
• Pas de logs audit — impossible de tracer qui a fait quoi.

Patterns liés

• Dynamic Router — consommateur classique du Control Bus.
• Test Message — message via Control Bus.
• Channel Purger — action déclenchée par Control Bus.

Sources

• Hohpe G., Woolf B. — EIP, Control Bus (p. 540). www.enterpriseintegrationpatterns.com/patterns/messaging/ControlBus.html