Aktualisieren von Nachrichten

Der Update Message-Vorgang aktualisiert das Sichtbarkeitstimeout einer Nachricht. Sie können diesen Vorgang auch verwenden, um den Inhalt einer Nachricht zu aktualisieren. Eine Nachricht muss in einem Format vorliegen, das in eine XML-Anforderung mit UTF-8-Codierung eingeschlossen werden kann, und die codierte Nachricht kann bis zu 64 KB groß sein. Dieser Vorgang wurde mit Version 2011-08-18 der Azure Queue Storage-API eingeführt.

Anforderung

Sie können die Update Message Anforderung wie folgt erstellen. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos und myqueue durch den Namen Ihrer Warteschlange.

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

Emulierter Speicherdienst

Dieser Vorgang wird für SDK 1.6 und höhere Versionen unterstützt.

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Emulatorhostnamen und den Warteschlangenspeicherport als 127.0.0.1:10001an, gefolgt vom Namen des emulierten Speicherkontos.

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

URI-Parameter

Sie können die folgenden Parameter für den Anforderungs-URI angeben.

Parameter	BESCHREIBUNG
popreceipt	Erforderlich. Gibt den gültigen Pop-Belegwert an, der von einem früheren Aufruf der Vorgänge "Nachrichten abrufen" oder "Nachricht aktualisieren" zurückgegeben wurde. Der popreceipt muss URL-codiert sein.
visibilitytimeout	Erforderlich. Gibt den neuen Sichtbarkeitstimeoutwert in Sekunden relativ zur Serverzeit an. Der neue Wert muss größer oder gleich 0 sein und darf nicht größer als 7 Tage sein. Das Sichtbarkeitstimeout einer Nachricht kann nicht auf einen Wert später als die Ablaufzeit festgelegt werden. Sie können eine Nachricht aktualisieren, bis sie gelöscht wurde oder abgelaufen ist.
timeout	Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Warteschlangenspeichervorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Anforderungsheader	BESCHREIBUNG
Authorization	Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date or x-ms-date	Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version	Erfordert 2011-08-18 oder höher. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-client-request-id	Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen von Azure Queue Storage.

Anforderungstext

Der Text der Anforderung enthält die Nachrichtendaten im folgenden XML-Format. Beachten Sie, dass der Nachrichteninhalt in einem Format vorliegen muss, das mit UTF-8 codiert werden kann.

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

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 204 (Kein Inhalt) zurückgegeben. Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann auch zusätzliche HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Anforderungsheader	BESCHREIBUNG
x-ms-request-id	Dieser Header identifiziert eindeutig die Anforderung, die gestellt wurde, und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version	Gibt die Version von Warteschlangenspeicher an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.
Date	Ein UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der die Antwort initiiert wurde. Der Dienst generiert diesen Wert.
x-ms-popreceipt	Die Abrufbestätigung der Warteschlangennachricht.
x-ms-time-next-visible	Ein Datums-/Uhrzeitwert in UTC, der angibt, wann die Nachricht in der Warteschlange sichtbar ist.
x-ms-client-request-id	Sie können diesen Header verwenden, um Probleme mit Anforderungen und entsprechenden Antworten zu beheben. Der Wert dieses Headers entspricht dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist. Der Wert ist höchstens 1.024 sichtbare ASCII-Zeichen. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.

Antworttext

Keine.

Authorization

Der Kontobesitzer kann diesen Vorgang ausführen. Darüber hinaus kann dies jeder mit einer freigegebenen Zugriffssignatur tun, der über die Berechtigung zum Ausführen dieses Vorgangs verfügt.

Beispielanforderung und -antwort

Die folgende Anforderung verlängert die Sichtbarkeit einer Warteschlangennachricht um 30 Sekunden und aktualisiert ihren Inhalt.

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

Die Anforderung wird mit den folgenden Headern gesendet;

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

Die Anforderung wird mit dem folgenden XML-Text gesendet:

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

Nachdem die Anforderung gesendet wurde, wird die folgende Antwort zurückgegeben:

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  

Hinweise

Ein Update Message Vorgang schlägt fehl, wenn die angegebene Nachricht nicht in der Warteschlange vorhanden ist oder wenn der angegebene Pop-Beleg nicht mit der Nachricht übereinstimmt.

Eine Abrufbestätigung wird vom Get Messages-Vorgang oder vom Update Message-Vorgang zurückgegeben. Abrufbestätigungen bleiben gültig, bis eines der folgenden Ereignisse eintritt:

• Die Nachricht ist abgelaufen.

• Die Nachricht wurde mithilfe des letzten empfangenen Get Messages Pop-Belegs von oder Update Messagegelöscht.

• Die Unsichtbarkeitszeit ist abgelaufen, und die Nachricht wurde durch eine Get Messages-Anforderung aus der Warteschlange entfernt. Nach Ablauf der Unsichtbarkeitszeit wird die Nachricht erneut angezeigt. Wenn sie von einer anderen Get Messages Anforderung abgerufen wird, kann der zurückgegebene Pop-Beleg verwendet werden, um die Nachricht zu löschen oder zu aktualisieren.

• Die Nachricht wurde mit einem neuen Sichtbarkeitstimeout aktualisiert. Wenn die Nachricht aktualisiert wurde, wird eine neue Abrufbestätigung zurückgegeben.

Sie können den Update Message Vorgang verwenden, um die Sichtbarkeit einer Warteschlangennachricht kontinuierlich zu erweitern. Diese Funktion kann nützlich sein, wenn eine Workerrolle eine Warteschlangennachricht leasen soll. Wenn beispielsweise eine Workerrolle Nachrichten abrufen aufruft und erkennt, dass sie mehr Zeit für die Verarbeitung einer Nachricht benötigt, kann sie die Sichtbarkeit der Nachricht kontinuierlich erweitern, bis sie verarbeitet wird. Wenn die Workerrolle während der Verarbeitung fehlschlägt, wird die Nachricht schließlich wieder sichtbar, und eine andere Workerrolle könnte sie verarbeiten.

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Queue Storage-Fehlercodes