Polling Consumer

Le consumer qui pull à intervalle régulier — le polling EDI legacy SFTP/FTPS.

Problème

Comment recevoir des messages d'un système qui n'a pas de push notification ? Comment intégrer un legacy système EDI qui ne fait que déposer des fichiers ?

Forces

• Push est élégant mais nécessite un endpoint exposé — pas toujours faisable derrière un firewall.
• Polling est simple à implémenter et à débugger — un cron + un script.
• Polling consomme des ressources même en l'absence de messages.
• Polling crée latence (poll interval) — pas adapté au temps réel.

Solution

Un consumer qui boucle : (1) interroger le canal/dossier, (2) traiter les nouveaux messages, (3) attendre N secondes, retour à 1. Pattern simple, prévisible, facile à monitorer (poll latency, items processed). Intervalle typique : 30s en EDI batch, 5s en EDI quasi-temps réel.

Implémentation EDI

En EDI, le Polling Consumer est le mode standard pour SFTP : un job CRON ou un Camel route `file://?delay=30000` parcourt le répertoire SFTP toutes les 30 secondes, traite chaque nouveau fichier. Aussi utilisé pour OFTP polling et pour les VAN legacy. Modernisé : Polling Bridge transforme polling SFTP en push Kafka.

Anti-patterns

• Polling interval < 1s avec traitement coûteux — surcharge inutile.
• Polling sans timeout — un répertoire massif (1000+ fichiers) prend des heures par cycle.
• Polling sans lockfile — deux instances traitent le même fichier en parallèle.

Patterns liés

• Event-Driven Consumer — alternative push.
• Message Endpoint — concept parent.

Sources

• Hohpe G., Woolf B. — EIP, Polling Consumer (p. 494). www.enterpriseintegrationpatterns.com/patterns/messaging/PollingConsumer.html