Messages, charges utiles et sérialisation

  • Article

Le service Azure Service Bus traite les messages. Les messages contiennent une charge utile et des métadonnées. Les métadonnées sont présentes sous la forme de paires clé-valeur ; elles décrivent la charge utile et fournissent des instructions de traitement à Service Bus et aux applications. Il arrive que les métadonnées suffisent à elles seules à transporter les informations que l’expéditeur souhaite communiquer aux destinataires, et la charge utile reste donc vide.

Le modèle objet des clients Service Bus officiels pour .NET et Java reflète la structure abstraite des messages Service Bus, qui est mappée sur et depuis les protocoles de transmission pris en charge par Service Bus.

Un message Service Bus se compose d’une section de charge utile binaire que Service Bus ne traite jamais sous quelque forme que ce soit côté service, ainsi que de deux ensembles de propriétés. Les propriétés de répartiteur sont prédéfinies par le système. Ces propriétés prédéfinies contrôlent les fonctionnalités au niveau des messages à l’intérieur du répartiteur, ou sont mappées sur des éléments de métadonnées communs et normalisés. Les propriétés utilisateur sont une collection de paires clé-valeur qui peuvent être définies et configurées par l’application.

Les propriétés de répartiteur prédéfinies sont répertoriées dans le tableau ci-après. Les noms sont utilisés avec toutes les API clientes officielles, ainsi que dans l’objet JSON BrokerProperties du mappage de protocole HTTP.

Les noms équivalents utilisés au niveau du protocole AMQP sont répertoriés entre parenthèses. Si les noms suivants utilisent la casse Pascal, notez cependant que les clients JavaScript et Python utilisent respectivement la casse Camel et la casse Snake.

Nom de la propriété Description
ContentType (content-type) Cette propriété facultative décrit la charge utile du message, avec un descripteur conforme au format de RFC2045, Section 5, par exemple application/json.
CorrelationId (correlation-id) Cette propriété permet à une application de spécifier un contexte pour le message à des fins de corrélation, qui reflète par exemple l’élément MessageId d’un message recevant une réponse.
DeadLetterSource Cette propriété est uniquement définie dans les messages qui ont été placés dans la file d’attente de lettres mortes, puis automatiquement transférés à une autre entité à partir de cette file d’attente. Elle indique l’entité dans laquelle le message a été placé comme message de lettres mortes. Cette propriété est en lecture seule.
DeliveryCount

Cette propriété indique le nombre de tentatives de remise de ce message. Ce nombre est incrémenté lorsque le verrouillage d’un message arrive à expiration, ou que le message est explicitement abandonné par le destinataire. Cette propriété est en lecture seule.

