Sdílet prostřednictvím

Odložení zpráv

  • Článek

Když klient fronty nebo odběru obdrží zprávu, že je ochotná zpracovat, ale zpracování není v současné době možné z důvodu zvláštních okolností, má možnost "odložení" načtení zprávy na pozdější bod. Zpráva zůstane ve frontě nebo odběru, ale je vyhrazená.

Poznámka:

Odložené zprávy nevypršela platnost a automaticky se přesunou do fronty nedoručených zpráv, dokud se klientská aplikace nepokusí je přijímat pomocí rozhraní API a pořadového čísla. Toto chování je záměrné. Když se klient pokusí načíst odloženou zprávu, zkontroluje se, jestli vypršela platnost, a pokud už vypršela platnost, přesune se do fronty nedoručených zpráv. Zpráva s vypršenou platností se přesune do podkateru deadletter pouze v případě, že je pro entitu (fronta nebo odběr) povolená funkce nedoručených zpráv.

Ukázkové scénáře

Deferral je funkce vytvořená speciálně pro scénáře zpracování pracovních postupů. Architektury pracovních postupů můžou vyžadovat zpracování určitých operací v určitém pořadí. Může být nutné odložit zpracování některých přijatých zpráv, dokud nebude předepsána předchozí práce informovaná jinými zprávami.

Jednoduchý ilustrativní příklad je pořadí zpracování objednávek, ve kterém se v systému zobrazí oznámení o platbě od externího poskytovatele plateb před rozšířením odpovídající nákupní objednávky z fronty obchodu do systému plnění. V takovém případě může systém plnění odložit zpracování oznámení o platbě, dokud nedojde k objednávce, ke které se má přidružit. V redezvous scénářích, kdy zprávy z různých zdrojů řídí pracovní postup vpřed, může být pořadí provádění v reálném čase skutečně správné, ale zprávy odrážející výsledky mohou přijít mimo pořadí.

Odložení nakonec pomáhá měnit pořadí zpráv z objednávky doručení do pořadí, ve kterém je možné je zpracovat, a zároveň tyto zprávy bezpečně ponechat v úložišti zpráv, pro které je potřeba odložit zpracování.

Pokud zprávu nejde zpracovat, protože konkrétní prostředek pro zpracování této zprávy je dočasně nedostupný, ale zpracování zpráv by nemělo být sumarizováno, způsob, jak tuto zprávu umístit na stranu na několik minut, je zapamatovat si pořadové číslo v naplánované zprávě , která se má publikovat během několika minut, a znovu načíst odloženou zprávu, když přijde naplánovaná zpráva. Pokud obslužná rutina zprávy závisí na databázi pro všechny operace a tato databáze je dočasně nedostupná, neměla by používat odložení, ale pozastavit příjem zpráv úplně, dokud nebude databáze znovu dostupná.

Načítání odložených zpráv

Odložené zprávy zůstávají v hlavní frontě spolu se všemi ostatními aktivními zprávami (na rozdíl od zpráv s nedoručenými písmeny, které jsou v podkateře), ale nelze je přijímat pomocí běžných operací příjmu. Odložené zprávy je možné zjistit prostřednictvím procházení zpráv nebo náhledu , pokud aplikace ztratí přehled o nich.

Pokud chcete načíst odloženou zprávu, je její vlastník zodpovědný za zapamatování pořadového čísla při jeho odvrácení. Každý příjemce, který zná pořadové číslo odložené zprávy, může později přijmout zprávu pomocí metod příjmu, které přebírají pořadové číslo jako parametr. Další informace o sekvenčních číslech naleznete v tématu Pořadí zpráv a časové razítka.

Další kroky

Vyzkoušejte ukázky v jazyce podle vašeho výběru a prozkoumejte funkce služby Azure Service Bus.

Ukázky pro starší klientské knihovny .NET a Java najdete tady:

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.