Report des messages dans Azure Service Bus

Lorsqu’une file d’attente ou un client d’abonnement reçoit un message qu’il est prêt à traiter, mais que le traitement n’est actuellement pas possible en raison de circonstances particulières, le client peut différer la récupération du message à un point ultérieur. Le message reste dans la file d’attente ou l’abonnement, mais il est mis de côté.

Quand utiliser le report de message

Le report est une fonctionnalité créée spécifiquement pour les scénarios de traitement de flux de travail. Les infrastructures de flux de travail peuvent nécessiter le traitement de certaines opérations dans un ordre particulier. Ils peuvent être amenés à reporter le traitement de certains messages reçus jusqu’à ce que le travail préalable prescrit informé par d’autres messages soit terminé.

Un exemple illustrant simple est une séquence de traitement des commandes dans laquelle une notification de paiement d’un fournisseur de paiement externe apparaît dans un système avant la propagation de la commande correspondante de la vitrine vers le système de traitement. Dans ce cas, le système de traitement peut différer le traitement de la notification de paiement jusqu’à ce qu’il y ait une commande à laquelle l’associer. Dans les scénarios de rendez-vous, où des messages provenant de différentes sources font avancer un flux de travail, l’ordre d’exécution en temps réel peut être correct, mais les messages qui reflètent les résultats peuvent arriver dans le désordre.

Le report permet de réorganiser les messages de l’ordre d’arrivée dans une commande dans laquelle ils peuvent être traités, tout en laissant ces messages en toute sécurité dans le magasin de messages lorsque le traitement doit être reporté.

Si un message ne peut pas être traité, car une ressource particulière pour la gestion de ce message n’est pas temporairement indisponible, mais que le traitement des messages ne doit pas être suspendu, vous pouvez mettre ce message de côté pendant quelques minutes. N’oubliez pas le numéro de séquence d’un message planifié à publier en quelques minutes et récupérez à nouveau le message différé lorsque le message planifié arrive. Si un gestionnaire de messages dépend d’une base de données pour toutes les opérations et que cette base de données est temporairement indisponible, n’utilisez pas de report. Au lieu de cela, suspendez complètement la réception des messages jusqu’à ce que la base de données soit à nouveau disponible.

Récupérer les messages différés

Les messages différés restent dans la file d’attente principale ainsi que tous les autres messages actifs (contrairement aux messages de lettres mortes qui vivent dans un sous-file d’attente), mais ils ne peuvent plus être reçus à l’aide des opérations de réception régulières. Vous pouvez découvrir les messages différés par le biais de la navigation des messages ou de l’aperçu si une application perd le suivi de ces messages.

Pour récupérer un message différé, le propriétaire est responsable de la mémorisation du numéro de séquence lors du report du message. Tout récepteur qui connaît le numéro de séquence d’un message différé peut recevoir ultérieurement le message à l’aide de méthodes de réception qui prennent le numéro de séquence comme paramètre. Pour plus d’informations sur les numéros de séquence, consultez séquencement de messages et horodatages.

Note

Les messages différés n’expirent pas et passent automatiquement à une file d’attente de lettres mortes jusqu’à ce qu’une application cliente tente de les recevoir à l’aide d’une API et du numéro de séquence. Ce comportement est voulu. Lorsqu’un client tente de récupérer un message différé, il est vérifié pour la condition expirée et déplacé vers une file d’attente de lettres mortes s’il a déjà expiré. Un message expiré est déplacé vers une sous-file de lettres mortes uniquement lorsque la fonctionnalité de mise en file de lettres mortes est activée pour l’entité (file d’attente ou abonnement).

Comportements clés des messages différés

  • Les messages différés restent dans la file d’attente principale, et non dans un sous-file d’attente.
  • Vous devez utiliser le numéro de séquence du message pour récupérer un message différé.
  • Les messages différés peuvent être découverts par le biais de la navigation des messages (aperçu) .
  • Les messages différés n’expirent pas tant qu’un client ne tente pas de les recevoir.
  • La vérification de l’expiration se produit uniquement lorsqu’un client appelle une API de réception avec le numéro de séquence.

Étapes suivantes

Essayez les exemples dans le langage de votre choix pour explorer les fonctionnalités d’Azure Service Bus.

Contenu connexe

  • Last updated on