ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Session Window

Comment regrouper des évènements naturellement groupés par bursts d'activité, sans alignement sur un calendrier fixe.

Problème

Les fenêtres tumbling et sliding sont alignées sur des horloges externes (chaque heure pile, chaque 30 secondes). Beaucoup d'activités réelles ne suivent pas un tempo régulier : un utilisateur clique 12 fois en 2 minutes puis disparaît pendant 4 heures ; un partenaire EDI envoie 200 factures en 5 minutes puis rien pendant la nuit. Pour ces cas, on veut regrouper les évènements proches dans le temps en sessions distinctes — comportement métier ou utilisateur unique — séparées par des périodes d'inactivité (gaps).

Forces

  • Pas d'alignement temporel — chaque clé a ses propres sessions avec début et fin variables.
  • Définition du gap : trop court = sessions fragmentées ; trop long = sessions fusionnées artificiellement.
  • Fusion de sessions : un évènement en retard peut fusionner deux sessions précédemment fermées — logique complexe.
  • State : maintenir une session ouverte par clé, libérer après gap.
  • Coût élevé sur très grande cardinalité — chaque clé porte sa session.

Solution

Définir un gap G (durée d'inactivité après laquelle la session est considérée terminée). Un évènement à temps t ouvre une session s'il n'y en a pas d'active pour cette clé. Un évènement subséquent à t' < t+G étend la session. Quand la watermark dépasse t_dernier + G sans nouvel évènement, la session se ferme et l'agrégat est émis. Pour gérer les évènements en retard, Flink permet la fusion : si un évènement arrive et tombe entre deux sessions déjà fermées séparées par moins de G, les deux sessions sont fusionnées rétroactivement. Implémentation Flink : stream.keyBy(partnerId).window(EventTimeSessionWindows.withGap(Time.minutes(30))).aggregate(new BatchSizeAggregator()).

Structure

Partner A timeline (gap = 30 min):
Time:  09:00  09:05  09:08  09:15 ...... 11:45  11:50  11:52
Event:  ●      ●      ●      ●            ●      ●      ●
        └─── Session 1 (4 events) ─┘     └ Session 2 (3) ─┘
              gap < 30min                  4h gap, > 30min
                                          → previous session closed

Partner B timeline:
Time:  09:30  09:50  10:25
Event:  ●      ●      ●
        └─ Session 1 ─┘
              all gaps < 30min → single session of 3 events

Late event arriving at 09:20 for partner A:
  Falls between sessions 1 (09:00-09:15) and an earlier session?
  → If yes and gap allows, merge sessions retroactively
  → If no, may create a new singleton session

Implémentation EDI

Cas EDI typiques. (1) Batch détection partenaire : regrouper toutes les INVOIC reçues d'un même partenaire séparées par moins de 30 minutes en une seule « session d'envoi », pour calculer la taille moyenne du batch et son timing — utile pour optimiser le SLA d'acquittement (envoyer un APERAK groupé par session plutôt qu'un par message). (2) Workflow saga long-running : un cycle ORDERS/ORDRSP/DESADV/RECADV/INVOIC peut s'étaler sur plusieurs jours mais avec des bursts d'activité ; une session window avec gap de 7 jours par numéro de commande regroupe les évènements d'une même saga métier. (3) Détection d'attaque : si un partenaire envoie une session anormalement courte avec beaucoup d'erreurs, c'est typiquement un mauvais déploiement ou un robot qui rejoue ; alerter sur le pattern. Pour ces cas, ne pas oublier de purger le state à la fermeture de session — sans ça, RocksDB explose en quelques semaines.

Anti-patterns

  • Gap trop court (par exemple 30 secondes pour des messages humains) — fragmente les vraies sessions en dizaines de fragments.
  • Gap trop long (par exemple 4h pour des websessions) — fusionne deux journées d'utilisation en une seule session.
  • Pas de TTL post-fermeture — le state d'une clé inactive depuis 6 mois reste éternel.
  • Calcul d'agrégat coûteux par évènement au lieu d'incrémental — chaque arrivée recalcule tout.
  • Ignorer le merge — un évènement en retard peut casser les agrégats déjà émis.

Patterns liés

Sources