Hôpital de messages

Objectif(s)
  1. Garantir la non perte de messages transactionnels.
  2. Permettre la réinjection par les équipes Support.
Cible(s) 

Principes

Il s'agit d'un routage des messages en erreur vers un espace de stockage dédié au:

  • Contrôle
  • Compréhension des erreurs
  • Rejeu

Un hôpital a plusieurs « lits », soit 1 lit par demi-flux. Cela offre:

  • un rejeu opérationnel par demi-flux
  • des corrections en masse par demi-flux
  • une ré-injection en masse maîtrise par demi-flux

Architecture

Chaque lit héberge les messages rejetés pour:

  • indisponibilité
  • mauvais format
  • incohérence fonctionnelle
  • etc.

Mais chaque lit correspond à la Dead letter queue du mode asynchrone.

Les données stockées sont au format d'entrée dans le demid-flux. Ainsi, toutes les stratégies de rejeux sont possibles: réinjection, transformation, routage, etc.

Comportement des erreurs

PatternComportementCommentaire(s)
Request / ResponseErreur renvoyée au demandeur

Comportement le plus simple possible pour ne pas comlexifier les médiations.

Sinon, il convient d'utiliser un cache de réponses.

One-WayStockage pour rejeuLes messages sont véhiculés suivant un principe asynchrone. Les messages sont stockées pour rejeu ultérieurs.
Multi-TargetStockage par destinataire

Chaque destinataire peut avoir absorber des messages indépendamment des autres.

Les destinataires peuvent avoir des SLA différents. Donc les messages sont stockées pour permettre leur déconnexion du réseau.