Service Activator

Le pont entre la queue et l'API : reçoit un message, appelle un service, gère la réponse — la passerelle classique vers les systèmes legacy.

Problème

Un système métier existant (ERP, OMS, mainframe) expose une API sync (SOAP, REST, RPC). Le hub EDI publie des messages async. Comment relier les deux sans modifier l'application existante ?

Forces

• Le système métier ne peut souvent pas devenir consumer de queue (pas de SDK, pas de modification possible).
• Le service activator doit gérer les retries, timeouts, et l'idempotency côté API legacy.
• Une exception du service legacy doit être encapsulée et routée correctement (DLQ, retry, alert).
• La latence du service sync impose un parallélisme limité côté activator.

Solution

Introduire un composant activator qui consomme du message broker, désérialise, prépare la requête, appelle l'API sync, attend la réponse, et soit acquitte (success) soit retry/escalade (failure). Le pattern paye sur le découplage : l'application legacy reste inchangée, le hub gère toute la complexité messaging. Implémentations classiques : Apache Camel `<process>` avec call HTTP, Spring Integration `<service-activator>`.

Implémentation EDI

En EDI, le Service Activator est le moyen le plus fréquent d'intégrer un ERP non-Kafka-native. Un consumer Camel sur `edi.orders` désérialise un JSON canonique, appelle un endpoint SAP via IDoc ou OData, attend la réponse, et publie un évènement `OrderImported`. Patterns associés : Circuit Breaker autour de l'appel API legacy, Idempotent Receiver côté DB de l'ERP, Dead Letter Channel pour les exceptions non-retriables.

Anti-patterns

• Activator sans timeout — un service legacy lent bloque tout le consumer pool.
• Activator sans retry — une glitch temporaire envoie tout en DLQ.
• Activator qui mute le message en place et acquitte avant la réponse legacy — perte de données si l'API legacy échoue.
• Activator qui appelle plusieurs services en cascade sans saga — incohérences sur exception.

Patterns liés

• Message Endpoint — concept parent.
• Circuit Breaker — protection autour de l'appel sync.
• Idempotent Receiver — côté DB legacy.
• Dead Letter Channel — destination des exceptions.

Sources

• Hohpe G., Woolf B. — EIP, Service Activator (p. 532). www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingAdapter.html
• Spring Integration — Service Activator. docs.spring.io/spring-integration/reference/service-activator.html