Nachricht löschen (Azure Storage)

  • Artikel

Der Delete Message Vorgang löscht die angegebene Nachricht aus der Warteschlange.

Anforderung

Sie können die Delete Message Anforderung wie folgt erstellen. HTTPS wird empfohlen.

Methode Anforderungs-URI HTTP-Version
DELETE https://myaccount.queue.core.windows.net/myqueue/messages/messageid?popreceipt=string-value HTTP/1.1

Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos, myqueue durch den Namen Ihrer Warteschlange und string-value durch den Wert des Pop-Belegs, der für die Zu löschende Nachricht abgerufen wurde.

Emulierter Speicherdienst-URI

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

Methode Anforderungs-URI HTTP-Version
DELETE http://127.0.0.1:10001/devstoreaccount1/myqueue/messages/messageid?popreceipt=string-value HTTP/1.1

URI-Parameter

Der Anforderungs-URI unterstützt die folgenden Parameter:

Parameter BESCHREIBUNG
popreceipt Erforderlich. Ein gültiger Popquittungswert, der von einem früheren Aufruf des Vorgangs "Nachrichten abrufen " oder " Nachricht aktualisieren" zurückgegeben wurde.
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 oder 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 Optional. 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

Keine.

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 enthält auch zusätzliche HTTP-Standardheader. 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-client-request-id Dieser Header kann zum Behandeln von Anforderungen und entsprechenden Antworten verwendet werden. 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 jeder, der über eine Shared Access Signature verfügt, die über die Berechtigung zum Ausführen dieses Vorgangs verfügt, diesen ausführen.

Hinweise

Wenn Sie eine Nachricht erfolgreich löschen, wird sie sofort zum Löschen markiert und ist für Clients nicht mehr zugänglich. Die Nachricht wird später während der automatischen Speicherbereinigung aus der Warteschlange entfernt.

Nachdem ein Client eine Nachricht mit dem Vorgang Nachrichten abrufen abgerufen hat, wird erwartet, dass der Client die Nachricht verarbeitet und löscht. Um die Nachricht zu löschen, müssen im Antworttext des Get Messages-Vorgangs zwei Datenelemente zurückgegeben werden:

  • Die Nachrichten-ID. Dies ist ein nicht transparenter GUID-Wert, der die Nachricht in der Warteschlange identifiziert.

  • Eine gültige Abrufbestätigung. Dies ist ein nicht transparenter Wert, der angibt, dass die Nachricht abgerufen wurde.

Die Nachrichten-ID wird vom vorherigen Get Messages-Vorgang zurückgegeben. Die Abrufbestätigung wird vom letzten Get Messages-Vorgang oder Update Message-Vorgang zurückgegeben. Damit der Delete Message Vorgang erfolgreich ist, muss der pop-Beleg, der in der Anforderung angegeben ist, mit dem pop-Beleg übereinstimmen, der Get MessagesUpdate Message vom Oder-Vorgang zurückgegeben wurde.

Abrufbestätigungen bleiben gültig, bis eines der folgenden Ereignisse eintritt:

  • Die Nachricht läuft ab.

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

  • Das Timeout für die Sichtbarkeit läuft ab, und die Nachricht wird durch eine Get Messages Anforderung entfernt. Wenn das Timeout der Sichtbarkeit abläuft, wird die Nachricht wieder sichtbar. 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 wird mit einem neuen Sichtbarkeitstimeout aktualisiert. Wenn die Nachricht aktualisiert wird, wird ein neuer Pop-Beleg zurückgegeben.

Wenn eine Nachricht mit einem übereinstimmenden Pop-Beleg nicht gefunden wird, gibt der Dienst den Fehlercode 404 (Nicht gefunden) zurück. Dieser Fehler tritt in den zuvor aufgeführten Fällen auf, in denen der Pop-Beleg nicht mehr gültig ist.

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Warteschlangenspeicherfehlercodes