Skjut upp meddelanden
När en kö- eller prenumerationsklient får ett meddelande som den är villig att bearbeta, men bearbetningen för närvarande inte är möjlig på grund av särskilda omständigheter, har den möjlighet att "skjuta upp" hämtningen av meddelandet till en senare tidpunkt. Meddelandet finns kvar i kön eller prenumerationen, men det har lagts åt sidan.
Kommentar
Uppskjutna meddelanden har inte upphört att gälla och flyttas automatiskt till en kö med obeställbara meddelanden tills en klientapp försöker ta emot dem med hjälp av ett API och sekvensnumret. Detta beteende är av design. När en klient försöker hämta ett uppskjutet meddelande kontrolleras det efter villkor som har upphört att gälla och flyttas till en kö med obeställbara meddelanden om det redan har upphört att gälla. Ett meddelande som har upphört att gälla flyttas endast till en underfråga för deadletter när funktionen med obeställbara bokstäver är aktiverad för entiteten (kön eller prenumerationen).
Exempelscenarier
Fördröjning är en funktion som skapats specifikt för scenarier för arbetsflödesbearbetning. Arbetsflödesramverk kan kräva att vissa åtgärder bearbetas i en viss ordning. De kan behöva skjuta upp bearbetningen av vissa mottagna meddelanden tills det tidigare arbete som har informerats av andra meddelanden har slutförts.
Ett enkelt exempel är en orderbearbetningssekvens där ett betalningsmeddelande från en extern betalningsleverantör visas i ett system innan matchande inköpsorder har spridits från butiksfronten till uppfyllelsesystemet. I så fall kan uppfyllelsesystemet skjuta upp bearbetningen av betalningsmeddelandet tills det finns en order att associera den med. I rendezvous-scenarier, där meddelanden från olika källor driver ett arbetsflöde framåt, kan körningsordningen i realtid vara korrekt, men meddelandena som återspeglar resultatet kan komma ur funktion.
I slutänden underlättar uppskjutande av ordningsföljden för meddelanden från ankomstordern till en ordning där de kan bearbetas, samtidigt som dessa meddelanden lämnas säkert i meddelandearkivet för vilka bearbetningen måste skjutas upp.
Om ett meddelande inte kan bearbetas eftersom en viss resurs för att hantera meddelandet är tillfälligt otillgänglig, men meddelandebearbetningen inte bör pausas sammanfattningsvis, är ett sätt att placera meddelandet på sidan i några minuter att komma ihåg sekvensnumret i ett schemalagt meddelande som ska publiceras om några minuter och hämta det uppskjutna meddelandet igen när det schemalagda meddelandet kommer. Om en meddelandehanterare är beroende av en databas för alla åtgärder och databasen är tillfälligt otillgänglig bör den inte använda uppskjutning, utan i stället pausa mottagandet av meddelanden helt tills databasen är tillgänglig igen.
Hämtar uppskjutna meddelanden
Uppskjutna meddelanden finns kvar i huvudkön tillsammans med alla andra aktiva meddelanden (till skillnad från meddelanden med obeställbara meddelanden som finns i en underfråga), men de kan inte längre tas emot med hjälp av de vanliga mottagningsåtgärderna. Uppskjutna meddelanden kan identifieras via meddelandebläddring eller genom att titta på om ett program förlorar kontrollen över dem.
För att hämta ett uppskjutet meddelande ansvarar ägaren för att komma ihåg sekvensnumret när det defersar det. En mottagare som känner till sekvensnumret för ett uppskjutet meddelande kan senare ta emot meddelandet med hjälp av mottagningsmetoder som tar sekvensnumret som en parameter. Mer information om sekvensnummer finns i Meddelandesekvensering och tidsstämplar.
Nästa steg
Prova exemplen på det språk du väljer för att utforska Azure Service Bus-funktioner.
- Azure Service Bus-klientbiblioteksexempel för .NET (senaste) – Se exemplet Lösa meddelanden .
- Azure Service Bus-klientbiblioteksexempel för Java (senaste)
- Azure Service Bus-klientbiblioteksexempel för Python – se receive_deferred_message_queue.py exempel.
- Azure Service Bus-klientbiblioteksexempel för JavaScript – se exemplet avancerat/deferral.js .
- Azure Service Bus-klientbiblioteksexempel för TypeScript – se exemplet avancerat/deferral.ts .
Se exempel för äldre .NET- och Java-klientbibliotek här:
- Azure Service Bus-klientbiblioteksexempel för .NET (äldre) – Se skjut upp exempel.
- Azure Service Bus-klientbiblioteksexempel för Java (äldre)
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.