Share via

Berichten, nettoladingen en serialisatie

  • Artikel

Azure Service Bus verwerkt berichten. Berichten bevatten een nettolading en metagegevens. De metagegevens hebben de vorm van sleutel-waardeparen en beschrijven de nettolading en geven instructies voor Service Bus en toepassingen. Af en toe is die metagegevens voldoende om de informatie over te dragen die de afzender wil communiceren met ontvangers en blijft de nettolading leeg.

Het objectmodel van de officiële Service Bus-clients voor .NET en Java weerspiegelen de abstracte Service Bus-berichtstructuur, die is toegewezen aan en van de wire-protocollen die Service Bus ondersteunt.

Een Service Bus-bericht bestaat uit een sectie met binaire nettoladingen die Service Bus nooit verwerkt in een vorm aan de servicezijde en twee sets eigenschappen. De brokereigenschappen zijn vooraf gedefinieerd door het systeem. Deze vooraf gedefinieerde eigenschappen bepalen de functionaliteit op berichtniveau in de broker of ze worden toegewezen aan algemene en gestandaardiseerde metagegevensitems. De gebruikerseigenschappen zijn een verzameling sleutel-waardeparen die door de toepassing kunnen worden gedefinieerd en ingesteld.

De vooraf gedefinieerde brokereigenschappen worden weergegeven in de volgende tabel. De namen worden gebruikt met alle officiële client-API's en ook in het JSON-object BrokerProperties van de HTTP-protocoltoewijzing.

De equivalente namen die op het niveau van het AMQP-protocol worden gebruikt, worden tussen haakjes weergegeven. Hoewel de volgende namen pascalbehuizing gebruiken, moet u er rekening mee houden dat JavaScript- en Python-clients respectievelijk kameel- en slangbehuizing zouden gebruiken.

Eigenschapsnaam Omschrijving
ContentType (inhoudstype) Beschrijft eventueel de nettolading van het bericht, met een descriptor volgens de indeling van RFC2045, sectie 5; bijvoorbeeld application/json.
CorrelationId (correlatie-id) Hiermee kan een toepassing een context voor het bericht opgeven voor het doel van correlatie; Bijvoorbeeld door de MessageId weer te geven van een bericht waarop wordt gereageerd.
DeadLetterSource Alleen ingesteld in berichten die in de wachtrij met dode letters zijn geplaatst en later automatisch zijn doorgestuurd vanuit de wachtrij met dode letters naar een andere entiteit. Hiermee wordt de entiteit aangegeven waarin het bericht niet is geschreven. Deze eigenschap heeft het kenmerk Alleen-lezen.
DeliveryCount

Aantal leveringen dat is geprobeerd voor dit bericht. Het aantal wordt verhoogd wanneer een berichtvergrendeling verloopt of het bericht expliciet wordt afgelaten door de ontvanger. Deze eigenschap heeft het kenmerk Alleen-lezen.

Het aantal leveringen wordt niet verhoogd wanneer de onderliggende AMQP-verbinding wordt gesloten.
EnqueuedSequenceNumber Voor berichten die automatisch zijn doorgestuurd, geeft deze eigenschap het volgnummer weer dat voor het eerst aan het bericht was toegewezen op het oorspronkelijke tijdstip van indiening. Deze eigenschap heeft het kenmerk Alleen-lezen.
EnqueuedTimeUtc Het UTC-moment waarop het bericht is geaccepteerd en opgeslagen in de entiteit. Deze waarde kan worden gebruikt als gezaghebbende en neutrale aankomsttijdindicator wanneer de ontvanger de klok van de afzender niet wil vertrouwen. Deze eigenschap heeft het kenmerk Alleen-lezen.
Expires​AtUtc (absolute verlooptijd) Het UTC-moment waarop het bericht is gemarkeerd voor verwijdering en die niet meer beschikbaar is voor het ophalen van de entiteit vanwege de vervaldatum ervan. De vervaldatum wordt bepaald door de eigenschap TimeToLive en deze eigenschap wordt berekend vanuit EnqueuedTimeUtc+TimeToLive. Deze eigenschap heeft het kenmerk Alleen-lezen.
Label of Subject (onderwerp) Met deze eigenschap kan de toepassing het doel van het bericht op een gestandaardiseerde manier aangeven aan de ontvanger, vergelijkbaar met een onderwerpregel voor e-mail.
Locked​Until​Utc Voor berichten die zijn opgehaald onder een vergrendeling (peek-lock receive mode, niet vooraf ingesteld) weerspiegelt deze eigenschap het UTC-moment totdat het bericht is vergrendeld in de wachtrij/het abonnement. Wanneer de vergrendeling verloopt, wordt de DeliveryCount verhoogd en is het bericht opnieuw beschikbaar voor het ophalen. Deze eigenschap heeft het kenmerk Alleen-lezen.
Lock​Token Het vergrendelingstoken is een verwijzing naar de vergrendeling die wordt vastgehouden door de broker in de modus voor het ontvangen van een peek-lock . Het token kan worden gebruikt om de vergrendeling permanent vast te maken via de uitstel-API en daarmee het bericht uit de normale bezorgingsstatusstroom te halen. Deze eigenschap heeft het kenmerk Alleen-lezen.
Message​Id (message-id) De bericht-id is een door de toepassing gedefinieerde waarde waarmee het bericht en de nettolading uniek worden geïdentificeerd. De id is een vrije tekenreeks en kan een GUID of een id weerspiegelen die is afgeleid van de toepassingscontext. Indien ingeschakeld, identificeert en verwijdert de functie voor duplicaatdetectie de tweede en verdere verzending van berichten met dezelfde MessageId.
Partition​Key Voor gepartitioneerde entiteiten zorgt het instellen van deze waarde ervoor dat gerelateerde berichten aan dezelfde interne partitie worden toegewezen, zodat de volgorde van verzending correct wordt vastgelegd. De partitie wordt gekozen door een hash-functie voor deze waarde en kan niet rechtstreeks worden gekozen. Voor sessiebewuste entiteiten overschrijft de eigenschap SessionId deze waarde.
Reply​To (beantwoorden) Deze optionele en toepassingsgedefinieerde waarde is een standaardmethode om een antwoordpad uit te drukken naar de ontvanger van het bericht. Wanneer een afzender een antwoord verwacht, wordt de waarde ingesteld op het absolute of relatieve pad van de wachtrij of het onderwerp waarnaar het antwoord wordt verzonden.
Reply​To​Session​Id (reply-to-group-id) Deze waarde vergroot de replyTo-informatie en geeft aan welke SessionId moet worden ingesteld voor het antwoord wanneer deze naar de antwoordentiteit wordt verzonden.
Scheduled​Enqueue​Time​Utc Voor berichten die alleen na een vertraging beschikbaar worden gesteld voor het ophalen, definieert deze eigenschap het UTC-moment waarop het bericht logisch wordt geïnstueerd, gesequentieerd en daarom beschikbaar wordt gesteld voor ophalen.
Sequence​Number Het volgnummer is een uniek 64-bits geheel getal dat is toegewezen aan een bericht omdat het wordt geaccepteerd en opgeslagen door de broker en fungeert als de ware id. Voor gepartitioneerde entiteiten weerspiegelen de bovenste 16 bits de partitie-id. Reeksnummers nemen monotonisch toe en zijn tussenruimteloos. Ze rollen over naar 0 wanneer het 48-64-bits bereik is uitgeput. Deze eigenschap heeft het kenmerk Alleen-lezen.
Session​Id (groeps-id) Voor sessiebewuste entiteiten geeft deze toepassingsgedefinieerde waarde de sessierelatie van het bericht op. Berichten met dezelfde sessie-id zijn onderworpen aan samenvattingsvergrendeling en kunnen exact in-orderverwerking en demultiplexing inschakelen. Voor entiteiten die niet sessiebewust zijn, wordt deze waarde genegeerd.
Time​To​Live Deze waarde is de relatieve duur waarna het bericht verloopt, te beginnen vanaf het moment dat het is geaccepteerd en opgeslagen door de broker, zoals vastgelegd in EnqueueTimeUtc. Als deze waarde niet expliciet is ingesteld, is de veronderstelde waarde de DefaultTimeToLive voor de respectieve wachtrij of het betreffende onderwerp. Een TimeToLive-waarde op berichtniveau kan niet langer zijn dan de instelling DefaultTimeToLive van de entiteit. Als het langer is, wordt deze op de achtergrond aangepast.
To (aan) Deze eigenschap is gereserveerd voor toekomstig gebruik in routeringsscenario's en wordt momenteel genegeerd door de broker zelf. Toepassingen kunnen deze waarde gebruiken in regelgestuurde scenario's voor automatisch koppelen om de beoogde logische bestemming van het bericht aan te geven.
Via​Partition​Key Als een bericht wordt verzonden via een overdrachtswachtrij binnen het bereik van een transactie, selecteert deze waarde de overdrachtwachtrijpartitie.

