Selective Consumer

Le filtrage côté queue plutôt que côté code — pour éviter qu'un consumer ne tire 1000 messages pour en jeter 999.

Problème

Une queue commune transporte des messages destinés à plusieurs consumers selon un critère (partenaire, type, environnement). Un consumer naïf tire tout et filtre en code — gaspillage de bande passante et de CPU.

Forces

• Une seule queue est souvent imposée par le broker EDI partagé ; on ne peut pas créer une queue par consumer.
• Tirer puis jeter consomme la lock du message, bloque les autres consumers et gonfle le commit log.
• Le filtrage côté queue ne s'applique que sur les headers / properties, pas sur le payload chiffré.
• Un selector inadapté peut faire stagner un message si aucun consumer ne le matche.

Solution

Configurer le consumer avec un selector côté broker. Sous JMS, le selector est une expression SQL-like sur les headers (`AS2_PARTNER = 'WALMART' AND DOC_TYPE = 'ORDERS'`). Sous Kafka, on s'appuie sur des partitions par clé et un filtre Streams. Sous RabbitMQ, on utilise un binding key sur un topic exchange. Le résultat : chaque consumer ne reçoit que ses messages, sans pull-and-drop.

Implémentation EDI

En EDI, le Selective Consumer est utilisé pour séparer les traitements par partenaire (un consumer par grand donneur d'ordre Walmart / Target / Amazon) sans dupliquer la queue. Les headers sont peuplés par le AS2 Gateway au moment de l'ingestion : `AS2_FROM`, `AS2_TO`, `DOC_TYPE`. Les consumers Camel s'abonnent avec un `selector='DOC_TYPE = ORDERS'`. Attention à ne pas reposer sur des headers non garantis (le partenaire peut omettre `AS2_FROM` dans certaines flow signed-only).

Anti-patterns

• Selector trop large qui matche tout — le pattern dégénère en pull-and-drop déguisé.
• Selector qui dépend du payload (impossible côté broker) — confondu avec un Message Filter applicatif.
• Selectors qui se recouvrent entre consumers — un même message tiré deux fois.
• Selectors qui se complètent pas (no consumer matches) — message bloqué jusqu'à TTL ou DLQ.

Patterns liés

• Message Filter — filtrage côté application (post-pull).
• Competing Consumers — scaling-out d`une queue unique.
• Datatype Channel — alternative : une queue par type.
• Event-Driven Consumer — consumer push complémentaire.

Sources

• Hohpe G., Woolf B. — EIP, Selective Consumer (p. 515). www.enterpriseintegrationpatterns.com/patterns/messaging/MessageSelector.html
• Apache ActiveMQ — Message Selectors. activemq.apache.org/components/classic/documentation/selectors