Dead Letter Queue für Jitterbit Message Queue

Übersicht

Diese Seite beschreibt, wie man ein Dead Letter Queue (DLQ) Designmuster mit dem Jitterbit Message Queue Service und dem Jitterbit MQ Connector implementiert.

Ein DLQ-Muster leitet Nachrichten, die nicht erfolgreich verarbeitet werden können, durch eine Reihe von Wiederholungswarteschlangen mit zunehmenden Verzögerungen, bevor sie in eine endgültige DLQ zur manuellen Überprüfung platziert werden.

NACK- und Wiederholungsbeschränkungen

Ein gängiges Integrationsmuster ist die Verwendung der NACK-Aktivität mit der Option Nach NACK Nachrichten erneut in die Warteschlange stellen, um eine Nachricht zurück in die Warteschlange zu senden, wenn die Verarbeitung fehlschlägt. Zum Beispiel kann eine Integration zur Rechnungsstellung von Bestellungen ein ERP-System wiederholt abfragen, bis eine Bestellung den erwarteten Status erreicht.

Dieser Ansatz hat zwei wesentliche Nachteile, wenn er mit Quorum-Warteschlangen verwendet wird:

• Nachrichten, die nicht sofort verarbeitet werden können, werden an den Anfang der Warteschlange zurückgegeben und kontinuierlich erneut versucht, wodurch Verarbeitungsressourcen verbraucht werden.
• Quorum-Warteschlangen setzen eine Liefergrenze von 20 Versuchen durch. Nachdem eine Nachricht 20 Mal negativ bestätigt wurde, wird sie ohne Fehlermeldung dauerhaft aus der Warteschlange entfernt.

Das DLQ-Muster verwendet stattdessen die NACK-Aktivität mit der Option Nach NACK Nachrichten ablehnen und implementiert eine explizite Weiterleitung zu einer Reihe von Wiederholungswarteschlangen mit eskalierenden Verzögerungen, wie in den folgenden Abschnitten beschrieben.

Musterübersicht

Das DLQ-Muster verwendet mehrere Warteschlangen und eine Reihe von Studio-Operationen:

1. Nachrichten werden aus einer Hauptwarteschlange verarbeitet.
2. Bei einem Fehler wird die Nachricht abgelehnt (nicht erneut in die Warteschlange gestellt) und an die erste Wiederholungswarteschlange mit einem erhöhten retryCount-Wert im Payload gesendet.
3. Eine geplante Operation liest nach ihrem Verzögerungsintervall aus jeder Wiederholungswarteschlange und leitet die Nachrichten zur erneuten Verarbeitung zurück an die Hauptwarteschlange.
4. Nach einer konfigurierbaren maximalen Anzahl von Versuchen werden die Nachrichten zur manuellen Überprüfung an die DLQ gesendet.

Queue setup

Erstellen Sie die folgenden fünf Warteschlangen auf der Seite Nachrichtenwarteschlangen der Management-Konsole. Alle Warteschlangen sollten den Typ Quorum für die Dauerhaftigkeit verwenden.

Message payload requirements

Um fehlgeschlagene Verarbeitungsversuche zu verfolgen, fügen Sie ein Feld retryCount (eine Ganzzahl, die bei 0 beginnt) zu Ihrer Nachrichtenlast hinzu. Bei jedem fehlgeschlagenen Verarbeitungsversuch konfigurieren Sie die Hauptverarbeitungsoperation, um die folgenden Schritte auszuführen:

1. Lesen Sie retryCount aus dem Feld messageBody im Antwortschema der Get activity.

2. Erhöhen Sie den Wert mithilfe eines Skripts oder einer Transformation.

3. Schreiben Sie den aktualisierten Wert über das Feld messageBody im Anfrage-Schema der Send activity, wenn Sie zur Wiederholungswarteschlange weiterleiten.

{
"orderId": "ORD-12345",
"retryCount": 0
}

Workflow-Design

Hauptprozessorbetrieb

Konfigurieren Sie diesen Betrieb so, dass er von orders.main liest und versucht, jede Nachricht zu verarbeiten.

1. Verwenden Sie die Get activity, um eine Nachricht von orders.main abzurufen.

2. Versuchen Sie, die Nachricht zu verarbeiten (zum Beispiel, um das ERP-System nach dem erwarteten Bestellstatus abzufragen).

3. Verwenden Sie operation actions, um die folgenden Aktionen zu konfigurieren:

   • Bei Erfolg: Führen Sie einen Betrieb aus, der die Acknowledge activity verwendet, um die Nachricht zu bestätigen.

   • Bei Fehler: Führen Sie einen Betrieb aus, der die folgenden Schritte ausführt:

     1. Lesen Sie retryCount aus der Nachrichtenpayload und erhöhen Sie ihn um 1.

     2. Verwenden Sie die Send activity, um die aktualisierte Nachricht an die entsprechende Wiederholungswarteschlange zu senden:

        retryCount-Wert	Zielwarteschlange
        1	orders.retry.1m
        2	orders.retry.5m
        3 oder 4	orders.retry.30m
        Größer als 4	orders.dlq

     3. Verwenden Sie die NACK activity mit Nach NACK Nachrichten ablehnen, um die Nachricht aus orders.main zu entfernen.

Retry-Forwarder-Operationen

Erstellen Sie eine Forwarder-Operation für jede Retry-Warteschlange. Konfigurieren Sie jede Operation so, dass sie Nachrichten aus ihrer Retry-Warteschlange liest, sie zurück an orders.main zur erneuten Verarbeitung sendet und nach einem Zeitplan ausgeführt wird, der der beabsichtigten Verzögerung entspricht:

Konfigurieren Sie jede Operation, um die folgenden Schritte auszuführen:

1. Verwenden Sie die Get activity, um eine Nachricht aus der Retry-Warteschlange abzurufen.

2. Verwenden Sie die Send activity, um die Nachricht an orders.main zu senden und den Wert von retryCount im Payload beizubehalten.

3. Verwenden Sie die Acknowledge activity, um die Nachricht aus der Retry-Warteschlange zu bestätigen.

DLQ-Inspektor-Operation (optional)

Erstellen Sie eine Operation, die aus orders.dlq liest, um auf Nachrichten zu alerten oder diese zu protokollieren, die alle Retry-Versuche erschöpft haben. Diese Operation kann Email-Benachrichtigungen senden, in ein Protokoll schreiben oder einen manuellen Überprüfungsworkflow auslösen.