Le nombre de remises n’est pas incrémenté lorsque la connexion AMQP sous-jacente est fermée.
EnqueuedSequenceNumber Dans le cas des messages qui ont été transférés automatiquement, cette propriété reflète le numéro de séquence qui avait été initialement attribué au message à son point d’envoi d’origine. Cette propriété est en lecture seule.
EnqueuedTimeUtc Cette propriété indique l’heure UTC à laquelle le message a été accepté et stocké dans l’entité. Cette valeur peut faire office d’indicateur d’heure d’arrivée de référence et neutre lorsque le destinataire ne souhaite pas se fier à l’horloge de l’expéditeur. Cette propriété est en lecture seule.
Expires​AtUtc (absolute-expiry-time) Cette propriété indique l’heure UTC à laquelle le message est marqué pour suppression et n’est plus récupérable à partir de l’entité en raison de son arrivée à expiration. L’arrivée à expiration est contrôlée par la propriété TimeToLive, et cette propriété est calculée à partir de la combinaison de propriétés EnqueuedTimeUtc+TimeToLive. Cette propriété est en lecture seule.
Label ou Subject (sujet) Cette propriété permet à l’application d’indiquer de façon normalisée au destinataire la finalité du message, tout comme la ligne Objet d’un e-mail.
Locked​Until​Utc Dans le cas des messages récupérés avec un verrouillage (mode de réception peek-lock, non préalablement réglé), cette propriété reflète l’heure UTC jusqu’à laquelle le message reste verrouillé dans la file d’attente / l’abonnement. Lorsque le verrouillage arrive à expiration, la propriété DeliveryCount est incrémentée, et le message redevient récupérable. Cette propriété est en lecture seule.
Lock​Token La valeur de jeton de verrouillage lock-token est une référence au verrouillage maintenu par le répartiteur en mode de réception peek-lock. Le jeton permet d’épingler définitivement le verrouillage par le biais de l’API Deferral et d’extraire ainsi le message du flux d’état de remise normale. Cette propriété est en lecture seule.
Message​Id (message-id) L’identificateur de message est une valeur définie par l’application qui identifie de manière unique le message et sa charge utile. Cet identificateur est une chaîne à structure libre et peut refléter un identificateur global unique (GUID) ou un identificateur dérivé du contexte de l’application. Si elle est activée, la fonctionnalité de détection des doublons identifie et supprime les envois ultérieurs des messages présentant la même valeur MessageId.
Partition​Key Dans le cas des entités partitionnées, la définition de cette valeur permet d’attribuer des messages associés à la même partition interne, afin que l’ordre de séquence d’envoi soit correctement enregistré. La partition est choisie par une fonction de hachage prioritaire sur cette valeur et ne peut pas être sélectionnée directement. Pour les entités prenant en charge la session, la propriété SessionId se substitue à cette valeur.
Reply​To (reply-to) Cette valeur facultative et définie par l’application est un moyen standard d’exprimer un chemin d’accès de réponse à l’intention du destinataire du message. Lorsqu’un expéditeur attend une réponse, cette propriété définit cette valeur sur le chemin d’accès absolu ou relatif de la file d’attente ou de la rubrique auxquelles la réponse doit être envoyée.
Reply​To​Session​Id (reply-to-group-id) Cette valeur incrémente l’information ReplyTo et spécifie la valeur SessionId qui doit être définie pour la réponse lors de son envoi à l’entité de réponse.
Scheduled​Enqueue​Time​Utc Dans le cas des messages qui ne deviennent récupérables qu’après un délai spécifique, cette propriété définit l’heure UTC à laquelle le message sera logiquement empilé, séquencé et rendu récupérable.
Sequence​Number Le numéro de séquence est un entier 64 bits unique attribué à un message lorsque celui-ci est accepté et stocké par le répartiteur, et fait office de véritable identificateur du message. Pour les entités partitionnées, les 16 premiers bits correspondent à l’identificateur de la partition. Les numéros de séquence augmentent de façon monotone et ininterrompue. Ils repassent à 0 lorsque la plage 48 à 64 bits est épuisée. Cette propriété est en lecture seule.
Session​Id (group-id) Dans le cas des entités prenant en charge la session, cette valeur définie par l’application spécifie l’affiliation de session du message. Les messages dotés du même identificateur de session sont soumis à un verrouillage du résumé et permettent un traitement et un démultiplexage chronologiques. Pour les entités qui ne prennent pas en charge la session, cette valeur est ignorée.
Time​To​Live Cette valeur indique la durée relative au terme de laquelle le message arrive à expiration, à partir du moment où il a été accepté et stocké par le répartiteur, tel que capturé dans la propriété EnqueueTimeUtc. Lorsque cette valeur n’est pas définie explicitement, la valeur prise en compte est celle du paramètre DefaultTimeToLive pour la file d’attente ou la rubrique concernées. La valeur TimeToLive au niveau du message ne peut pas dépasser celle du paramètre DefaultTimeToLive de l’entité. Si elle est plus longue, elle est automatiquement ajustée.
To (à) Cette propriété est réservée pour une utilisation ultérieure dans les scénarios de routage et est actuellement ignorée par le répartiteur proprement dit. Les applications peuvent utiliser cette valeur dans les scénarios de chaînage de transferts automatiques basés sur des règles afin d’indiquer la destination logique prévue du message.
Via​Partition​Key Si un message est envoyé par le biais d’une file d’attente de transfert dans l’étendue d’une transaction, cette valeur sélectionne la partition de file d’attente de transfert.

Le modèle de message abstrait permet de publier un message dans une file d’attente par l’intermédiaire du protocole HTTPS et de le récupérer à l’aide d’AMQP. Dans les deux cas, le message semble normal dans le contexte du protocole utilisé. Les propriétés du répartiteur sont traduites en fonction des besoins, et les propriétés utilisateur sont mappées sur l’emplacement le plus approprié du modèle de message du protocole associé. En HTTP, les propriétés utilisateur sont directement mappées sur et depuis les en-têtes HTTP ; en AMQP, elles sont mappées sur et depuis le mappage application-properties.

Routage et corrélation des messages

