Message Filter
Le filtre sélectif — ne pas confondre avec le router (qui aiguille toujours).
Problème
Une équipe a souscrit à un canal général (toutes les factures) mais ne s'intéresse qu'aux factures de plus de 10 000 €. Comment éviter de traiter inutilement les petites factures ?
Forces
- Republier un canal filtré coûte du throughput au broker (lecture + écriture).
- Demander au producteur de splitter coûte de la complexité côté amont.
- Filtrer côté consumer reste local mais consomme du CPU côté abonné.
- Les critères évoluent — hier 10 000 €, demain 5 000 €.
Solution
Insérer un Message Filter entre le canal source et le canal cible (ou directement dans le consumer). Le filter inspecte le payload (typiquement via une expression — JSONPath, XPath, expression Camel) et publie seulement les messages matching. Implémentation simple, sémantique connue de tous.
Implémentation EDI
En EDI, exemples typiques : filtrer les INVOIC > 10 k€ pour le service comptable, filtrer les ORDERS contenant des produits réglementés (alcool, pharmacie) pour le service compliance, filtrer les MDN négatifs vers le service support partenaire. Implémentation : route Camel `.filter()`, Kafka Streams `.filter()`, function Lambda à filtre. Réutiliser le schema registry pour parser typé.
Anti-patterns
- Filter qui modifie le message — ce n'est plus un filter, c'est un translator.
- Filter en cascade sans monitoring du drop rate — silencieux et impossible à débugger.
- Filter trop coûteux (parse XML complet) qui surcharge le consumer.
Patterns liés
- Content-Based Router — aiguillage vs filtrage.
- Message Router — concept parent.
Sources
- Hohpe G., Woolf B. — EIP, Message Filter (p. 237). www.enterpriseintegrationpatterns.com/patterns/messaging/Filter.html