Fehlgeschlagene Nachrichten untersuchen? Dead-Letter-Nachricht prüfen und erneut senden

Ein Worker empfängt eine Bestellung mit negativer Menge. Erneutes Verarbeiten derselben ungültigen Bestellung behebt den Fehler nicht. Eine Dead-Letter-Queue (DLQ) hält Nachrichten zur Untersuchung statt zur normalen Verarbeitung bereit. Jede Service-Bus-Queue besitzt diese integrierte Unterqueue; du erstellst dafür keine separate Queue.

Nachrichten können nach zu vielen erfolglosen Zustellversuchen oder durch ausdrückliche Ablehnung einer Anwendung in die DLQ gelangen. In diesem Lab übernimmst du die Rolle der Anwendung und lehnst eine ungültige Bestellung manuell ab. Service Bus prüft die fachlichen Felder deiner Bestellung nicht automatisch.

Verwende sb-ctmessagingweu, die normale Queue orders und deine Rolle Azure Service Bus Data Owner aus dem ersten Messaging-Trip. Nutze deinen tatsächlichen Namespace-Namen, falls er abweicht. Verwende orders, nicht die Queue orders-sessions mit aktivierten Sessions. Die gesamte Übung läuft im Azure-Portal.

Ungültige Bestellung senden und ablehnen

Öffne orders → Service Bus Explorer. Verwende unter Settings die Authentifizierung Microsoft Entra ID. Wähle Send messages, dann Application/Json, und sende diesen Inhalt einmal:

{
  "orderId": "CT-4001",
  "product": "Notebook",
  "quantity": -1
}

Setze unter Broker properties die Message ID auf ct-4001-invalid. Wiederholtes Senden bleibt deaktiviert.

Wähle Receive Mode, die normale Queue und empfange 1 Nachricht mit PeekLock. Prüfe, dass CT-4001 ausgewählt ist, und wähle Dead-letter, solange die Sperre gültig ist. Bietet der Dialog Felder für Grund und Beschreibung an, trage InvalidQuantity und Quantity must be greater than zero ein. Andernfalls fahre mit dem vom Portal vergebenen Grund fort.

Damit simulierst du einen Worker, der ungültige Eingaben ablehnt. Liegen andere Lab-Nachrichten davor, prüfe und erledige diese zuerst. Läuft die Sperre ab, empfange CT-4001 erneut, bevor du Dead-letter auswählst.

Dead-Letter-Nachricht untersuchen

Wechsle zu Peek Mode, wähle DeadLetter und Peek from start. Öffne CT-4001 und prüfe den Inhalt sowie Message Properties:

Detail	Was du untersuchst
MessageId	Identifiziert die fehlgeschlagene Nachricht: ct-4001-invalid.
DeadLetterReason / DeadLetterErrorDescription	Erklärt die Ablehnung, sofern Anwendung oder Dienst diese Angaben gesetzt haben.
DeliveryCount	Hilft beim Erkennen wiederholter Zustellversuche. Eine manuelle Ablehnung erfordert nicht das Erreichen des Zustelllimits.
Body	Die Menge ist -1; diese Bestellung muss korrigiert werden.

Korrigierte Kopie erneut senden

Markiere die Dead-Letter-Nachricht und wähle Re-send selected messages. Wähle die Nachricht im Formular zum Bearbeiten aus und ändere ihren Inhalt auf:

{
  "orderId": "CT-4001",
  "product": "Notebook",
  "quantity": 1
}

Setze Message ID auf ct-4001-corrected und sende einmal. Die unveränderte orderId erhält den fachlichen Bezug. Die neue Message ID kennzeichnet diese Korrektur und verhindert eine Unterdrückung durch die MessageId-basierte Duplikaterkennung, falls diese aktiviert ist.

Erneutes Senden erstellt eine neue Kopie in der normalen Queue. Das Original bleibt in der DLQ. Klicke bei verzögerter Anzeige nicht wiederholt auf Send, sondern prüfe zuerst die Queue.

Wechsle zurück zu Queue → Peek Mode → Peek from start. Prüfe, dass CT-4001 die Menge 1 und die MessageId ct-4001-corrected hat.

Korrektur bestätigen und Original erledigen

Empfange die korrigierte Kopie in der normalen Queue mit PeekLock, prüfe sie und wähle Complete. Das steht im Lab für erfolgreiche Verarbeitung; eine echte Versandaktion findet nicht statt.

Wähle erst nach Prüfung der korrigierten Kopie DeadLetter, wechsle zu Receive Mode und empfange das Original mit PeekLock. Prüfe die MessageId ct-4001-invalid und wähle Complete, um das erledigte Original zu entfernen. Eine nur über Peek angesehene Nachricht muss vor dem Bestätigen erst empfangen werden.

Aktualisiere orders → Overview. War die Queue ansonsten leer, sollten Active messages und Dead-letter messages jeweils 0 anzeigen. Die Zähler können sich verzögert aktualisieren.

Abschluss

Du hast den Fehler untersucht, seine Ursache korrigiert, den Ersatz geprüft und das erledigte Original entfernt. DLQ-Nachrichten werden weder automatisch erneut verarbeitet noch durch ihre Time-to-live entfernt. Sie müssen ausdrücklich behandelt werden.

Dokumentiere in Produktion Fehler und Wiederherstellung, bevor du Nachweise entfernst. Erneutes Senden und Bestätigen im Portal sind getrennte Vorgänge. Bei einer Unterbrechung können deshalb beide Kopien vorhanden bleiben. Worker brauchen weiterhin eine Duplikatbehandlung für die fachliche Operation. Eine andere MessageId macht das zweimalige Verarbeiten derselben Bestellung nicht sicher.

Behalte den Namespace für spätere Trips oder lösche rg-cloudtrips-servicebus-test-weu nach Abschluss der Messaging-Labs, um laufende Namespace-Kosten zu beenden.