Sdílet prostřednictvím

Zprávy, datové části a serializace

  • Článek

Azure Service Bus zpracovává zprávy. Zprávy obsahují datovou část a metadata. Metadata jsou ve formě párů klíč-hodnota a popisují datovou část a poskytují pokyny ke zpracování služby Service Bus a aplikacím. Tato metadata jsou někdy dostatečná k přenosu informací, které odesílatel chce sdělit příjemcům, a datová část zůstane prázdná.

Objektový model oficiálního klienta Service Bus pro .NET a Javu odráží abstraktní strukturu zpráv Service Bus, která je mapována na protokoly drátů, které Service Bus podporuje.

Zpráva služby Service Bus se skládá z oddílu binární datové části, kterou Service Bus nikdy nezpracuje v žádném formuláři na straně služby, a dvě sady vlastností. Vlastnosti zprostředkovatele jsou předdefinovány systémem. Tyto předdefinované vlastnosti řídí funkce na úrovni zpráv uvnitř zprostředkovatele nebo se mapují na běžné a standardizované položky metadat. Vlastnosti uživatele jsou kolekce párů klíč-hodnota, které lze definovat a nastavit aplikací.

Předdefinované vlastnosti zprostředkovatele jsou uvedeny v následující tabulce. Názvy se používají se všemi oficiálními klientskými rozhraními API a také v objektu BrokerProperties JSON mapování protokolu HTTP.

Ekvivalentní názvy použité na úrovni protokolu AMQP jsou uvedeny v závorkách. I když následující názvy používají písmena pascal, mějte na paměti, že javascript a python klienti by používali camel a had casing v uvedeném pořadí.

Název vlastnosti Popis
ContentType (typ obsahu) Volitelně popisuje datovou část zprávy s popisovačem podle formátu RFC2045 oddílu 5; například application/json.
CorrelationId (ID korelace) Umožňuje aplikaci určit kontext zprávy pro účely korelace; Například reflektující ID zprávy, na kterou se odpovídá.
DeadLetterSource Nastaveno pouze ve zprávách, které byly nedoručené a později automaticky převedené z fronty nedoručených zpráv do jiné entity. Označuje entitu, ve které byla zpráva nedoručována. Tato vlastnost je jen ke čtení.
DeliveryCount

Počet dodávek, o které se tato zpráva pokusila. Počet se zvýší, když vyprší platnost zámku zprávy nebo příjemce zprávu explicitně opustí. Tato vlastnost je jen ke čtení.

Při zavření základního připojení AMQP se počet doručení nezvýší.
EnqueuedSequenceNumber U zpráv, které byly automaticky přeforwardovány, tato vlastnost odráží pořadové číslo, které bylo poprvé přiřazeno ke zprávě v původním okamžiku odeslání. Tato vlastnost je jen ke čtení.
EnqueuedTimeUtc Okamžitě ve standardu UTC, ve kterém byla zpráva přijata a uložena v entitě. Tuto hodnotu lze použít jako autoritativní a neutrální indikátor času doručení, pokud příjemce nechce důvěřovat hodině odesílatele. Tato vlastnost je jen ke čtení.
Expires​AtUtc (absolutní doba vypršení platnosti) Okamžitě ve standardu UTC, ve kterém je zpráva označena k odebrání a již není k dispozici pro načtení z entity kvůli vypršení platnosti. Vypršení platnosti je řízeno TimeToLive vlastnost a tato vlastnost je vypočítána z EnqueuedTimeUtc+TimeToLive. Tato vlastnost je jen ke čtení.
Label nebo Subject (předmět) Tato vlastnost umožňuje aplikaci indikovat účel zprávy příjemci standardizovaným způsobem, podobně jako řádek předmětu e-mailu.
Locked​Until​Utc U zpráv načtených pod zámkem (režim příjmu peek-lock, bez přednastavení) tato vlastnost odráží okamžitou dobu UTC, dokud se zpráva neudržuje ve frontě nebo odběru. Po vypršení platnosti zámku se zvýší počet doručení a zpráva bude opět k dispozici pro načtení. Tato vlastnost je jen ke čtení.
Lock​Token Zámek tokenu je odkazem na zámek, který zprostředkovatel uchovává v režimu příjmu peek-lock . Token lze použít k trvalému připnutí zámku prostřednictvím rozhraní Deferral API a s tím vynechejte zprávu z běžného toku stavu doručení. Tato vlastnost je jen ke čtení.
Message​Id (message-id) Identifikátor zprávy je hodnota definovaná aplikací, která jednoznačně identifikuje zprávu a její datovou část. Identifikátor je řetězec volného formuláře a může odrážet identifikátor GUID nebo identifikátor odvozený z kontextu aplikace. Pokud je tato možnost povolená, funkce detekce duplicit identifikuje a odebere druhé a další odeslání zpráv se stejným ID zprávy.
Partition​Key U dělených entit umožňuje nastavení této hodnoty přiřazení souvisejících zpráv ke stejnému internímu oddílu, aby bylo správně zaznamenáno pořadí odeslání. Oddíl je zvolen funkcí hash nad touto hodnotou a nelze ho vybrat přímo. U entit pracujících s relacemi vlastnost SessionId tuto hodnotu přepíše.
Reply​To (odpovědět) Tato volitelná hodnota a hodnota definovaná aplikací je standardní způsob vyjádření cesty odpovědi příjemci zprávy. Když odesílatel očekává odpověď, nastaví hodnotu na absolutní nebo relativní cestu fronty nebo tématu, na kterou očekává odeslání odpovědi.
Reply​To​Session​Id (reply-to-group-id) Tato hodnota rozšiřuje informace ReplyTo a určuje, které Id relace se má nastavit pro odpověď při odeslání do entity odpovědi.
Scheduled​Enqueue​Time​Utc U zpráv, které jsou k dispozici pouze pro načtení po zpoždění, tato vlastnost definuje instanci UTC, ve které bude zpráva logicky zařazována, sekvencována a tudíž zpřístupněna pro načtení.
Sequence​Number Pořadové číslo je jedinečné 64bitové celé číslo přiřazené ke zprávě, protože je přijato a uloženo zprostředkovatelem a funguje jako jeho skutečný identifikátor. U dělených entit odráží identifikátor oddílu nejvíce 16 bitů. Pořadová čísla se monotonicky zvětšují a jsou bez mezer. Při vyčerpání 48-64bitového rozsahu se převrácejí na 0. Tato vlastnost je jen ke čtení.
Session​Id (ID skupiny) U entit pracujících s relacemi určuje tato hodnota definovaná aplikací přidružení relace zprávy. Zprávy se stejným identifikátorem relace podléhají souhrnnému uzamčení a umožňují přesné zpracování v pořadí a demultiplexování. U entit, které nepodporují relaci, se tato hodnota ignoruje.
Time​To​Live Tato hodnota je relativní doba trvání, po které vyprší platnost zprávy, počínaje okamžikem, kdy byla přijata a uložena zprostředkovatelem, jak je zachyceno v EnqueueTimeUtc. Pokud není nastaven explicitně, předpokládaná hodnota je DefaultTimeToLive pro příslušnou frontu nebo téma. Hodnota TimeToLive na úrovni zprávy nemůže být delší než nastavení DefaultTimeToLive entity. Pokud je delší, je bezobslužná.
To (do) Tato vlastnost je vyhrazena pro budoucí použití ve scénářích směrování a aktuálně ignorována samotným zprostředkovatelem. Aplikace můžou tuto hodnotu použít ve scénářích automatického řetězení řízeného pravidlem k označení zamýšleného logického cíle zprávy.
Via​Partition​Key Pokud je zpráva odeslána prostřednictvím fronty přenosu v oboru transakce, tato hodnota vybere oddíl přenosové fronty.

Abstraktní model zpráv umožňuje, aby se zpráva publikovala do fronty prostřednictvím PROTOKOLU HTTPS a dá se načíst prostřednictvím AMQP. V obou případech zpráva vypadá normálně v kontextu příslušného protokolu. Vlastnosti zprostředkovatele se přeloží podle potřeby a vlastnosti uživatele se mapují na nejvhodnější umístění v příslušném modelu zpráv protokolu. V PROTOKOLU HTTP se vlastnosti uživatelů mapují přímo na hlavičky HTTP a z hlavičky HTTP; v AMQP mapují na a z mapy vlastností aplikace.

Směrování zpráv a korelace