Certaines des propriétés de répartiteur décrites ci-dessus, plus précisément To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId et SessionId, sont conçues pour aider les applications à router les messages vers des destinations spécifiques. Pour illustrer cette fonctionnalité, considérons quelques modèles :

  • Requête/réponse simple : Un serveur de publication envoie un message dans une file d’attente et attend une réponse du consommateur du message. Pour recevoir la réponse, le serveur de publication dispose d’une file d’attente à laquelle les réponses doivent être remises. L’adresse de la file d’attente est exprimée dans la propriété ReplyTo du message sortant. Lorsque le consommateur répond, la valeur MessageId du message traité est copiée dans la propriété CorrelationId du message de réponse, et le message est remis à la destination indiquée par la propriété ReplyTo. Selon le contexte de l’application, un même message peut entraîner plusieurs réponses.
  • Demande/réponse de multidiffusion : en guise de variante du modèle précédent, un éditeur envoie le message dans une rubrique et plusieurs abonnés deviennent éligibles pour utiliser le message. Chacun de ces abonnés peut répondre de la manière précédemment décrite. Ce modèle est utilisé dans les scénarios de détection ou de liste d’appel, et le répondant s’identifie généralement avec une propriété utilisateur ou dans la charge utile. Si la propriété ReplyTo pointe vers une rubrique, cet ensemble de réponses de détection peut être distribué à une audience.
  • Multiplexage : Cette fonctionnalité de session permet de multiplexer des flux de messages associés par le biais d’une file d’attente ou d’un abonnement uniques, de sorte que chaque session (ou groupe) de messages associés, identifiée par des valeurs SessionId correspondantes, soit routée vers un destinataire spécifique pendant que ce dernier maintient sa session verrouillée. Pour plus d’informations sur les détails des sessions, consultez cet article.
  • Requête/réponse multiplexée : Cette fonctionnalité de session autorise le multiplexage des réponses et permet ainsi à plusieurs serveurs de publication de partager une file d’attente de réponse. En définissant la propriété ReplyToSessionId, le serveur de publication peut demander aux consommateurs de copier cette valeur dans la propriété SessionId du message de réponse. La file d’attente ou la rubrique de publication n’ont pas besoin de prendre en charge la session. Une fois le message envoyé, le moteur de publication peut alors attendre spécifiquement qu’une session présentant la valeur SessionId correspondante se matérialise sur la file d’attente en acceptant de manière conditionnelle un destinataire de session.

Le routage à l’intérieur d’un espace de noms Service Bus peut être effectué à l’aide de règles de chaînage de transferts automatiques et d’abonnement aux rubriques. Le routage au sein des espaces de noms est réalisable par l’intermédiaire d’Azure Logic Apps. Comme indiqué dans la liste précédente, la propriété To est réservée pour une utilisation ultérieure et peut finalement être interprétée par le répartiteur avec une fonctionnalité activée spécialement. Les applications destinées à implémenter le routage doivent effectuer cette opération à l’aide des propriétés utilisateur plutôt qu’en s’appuyant sur la propriété To ; toutefois, le choix de cette dernière solution n’entraîne plus de problèmes de compatibilité.

Sérialisation de la charge utile

Lorsque la charge utile est en transit ou stockée à l’intérieur de Service Bus, elle constitue toujours un bloc binaire opaque. La propriété ContentType permet aux applications de décrire la charge utile, et le format recommandé pour les valeurs de cette propriété est une description Content-Type MIME conforme à IETF RFC2045, par exemple application/json;charset=utf-8.

Contrairement aux variantes Java ou .NET Standard, la version .NET Framework de l’API Service Bus prend en charge la création d’instances BrokeredMessage en transmettant des objets .NET arbitraires dans le constructeur.

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.

Si vous utilisez le protocole SBMP hérité, ces objets sont sérialisés avec le sérialiseur binaire par défaut ou avec un sérialiseur fourni en externe. L’objet est sérialisé dans un objet AMQP. Le récepteur peut récupérer ces objets avec la méthode GetBody<T>(), en fournissant le type attendu. Avec AMQP, les objets sont sérialisés dans un graphique AMQP d’objets ArrayList et IDictionary<string,object> , et n’importe quel client AMQP peut les décoder.

Le 30 septembre 2026, nous mettrons fin à la prise en charge du protocole SBMP pour Azure Service Bus. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du SDK Azure Service Bus utilisant le protocole AMQP, qui offre des mises à jour de sécurité critiques et des fonctionnalités améliorées, avant cette date.

Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Bien que cette sérialisation cachée se révèle commode, les applications doivent contrôler explicitement la sérialisation des objets et convertir leurs graphiques d’objets en flux avant de les inclure dans un message, ainsi qu’effectuer l’opération inverse côté destinataire. Ceci entraîne des résultats interopérables. Bien qu’AMQP dispose d’un modèle d’encodage binaire très puissant, il est lié à l’écosystème de messagerie AMQP, et les clients HTTP auront donc des difficultés à décoder les charges utiles de ce type.

Les variantes d’API .NET Standard et Java acceptent uniquement les tableaux d’octets, ce qui signifie que l’application doit gérer le contrôle de sérialisation des objets.

Si la charge utile d’un message ne peut pas être désérialisée, il est recommandé de mettre en lettres mortes le message.

Étapes suivantes

Pour plus d’informations sur la messagerie Service Bus, consultez les articles suivants :