Report de message
Lorsqu’un client de file d’attente ou d’abonnement reçoit un message qu’il souhaite traiter, mais que le traitement n’est pas possible actuellement en raison de circonstances particulières, il a la possibilité de « reporter » la récupération du message. Le message est conservé dans la file d’attente ou l’abonnement, mais il est mis de côté.
Remarque
Les messages différés n’ont pas expiré et sont automatiquement déplacés vers 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 normal. Lorsqu’un client tente de récupérer un message différé, il est vérifié pour s’assurer qu’il n’a pas expiré, puis déplacé vers une file d’attente de lettres mortes s’il a déjà expiré. Un message arrivé à expiration est déplacé vers une sous-file d’attente de lettres mortes uniquement lorsque la fonctionnalité de lettres mortes est activée pour l’entité (file d’attente ou abonnement).
Exemples de scénarios
Le report est une fonctionnalité créée spécifiquement pour des scénarios de traitement de workflows. Les infrastructures de flux de travail peuvent nécessiter que certaines opérations soient traitées dans un ordre particulier. Elles peuvent être amenées à retarder le traitement de certains messages reçus jusqu’à ce que le travail antérieur prescrit, informé par d’autres messages, soit terminé.
Un exemple simple illustrant cela est une séquence de traitement d’une commande dans laquelle une notification de paiement provenant d’un fournisseur de paiement externe s’affiche dans un système avant que le bon de commande associé ait été transmis du magasin au système de traitement. Dans ce cas, le système de traitement peut reporter le traitement de la notification de paiement jusqu’à ce qu’une commande y soit associée. Dans les scénarios de rendez-vous, dans lesquels des messages provenant de différentes sources font avancer un flux de travail, l’ordre d’exécution en temps réel peut effectivement être correct, mais les messages reflétant les résultats peuvent arriver dans le désordre.
Enfin, le report permet de faciliter la réorganisation des messages, de leur ordre d’arrivée à l’ordre dans lequel ils peuvent être traités, tout en laissant en toute sécurité ces messages (dont le traitement doit être différé) dans le magasin de messages.
Si un message ne peut pas être traité en raison de l’indisponibilité temporaire d’une ressource nécessaire au traitement de ce message, mais que le traitement du message ne doit pas être sommairement interrompu, un moyen pour mettre le message de côté pendant quelques minutes consiste à se souvenir du numéro de séquence dans un message planifié qui sera publié après quelques minutes, puis à récupérer le message reporté 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, il ne doit pas utiliser le report, mais plutôt interrompre complètement la réception des messages jusqu’à ce que la base de données soit à nouveau disponible.
Récupération des messages reportés
Les messages reportés restent dans la file d’attente principale avec tous les autres messages actifs (contrairement aux messages de type lettres mortes qui se trouvent dans une sous-file d’attente), mais ils ne peuvent plus être reçus à l’aide des opérations de réception habituelles. Les messages reportés peuvent être découverts via la navigation ou l’aperçu des messages ou si une application perd leur trace.
Pour récupérer un message différé, son propriétaire doit se souvenir du numéro de séquence au moment du report. Tout destinataire qui connaît le numéro de séquence d’un message reporté peut ultérieurement recevoir le message en utilisant les 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 et horodatage des messages.
Étapes suivantes
Essayez les exemples dans le langage de votre choix pour explorer les fonctionnalités d’Azure Service Bus.
- Exemples de bibliothèque de client Azure Service Bus pour .NET (dernière version) : Voir l’exemple Règlement des messages.
- Exemples de bibliothèque de client Azure Service Bus pour Java (dernière version)
- Exemples de bibliothèque de client Azure Service Bus pour Python : Voir l’exemple receive_deferred_message_queue.py.
- Exemples de bibliothèque de client Azure Service Bus pour JavaScript : Voir l’exemple advanced/deferral.js.
- Exemples de bibliothèque de client Azure Service Bus pour TypeScript : Voir l’exemple advanced/deferral.ts.
Consultez ici des exemples pour les anciennes bibliothèques de client .NET et Java :
- Exemples de bibliothèque de client Azure Service Bus pour .NET (version héritée) : Voir l’exemple Deferral.
- Exemples de bibliothèque de client Azure Service Bus pour Java (version héritée)
Le 30 septembre 2026, nous retirerons les bibliothèques WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus et com.microsoft.azure.servicebus du kit de développement logiciel (SDK) Azure Service Bus, qui ne sont pas conformes aux directives du kit de développement logiciel (SDK) Azure. Nous mettrons également fin à la prise en charge du protocole SBMP. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du kit de développement logiciel (SDK) Azure, qui offre des correctifs de sécurité critiques et des fonctionnalités améliorées, avant cette date.
Bien que les anciennes bibliothèques puissent toujours être utilisées au-delà du 30 septembre 2026, elles ne seront plus prises en charge officiellement et mises à jour par Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.