Podmnožina vlastností zprostředkovatele popsaných výše, konkrétně ToReplyTo, , ReplyToSessionIdMessageId, CorrelationId, a SessionId, slouží k tomu, aby aplikace směrovala zprávy do konkrétních cílů. Pro ilustraci této funkce zvažte několik vzorů:

  • Jednoduchý požadavek/odpověď: Vydavatel odešle zprávu do fronty a očekává odpověď od příjemce zprávy. Pokud chcete odpověď přijmout, vydavatel vlastní frontu, do které očekává doručení odpovědí. Adresa fronty je vyjádřena ve vlastnosti ReplyTo odchozí zprávy. Když příjemce odpoví, zkopíruje MessageId zpracovávané zprávy do vlastnosti CorrelationId zprávy odpovědi a doručí zprávu do cíle označeného vlastností ReplyTo. Jedna zpráva může v závislosti na kontextu aplikace přinést více odpovědí.
  • Žádost/odpověď vícesměrového vysílání: Jako varianta předchozího vzoru odešle vydavatel zprávu do tématu a více odběratelů může zprávu využívat. Každý z odběratelů může reagovat způsobem popsaným výše. Tento model se používá ve scénářích zjišťování nebo roll-call a respondent se obvykle identifikuje pomocí vlastnosti uživatele nebo uvnitř datové části. Pokud replyTo odkazuje na téma, může být taková sada odpovědí zjišťování distribuována cílové skupině.
  • Multiplexing: Tato funkce relace umožňuje multiplexování datových proudů souvisejících zpráv prostřednictvím jedné fronty nebo odběru, aby každá relace (nebo skupina) souvisejících zpráv identifikovaná odpovídajícími hodnotami SessionId byla směrována konkrétnímu příjemci, zatímco příjemce uchovává relaci pod zámkem. Další informace o relacích najdete tady.
  • Multiplexed request/reply: Tato funkce relace umožňuje multiplexované odpovědi, což umožňuje několika vydavatelům sdílet frontu odpovědí. Nastavením ReplyToSessionId může vydavatel dát příjemcům pokyn, aby tuto hodnotu zkopírovali do vlastnosti SessionId zprávy odpovědi. Fronta nebo téma publikování nemusí být v relaci. Při odesílání zprávy pak vydavatel může konkrétně počkat na relaci s daným ID relace, aby se materializovala ve frontě podmíněným přijetím příjemce relace.

Směrování uvnitř oboru názvů služby Service Bus je možné realizovat pomocí pravidel automatického řetězení a odběru témat. Směrování mezi obory názvů je možné realizovat pomocí Azure LogicApps. Jak je uvedeno v předchozím seznamu, vlastnost To je vyhrazena pro budoucí použití a může být nakonec interpretována zprostředkovatel s speciálně povolenou funkcí. Aplikace, které chtějí implementovat směrování, by to měly provést na základě vlastností uživatele, a ne spoléhat se na vlastnost To . To ale teď nezpůsobí problémy s kompatibilitou.

Serializace datové části

Při přenosu nebo uložení uvnitř služby Service Bus je datová část vždy neprůrůzdný binární blok. Tato ContentType vlastnost umožňuje aplikacím popsat datovou část s navrhovaným formátem hodnot vlastností, které jsou popisem typu obsahu MIME podle RFC2045 IETF, application/json;charset=utf-8například .

Na rozdíl od variant Java nebo .NET Standard podporuje verze rozhraní .NET Framework rozhraní API služby Service Bus vytváření instancí BrokeredMessage předáním libovolných objektů .NET do konstruktoru.

30. září 2026 vyřadíme knihovny sady SDK služby Azure Service Bus pro WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus a com.microsoft.azure.servicebus, které nevyhovují pokynům sady Azure SDK. Také ukončíme podporu protokolu SBMP, takže tento protokol už nebudete moct používat po 30. září 2026. Před tímto datem migrujte na nejnovější knihovny sady Azure SDK, které nabízejí důležité aktualizace zabezpečení a vylepšené funkce.

I když starší knihovny je možné používat i po 30. září 2026, nebudou už od Microsoftu dostávat oficiální podporu a aktualizace. Další informace najdete v oznámení o vyřazení podpory.

Pokud používáte starší protokol SBMP, tyto objekty jsou následně serializovány s výchozí binární serializátor, nebo serializátor, který je externě dodán. Objekt je serializován do objektu AMQP. Příjemce může tyto objekty načíst metodou GetBody<T>() a zadat očekávaný typ. Pomocí AMQP se objekty serializují do grafu ArrayList AMQP a IDictionary<string,object> objektů a jakýkoli klient AMQP je může dekódovat.

Dne 30. září 2026 vyřadíme podporu protokolu SBMP pro Azure Service Bus, takže tento protokol už nebudete moct používat po 30. září 2026. Migrujte na nejnovější knihovny sady SDK služby Azure Service Bus pomocí protokolu AMQP, který nabízí důležité aktualizace zabezpečení a vylepšené funkce před tímto datem.

Další informace najdete v oznámení o vyřazení podpory.

I když je tato skrytá serializace magic pohodlná, aplikace by měly převzít explicitní kontrolu nad serializací objektů a převést jejich objektové grafy na datové proudy předtím, než je zahrne do zprávy, a provést opak na straně příjemce. Výsledkem jsou interoperabilní výsledky. I když má AMQP výkonný model binárního kódování, je svázaný s ekosystémem zasílání zpráv AMQP a klienti HTTP budou mít problémy s dekódováním takových datových částí.

Varianty rozhraní .NET Standard a Java API přijímají pouze bajtová pole, což znamená, že aplikace musí zpracovávat ovládací prvek serializace objektů.

Pokud datová část zprávy nemůže být deserializována, doporučuje se zprávu přepsat do nedoručených zpráv.

Další kroky

Další informace o zasílání zpráv služby Service Bus najdete v následujících tématech: