Meddelanden, nyttolaster och serialisering
Azure Service Bus hanterar meddelanden. Meddelanden har en nyttolast och metadata. Metadata är i form av nyckel/värde-par och beskriver nyttolasten och ger hanteringsinstruktioner till Service Bus och program. Ibland räcker enbart dessa metadata för att överföra den information som avsändaren vill kommunicera med mottagare och nyttolasten förblir tom.
Objektmodellen för de officiella Service Bus-klienterna för .NET och Java återspeglar den abstrakta Service Bus-meddelandestrukturen, som mappas till och från de trådprotokoll som Service Bus stöder.
Ett Service Bus-meddelande består av ett binärt nyttolastavsnitt som Service Bus aldrig hanterar i något formulär på tjänstsidan och två uppsättningar egenskaper. Egenskaperna för asynkron meddelandekö är fördefinierade av systemet. Dessa fördefinierade egenskaper styr antingen funktionerna på meddelandenivå i asynkron meddelandekö eller mappar till vanliga och standardiserade metadataobjekt. Användaregenskaperna är en samling nyckel/värde-par som kan definieras och anges av programmet.
De fördefinierade asynkrona asynkrona egenskaperna visas i följande tabell. Namnen används med alla officiella klient-API:er och även i BrokerProperties JSON-objektet för HTTP-protokollmappningen.
Motsvarande namn som används på protokollnivån Advanced Message Queuing Protocol (AMQP) visas inom parenteser. Även om följande namn använder pascalhölje skulle JavaScript- och Python-klienter använda kamel- respektive ormhölje.
| Egenskapsnamn | beskrivning |
|---|---|
ContentType (content-type) |
Du kan också beskriva nyttolasten för meddelandet med en beskrivning som följer formatet för RFC2045, avsnitt 5; till exempel application/json. |
CorrelationId (correlation-id) |
Gör att ett program kan ange en kontext för meddelandet i samband med korrelation. till exempel, som återspeglar MessageId för ett meddelande som besvaras. |
DeadLetterSource |
Ange endast i meddelanden som har varit obeställbara och senare automatiskt från kön med obeställbara meddelanden till en annan entitet. Anger entiteten där meddelandet var obeställt. Den här egenskapen är skrivskyddad. |
DeliveryCount |
Antal leveranser som har försökts för det här meddelandet. Antalet ökas när ett meddelandelås upphör att gälla, eller så avbryts meddelandet uttryckligen av mottagaren. Den här egenskapen är skrivskyddad. Leveransantalet ökas inte när den underliggande AMQP-anslutningen stängs. |
EnqueuedSequenceNumber |
För meddelanden som har autoforwardats återspeglar den här egenskapen det sekvensnummer som först hade tilldelats meddelandet vid den ursprungliga sändningspunkten. Den här egenskapen är skrivskyddad. |
EnqueuedTimeUtc |
UTC-ögonblick då meddelandet har accepterats och lagrats i entiteten. Det här värdet kan användas som en auktoritativ och neutral ankomsttidsindikator när mottagaren inte vill lita på avsändarens klocka. Den här egenskapen är skrivskyddad. |
ExpiresAtUtc (absolute-expiry-time) |
UTC-ögonblick då meddelandet har markerats för borttagning och inte längre är tillgängligt för hämtning från entiteten på grund av dess upphörande. Förfallodatum styrs av egenskapen TimeToLive och den här egenskapen beräknas från EnqueuedTimeUtc+TimeToLive. Den här egenskapen är skrivskyddad. |
Label eller Subject (subject) |
Med den här egenskapen kan programmet ange syftet med meddelandet till mottagaren på ett standardiserat sätt, ungefär som en ämnesrad för e-post. |
LockedUntilUtc |
För meddelanden som hämtas under ett lås (peek-lock-mottagningsläge, inte förinställt) återspeglar den här egenskapen UTC-ögonblicket tills meddelandet hålls låst i kön/prenumerationen. När låset upphör att gälla ökas DeliveryCount och meddelandet är återigen tillgängligt för hämtning. Den här egenskapen är skrivskyddad. |
LockToken |
Låstoken är en referens till låset som hålls av mäklaren i mottagningsläge för peek-lock . Token kan användas för att fästa låset permanent via DEFERRAL-API:et och därmed ta meddelandet ur det vanliga leveranstillståndsflödet. Den här egenskapen är skrivskyddad. |
MessageId (message-id) |
Meddelandeidentifieraren är ett programdefinierat värde som unikt identifierar meddelandet och dess nyttolast. Identifieraren är en friformssträng och kan återspegla ett GUID eller en identifierare som härleds från programkontexten. Om aktiverad identifierar och tar dubblettidentifieringsfunktionen bort andra och ytterligare inskickade meddelanden med samma MessageId. |
PartitionKey |
Om du anger det här värdet för partitionerade entiteter kan relaterade meddelanden tilldelas till samma interna partition, så att sekvensordningen för överföring registreras korrekt. Partitionen väljs av en hash-funktion framför det här värdet och kan inte väljas direkt. För sessionsmedvetna entiteter åsidosätter egenskapen SessionId det här värdet. |
ReplyTo (reply-to) |
Det här valfria och programdefinierade värdet är ett standardsätt för att uttrycka en svarssökväg till mottagaren av meddelandet. När en avsändare förväntar sig ett svar anges värdet till den absoluta eller relativa sökvägen för kön eller ämnet som den förväntar sig att svaret ska skickas till. |
ReplyToSessionId (reply-to-group-id) |
Det här värdet ökar ReplyTo-informationen och anger vilket SessionId som ska anges för svaret när det skickas till svarsentiteten. |
ScheduledEnqueueTimeUtc |
För meddelanden som endast görs tillgängliga för hämtning efter en fördröjning definierar den här egenskapen UTC-omedelbart där meddelandet kommer att vara logiskt anget, sekvenserat och därför tillgängligt för hämtning. |
SequenceNumber |
Sekvensnumret är ett unikt 64-bitars heltal som tilldelats ett meddelande eftersom det accepteras och lagras av asynkron meddelandekö och fungerar som dess sanna identifierare. För partitionerade entiteter återspeglar de översta 16 bitarna partitionsidentifieraren. Sekvensnummer ökar monotont och är gaplösa. De rullar över till 0 när 48-64-bitarsintervallet är uttömt. Den här egenskapen är skrivskyddad. |
SessionId (group-id) |
För sessionsmedvetna entiteter anger det här programdefinierade värdet sessionstillhörigheten för meddelandet. Meddelanden med samma sessionsidentifierare omfattas av sammanfattningslåsning och möjliggör exakt bearbetning i ordning och demultiplexing. För entiteter som inte är sessionsmedvetna ignoreras det här värdet. |
TimeToLive |
Det här värdet är den relativa varaktigheten efter vilken meddelandet upphör att gälla, från och med det ögonblick då det har accepterats och lagrats av asynkron meddelandekö, enligt vyn i EnqueueTimeUtc. När det inte anges explicit är det antagna värdet DefaultTimeToLive för respektive kö eller ämne. Ett TimeToLive-värde på meddelandenivå får inte vara längre än entitetens DefaultTimeToLive-inställning. Om den är längre justeras den tyst. |
To (to) |
Den här egenskapen är reserverad för framtida användning i routningsscenarier och ignoreras för närvarande av själva koordinatorn. Program kan använda det här värdet i regeldrivna autoforward-länkningsscenarier för att ange meddelandets avsedda logiska mål. |
ViaPartitionKey |
Om ett meddelande skickas via en överföringskö i omfånget för en transaktion väljer det här värdet partitionen för överföringskö. |
Den abstrakta meddelandemodellen gör att ett meddelande kan publiceras i en kö via HTTPS och kan hämtas via AMQP. I båda fallen ser meddelandet normalt ut i kontexten för respektive protokoll. Egenskaperna för koordinatorn översätts efter behov och användaregenskaperna mappas till den lämpligaste platsen för respektive protokollmeddelandemodell. I HTTP mappas användaregenskaper direkt till och från HTTP-huvuden. i AMQP mappar de till och från kartan application-properties .
Meddelanderoutning och korrelation
En delmängd av egenskaperna för koordinatorn som beskrevs tidigare, specifikt To, ReplyTo, ReplyToSessionId, MessageIdCorrelationId, och SessionId, används för att hjälpa program att dirigera meddelanden till specifika mål. För att illustrera den här funktionen bör du överväga några mönster:
- Enkel begäran/svar: En utgivare skickar ett meddelande till en kö och förväntar sig ett svar från meddelandekonsumenten. För att få svaret äger utgivaren en kö där den förväntar sig att svar ska levereras. Köns adress uttrycks i egenskapen ReplyTo för det utgående meddelandet. När konsumenten svarar kopierar den MessageId för det hanterade meddelandet till egenskapen CorrelationId för svarsmeddelandet och levererar meddelandet till det mål som anges av egenskapen ReplyTo . Ett meddelande kan ge flera svar, beroende på programkontexten.
- Multicast-begäran/svar: Som en variant av det tidigare mönstret skickar en utgivare meddelandet till ett ämne och flera prenumeranter blir berättigade att använda meddelandet. Var och en av prenumeranterna kan svara på det sätt som beskrevs tidigare. Det här mönstret används i identifierings- eller uppropsscenarier och respondenten identifierar sig vanligtvis med en användaregenskap eller inuti nyttolasten. Om ReplyTo pekar på ett ämne kan en sådan uppsättning identifieringssvar distribueras till en målgrupp.
- Multiplexering: Den här sessionsfunktionen möjliggör multiplexering av strömmar av relaterade meddelanden via en enda kö eller prenumeration, så att varje session (eller grupp) med relaterade meddelanden, som identifieras med matchande SessionId-värden , dirigeras till en specifik mottagare medan mottagaren håller sessionen låst. Läs mer om information om sessioner här.
- Multiplexerad begäran/svar: Den här sessionsfunktionen aktiverar multiplexade svar, vilket gör att flera utgivare kan dela en svarskö. Genom att ange ReplyToSessionId kan utgivaren instruera konsumenterna att kopiera värdet till egenskapen SessionId för svarsmeddelandet. Publiceringskön eller ämnet behöver inte vara sessionsmedveten. När meddelandet skickas kan utgivaren sedan specifikt vänta på att en session med det angivna SessionId ska materialiseras i kön genom att villkorligt acceptera en sessionsmottagare.
Routning i ett Service Bus-namnområde kan genomföras med hjälp av regler för automatisk länkning och ämnesprenumeration. Routning mellan namnområden kan realiseras med hjälp av Azure LogicApps. Som anges i föregående lista är egenskapen Till reserverad för framtida användning och kan så småningom tolkas av mäklaren med en särskilt aktiverad funktion. Program som vill implementera routning bör göra det baserat på användaregenskaper och inte luta sig mot egenskapen Till . Men om du gör det nu orsakas inte kompatibilitetsproblem.
Serialisering av nyttolast
När nyttolasten överförs eller lagras i Service Bus är den alltid ett täckande binärt block. Egenskapen ContentType gör det möjligt för program att beskriva nyttolasten, där det föreslagna formatet för egenskapsvärdena är en beskrivning av MIME-innehållstyp enligt IETF-RFC2045, application/json;charset=utf-8till exempel .
Till skillnad från Java- eller .NET Standard-varianterna har .NET Framework-versionen av Service Bus-API:et stöd för att skapa BrokeredMessage-instanser genom att skicka godtyckliga .NET-objekt till konstruktorn.
Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.
Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.
När du använder det äldre SBMP-protokollet serialiseras dessa objekt sedan med standard binär serialiserare eller med en serialiserare som tillhandahålls externt. Objektet serialiseras till ett AMQP-objekt. Mottagaren kan hämta dessa objekt med GetBody\<T>() metoden och ange den förväntade typen. Med AMQP serialiseras objekten till en AMQP-graf över ArrayList och IDictionary<string,object> objekt, och alla AMQP-klienter kan avkoda dem.
Den 30 september 2026 drar vi tillbaka stödet för SBMP-protokollet för Azure Service Bus, så att du inte längre kan använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure Service Bus SDK-biblioteken med hjälp av AMQP-protokollet, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.
Även om den här dolda serialiseringsmagien är praktisk bör program ta explicit kontroll över objektserialisering och omvandla objektdiagram till strömmar innan de inkluderas i ett meddelande och göra det omvända på mottagarsidan. Detta ger samverkande resultat. AMQP har en kraftfull binär kodningsmodell, men den är knuten till AMQP-meddelandeekosystemet och HTTP-klienter har problem med att avkoda sådana nyttolaster.
.NET Standard- och Java API-varianterna accepterar endast bytematriser, vilket innebär att programmet måste hantera objektserialiseringskontroll.
När du hanterar objektdeserialisering från meddelandenyttolasten bör utvecklare ta hänsyn till att meddelanden kan komma från flera källor med olika serialiseringsmetoder. Detta kan också inträffa när du utvecklar ett enda program, där gamla versioner kan fortsätta att köras tillsammans med nyare versioner. I dessa fall rekommenderar vi att du har ytterligare deserialiseringsmetoder att prova om det första försöket till deserialisering misslyckas. Ett bibliotek som stöder detta är NServiceBus. Om alla deserialiseringsmetoder misslyckas rekommenderar vi att meddelandet skrivs utan bokstav.
Nästa steg
Mer information om Service Bus-meddelanden finns i följande avsnitt: