Delen via

Bericht bijwerken

Met deze Update Message bewerking wordt de time-out voor de zichtbaarheid van een bericht bijgewerkt. U kunt deze bewerking ook gebruiken om de inhoud van een bericht bij te werken. Een bericht moet een indeling hebben die kan worden opgenomen in een XML-aanvraag met UTF-8-codering en het gecodeerde bericht mag maximaal 64 kB groot zijn. Deze bewerking is geïntroduceerd met versie 2011-08-18 van de Azure Queue Storage-API.

Aanvraag

U kunt de Update Message aanvraag als volgt opbouwen. HTTPS wordt aanbevolen. Vervang mijnaccount door de naam van uw opslagaccount en mijnwachtrij door de naam van uw wachtrij.

Methode URI-aanvraag HTTP-versie
PUT https://myaccount.queue.core.windows.net/myqueue/messages/messageid?popreceipt=<string-value>&visibilitytimeout=<int-seconds> HTTP/1.1

Geëmuleerde opslagservice

Deze bewerking wordt ondersteund voor SDK 1.6 en latere versies.

Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de wachtrijopslagpoort op als 127.0.0.1:10001, gevolgd door de naam van het geëmuleerde opslagaccount.

Methode URI-aanvraag HTTP-versie
PUT http://127.0.0.1:10001/devstoreaccount1/myqueue/messages/messageid?popreceipt=<string-value>&visibilitytimeout=<int-seconds> HTTP/1.1

URI Parameters

U kunt de volgende parameters opgeven voor de aanvraag-URI.

Kenmerk Description
popreceipt Verplicht. Hiermee geeft u de geldige pop-ontvangstwaarde op die wordt geretourneerd door een eerdere aanroep naar de bewerkingen Berichten ophalen of Bericht bijwerken . Ze popreceipt moeten URL-gecodeerd zijn.
visibilitytimeout Verplicht. Hiermee geeft u de nieuwe time-outwaarde voor zichtbaarheid op, in seconden, ten opzichte van de servertijd. De nieuwe waarde moet groter zijn dan of gelijk zijn aan 0 en mag niet groter zijn dan 7 dagen. De time-out voor zichtbaarheid van een bericht kan niet worden ingesteld op een waarde die later is dan de vervaltijd. U kunt een bericht bijwerken totdat het is verwijderd of is verlopen.
timeout Optional. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Queue Storage-bewerkingen voor meer informatie.

Headers aanvragen

In de volgende tabel worden de vereiste en optionele aanvraagheaders beschreven.

Header van het verzoek Description
Authorization Verplicht. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
Date or x-ms-date Verplicht. Hiermee geeft u de gecoördineerde universele tijd (UTC) voor de aanvraag op. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
x-ms-version Vereist 2011-08-18 of later. Hiermee geeft u de versie van de bewerking op die voor deze aanvraag moet worden gebruikt. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
x-ms-client-request-id Optional. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie wordt geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. Zie Azure Queue Storage bewaken voor meer informatie.

Inhoud van het verzoek

De hoofdtekst van de aanvraag bevat de berichtgegevens in de volgende XML-indeling. Houd er rekening mee dat de inhoud van het bericht een indeling moet hebben die kan worden gecodeerd met UTF-8.

<QueueMessage>  
    <MessageText>message-content</MessageText>  
</QueueMessage>

Reactie

Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.

Statuscode

Een geslaagde bewerking retourneert statuscode 204 (Geen inhoud). Zie Status- en foutcodes voor meer informatie over statuscodes.

Antwoordkopteksten

Het antwoord voor deze bewerking bevat de volgende koppen. Het antwoord kan ook aanvullende, standaard HTTP-headers bevatten. Alle standaard headers voldoen aan de HTTP/1.1-protocolspecificatie.

Header van het verzoek Description
x-ms-request-id Deze header identificeert op unieke wijze de aanvraag die is gedaan en kan worden gebruikt voor het oplossen van problemen met de aanvraag. Zie Problemen met API-bewerkingen oplossen voor meer informatie.
x-ms-version Geeft de versie van Queue Storage aan die is gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn ingediend tegen versie 2009-09-19 en hoger.
Date Een UTC-datum/tijd-waarde die het tijdstip aangeeft waarop de reactie is gestart. De service genereert deze waarde.
x-ms-popreceipt De pop-ontvangst van het wachtrijbericht.
x-ms-time-next-visible Een UTC-datum/tijd-waarde die aangeeft wanneer het bericht zichtbaar is in de wachtrij.
x-ms-client-request-id U kunt deze koptekst gebruiken om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header, als deze aanwezig is in de aanvraag. De waarde is maximaal 1.024 zichtbare ASCII-tekens. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord.