Met het abstracte berichtmodel kan een bericht via HTTPS in een wachtrij worden geplaatst en kan worden opgehaald via AMQP. In beide gevallen ziet het bericht er normaal uit in de context van het respectieve protocol. De brokereigenschappen worden naar behoefte vertaald en de gebruikerseigenschappen worden toegewezen aan de meest geschikte locatie in het desbetreffende protocolberichtmodel. In HTTP worden gebruikerseigenschappen rechtstreeks toegewezen aan en van HTTP-headers; in AMQP worden ze toegewezen aan en van de kaart met toepassingseigenschappen .

Berichtroutering en correlatie

Een subset van de brokereigenschappen die eerder zijn beschreven, met name To, ReplyTo, ReplyToSessionId, MessageId, CorrelationIden SessionId, worden gebruikt om toepassingen te helpen berichten naar bepaalde bestemmingen te routeren. Bekijk een aantal patronen om deze functie te illustreren:

  • Eenvoudige aanvraag/antwoord: een uitgever verzendt een bericht naar een wachtrij en verwacht een antwoord van de gebruiker van het bericht. Voor het ontvangen van het antwoord is de uitgever eigenaar van een wachtrij waarin wordt verwacht dat antwoorden worden bezorgd. Het adres van de wachtrij wordt uitgedrukt in de eigenschap ReplyTo van het uitgaande bericht. Wanneer de consument reageert, wordt de MessageId van het afgehandelde bericht gekopieerd naar de eigenschap CorrelationId van het antwoordbericht en wordt het bericht bezorgd naar de bestemming die wordt aangegeven door de eigenschap ReplyTo . Eén bericht kan meerdere antwoorden opleveren, afhankelijk van de toepassingscontext.
  • Multicast-aanvraag/antwoord: als een variant van het voorgaande patroon verzendt een uitgever het bericht naar een onderwerp en komen meerdere abonnees in aanmerking om het bericht te gebruiken. Elk van de abonnees kan reageren op de manier die eerder is beschreven. Dit patroon wordt gebruikt in detectie- of roll-callscenario's en de respondent identificeert zichzelf meestal met een gebruikerseigenschap of binnen de nettolading. Als ReplyTo verwijst naar een onderwerp, kan een dergelijke set detectiereacties worden gedistribueerd naar een doelgroep.
  • Multiplexing: met deze sessiefunctie kunnen streams van gerelateerde berichten via één wachtrij of abonnement worden ge multiplexeerd, zodat elke sessie (of groep) gerelateerde berichten, geïdentificeerd door overeenkomende SessionId-waarden , worden doorgestuurd naar een specifieke ontvanger terwijl de ontvanger de sessie onder vergrendeling houdt. Lees hier meer over de details van sessies.
  • Multiplexed request/reply: Met deze sessiefunctie kunt u multiplexed antwoorden inschakelen, zodat verschillende uitgevers een antwoordwachtrij kunnen delen. Door ReplyToSessionId in te stellen, kan de uitgever de consument(en) instrueren die waarde te kopiëren naar de eigenschap SessionId van het antwoordbericht. De publicatiewachtrij of het onderwerp hoeft niet sessiebewust te zijn. Terwijl het bericht wordt verzonden, kan de uitgever vervolgens specifiek wachten tot een sessie met de opgegeven SessionId in de wachtrij wordt gerealiseerd door voorwaardelijk een sessieontvanger te accepteren.