Antwoordlichaam

Geen.

Authorization

De accounteigenaar kan deze bewerking uitvoeren. Bovendien kan iedereen met een handtekening voor gedeelde toegang die gemachtigd is om deze bewerking uit te voeren, dit doen.

Voorbeeldaanvraag en -antwoord

Met het volgende verzoek wordt de zichtbaarheid van een wachtrijbericht met 30 seconden verlengd en wordt de inhoud bijgewerkt.

PUT https://myaccount.queue.core.windows.net/myqueue/messages/663d89aa-d1d9-42a2-9a6a-fcf822a97d2c?popreceipt=AgAAAAEAAAApAAAAGIw6Q29bzAE%3d&visibilitytimeout=30&timeout=30 HTTP/1.1

Het verzoek wordt verzonden met de volgende koppen:

x-ms-version: 2011-08-18  
x-ms-date: Mon, 29 Aug 2011 17:17:21 GMT  
Authorization: SharedKey myaccount:batcrWZ35InGCZeTUFWMdIQiOZPCW7UEyeGdDOg7WW4=  
Content-Length: 75

De aanvraag wordt verzonden met de volgende XML-body:

<QueueMessage>  
    <MessageText>new-message-content</MessageText>  
</QueueMessage>

Nadat het verzoek is verzonden, wordt het volgende antwoord geretourneerd:

HTTP/1.1 204 No Content  
Content-Length: 0  
Server: Windows-Azure-Queue/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: df34a7dd-3cbe-4206-a586-d6de3cf225a7  
x-ms-version: 2011-08-18  
x-ms-popreceipt: AwAAAAIAAAApAAAAINtMQ29bzAEBAAAA  
x-ms-time-next-visible: Mon, 29 Aug 2011 17:17:51 GMT  
Date: Mon, 29 Aug 2011 17:17:21 GMT

Opmerkingen

Een Update Message bewerking mislukt als het opgegeven bericht niet in de wachtrij staat of als de opgegeven pop-bevestiging niet overeenkomt met het bericht.

Een pop-ontvangstbewijs wordt geretourneerd door de Get Messages bewerking of de Update Message bewerking. Pop-ontvangstbewijzen blijven geldig totdat een van de volgende gebeurtenissen zich voordoet:

  • Het bericht is verlopen.

  • Het bericht is verwijderd met behulp van de laatst ontvangen pop-ontvangstbevestiging, van Get Messages of Update Message.

  • De onzichtbaarheidstijd is verstreken en het bericht is uit de wachtrij gehaald door een Get Messages verzoek. Wanneer de onzichtbaarheidstijd verstrijkt, wordt de boodschap weer zichtbaar. Als het wordt opgehaald door een ander Get Messages verzoek, kan de geretourneerde pop-bevestiging worden gebruikt om het bericht te verwijderen of bij te werken.

  • Het bericht is bijgewerkt met een nieuwe time-out voor zichtbaarheid. Wanneer het bericht is bijgewerkt, wordt een nieuw pop-ontvangstbewijs geretourneerd.

U kunt de Update Message bewerking gebruiken om de onzichtbaarheid van een wachtrijbericht voortdurend te vergroten. Deze functionaliteit kan handig zijn als u wilt dat een werknemerrol een wachtrijbericht leaset. Als een werknemer bijvoorbeeld Berichten ophalen aanroept en herkent dat er meer tijd nodig is om een bericht te verwerken, kan de onzichtbaarheid van het bericht voortdurend worden verlengd totdat het is verwerkt. Als de rol van de werknemer tijdens de verwerking zou mislukken, zou het bericht uiteindelijk weer zichtbaar worden en zou een andere rol van de werknemer het kunnen verwerken.

Een bericht moet een indeling hebben die kan worden opgenomen in een XML-aanvraag met UTF-8-codering. Als u opmaak in het bericht wilt opnemen, moet de inhoud van het bericht Base64-gecodeerd zijn. Elke XML-opmaak in het bericht die niet is gecodeerd, zorgt ervoor dat het bericht ongeldig is. Als er een ongeldig teken (bijvoorbeeld 0x1F) in het bericht is opgenomen, zelfs als het een XML-escaped is, kan het bericht niet worden gelezen.

Als het bericht te groot is, retourneert de service statuscode 400 (Ongeldig verzoek).

Zie ook

Aanvragen voor Azure Storage autoriseren
status en foutcodes
Foutcodes voor wachtrijopslag

  • Last updated on