Routering binnen een Service Bus-naamruimte kan worden gerealiseerd met behulp van regels voor automatisch doorsturen van ketens en onderwerpabonnementen. Routering tussen naamruimten kan worden gerealiseerd met behulp van Azure LogicApps. Zoals aangegeven in de vorige lijst, is de eigenschap Aan gereserveerd voor toekomstig gebruik en kan uiteindelijk worden geïnterpreteerd door de broker met een speciaal ingeschakelde functie. Toepassingen die routering willen implementeren, moeten dit doen op basis van gebruikerseigenschappen en niet op de eigenschap Aan leunen. Als u dit doet, veroorzaakt dit echter geen compatibiliteitsproblemen.

Serialisatie van nettolading

Wanneer de nettolading onderweg is of is opgeslagen in Service Bus, is de nettolading altijd een ondoorzichtig binair blok. Met ContentType de eigenschap kunnen toepassingen de nettolading beschrijven, met de voorgestelde indeling voor de eigenschapswaarden als een MIME-beschrijving van het inhoudstype volgens IETF-RFC2045, application/json;charset=utf-8bijvoorbeeld.

In tegenstelling tot de Java- of .NET Standard-varianten biedt de .NET Framework-versie van de Service Bus-API ondersteuning voor het maken van BrokeredMessage-exemplaren door willekeurige .NET-objecten door te geven aan de constructor.

Op 30 september 2026 gaan we de Azure Service Bus SDK-bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus en com.microsoft.azure.servicebus buiten gebruik stellen, die niet voldoen aan de Azure SDK-richtlijnen. We beëindigen ook de ondersteuning van het SBMP-protocol, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure SDK-bibliotheken, die vóór die datum essentiële beveiligingsupdates en verbeterde mogelijkheden bieden.

Hoewel de oudere bibliotheken nog steeds meer dan 30 september 2026 kunnen worden gebruikt, ontvangen ze geen officiële ondersteuning en updates meer van Microsoft. Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

Wanneer u het verouderde SBMP-protocol gebruikt, worden deze objecten vervolgens geserialiseerd met de standaard binaire serializer of met een serialisatiefunctie die extern wordt geleverd. Het object wordt geserialiseerd in een AMQP-object. De ontvanger kan deze objecten ophalen met de GetBody<T>() -methode, die het verwachte type levert. Met AMQP worden de objecten geserialiseerd in een AMQP-grafiek van ArrayList en IDictionary<string,object> objecten, en elke AMQP-client kan deze decoderen.

Op 30 september 2026 wordt de ondersteuning van het SBMP-protocol voor Azure Service Bus buiten gebruik gesteld, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure Service Bus SDK-bibliotheken met behulp van het AMQP-protocol, dat essentiële beveiligingsupdates en verbeterde mogelijkheden biedt, vóór die datum.

Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

Hoewel deze verborgen serialisatiemagie handig is, moeten toepassingen expliciet de controle over objectserialisatie overnemen en hun objectgrafieken omzetten in streams voordat ze in een bericht worden opgenomen en het omgekeerde aan de ontvangerzijde doen. Dit levert interoperabele resultaten op. Hoewel AMQP een krachtig binair coderingsmodel heeft, is het gekoppeld aan het AMQP-berichtenecosysteem en hebben HTTP-clients problemen met het decoderen van dergelijke nettoladingen.

De .NET Standard- en Java API-varianten accepteren alleen bytematrices, wat betekent dat de toepassing objectserialisatiebeheer moet verwerken.

Als de nettolading van een bericht niet kan worden gedeserialiseerd, wordt het aanbevolen om het bericht in een dode letter te schrijven.

Volgende stappen

Zie de volgende onderwerpen voor meer informatie over Service Bus Messaging: