Zum Inhalt springen

Fehlgeschlagene Nachrichten mit einer Dead Letter Queue in Jitterbit Studio behandeln

Einführung

Der Jitterbit MQ Connector ermöglicht die Verarbeitung von Nachrichten aus einer Warteschlange mit einer Get-Aktivität. Bei Verarbeitungsfehlern ist ein häufiger Ansatz die NACK-Aktivität mit Requeue Messages After NACK, um die Nachricht später erneut zur Warteschlange hinzuzufügen. Bei Quorum-Warteschlangen hat dieser Ansatz jedoch eine harte Grenze: Nach 20 fehlgeschlagenen Bestätigungen wird die Nachricht ohne Fehler dauerhaft aus der Warteschlange entfernt. Für Integrationen, die kontrolliertes Wiederholungsverhalten und garantierte Zustellung erfordern, nutzt man stattdessen das Dead Letter Queue (DLQ) Muster.

Diese Anleitung führt durch die Erstellung eines DLQ-Musters mit mehreren Warteschlangen und einer Reihe von Studio-Operationen. Fehlgeschlagene Nachrichten werden aus der Hauptwarteschlange abgelehnt und an eine Serie von Wiederholungswarteschlangen mit zunehmenden Verzögerungen weitergeleitet. Nach einer konfigurierbaren Anzahl von Versuchen werden Nachrichten an eine finale DLQ zur manuellen Überprüfung gesendet.

%%{init: {"themeVariables": {"lineColor": "#6b7280", "edgeLabelBackground": "#f5f5f5"}}}%% flowchart TD A([Message in orders.main]) --> B[Main processor] B -->|Success| C([ACK: message removed]) B -->|Failure| D{retryCount} D -->|1| E([orders.retry.1m]) D -->|2| F([orders.retry.5m]) D -->|3 or 4| G([orders.retry.30m]) D -->|greater than 4| H([orders.dlq]) E -->|Forwarder runs every 1 min| A F -->|Forwarder runs every 5 min| A G -->|Forwarder runs every 30 min| A

Für einfachere Wiederholungsanforderungen, die keine mehrstufige Verzögerungsweiterleitung erfordern, siehe Fehlgeschlagenen Vorgang erneut ausführen. Weitere Informationen zur Konfiguration von On-Success- und On-Fail-Verhalten finden Sie unter Fehlerbehandlung in Operationen konfigurieren.

Diese Anleitung geht von Folgendem aus:

  • Sie haben eine funktionierende Jitterbit MQ-Verbindung in Studio. Anweisungen zur Einrichtung finden Sie in der Jitterbit MQ Connector Dokumentation.
  • Sie sind mit der Erstellung und Ausführung von Studio-Operationen vertraut.
  • Sie verwenden Quorum-Warteschlangen, die für Dauerhaftigkeit erforderlich sind, aber die 20-Versuch-Zustellungsbegrenzung auferlegen, die dieses Muster adressiert.

Teil 1: Die Warteschlangen erstellen

Schritt 1: Die Warteschlangen in der Management Console erstellen

  1. Öffnen Sie die Seite Message Queues der Management Console.

  2. Erstellen Sie die folgenden fünf Warteschlangen. Setzen Sie den Type für jede auf Quorum.

    Warteschlangenname Zweck Nachrichten-TTL
    orders.main Primäre Verarbeitungswarteschlange —
    orders.retry.1m Erste Wiederholung (1-Minuten-Verzögerung) 3.600.000 ms
    orders.retry.5m Zweite Wiederholung (5-Minuten-Verzögerung) 3.600.000 ms
    orders.retry.30m Dritte Wiederholung (30-Minuten-Verzögerung) 3.600.000 ms
    orders.dlq Letzte Warteschlange zur manuellen Überprüfung 864.000.000 ms

    Passen Sie die Warteschlangennamen und die Anzahl der Wiederholungsebenen an Ihre Integration an.

Hinweis

Die TTL-Werte in den Wiederholungswarteschlangen sind eine Sicherheitsmaßnahme, die verhindert, dass sich Nachrichten unbegrenzt ansammeln, falls eine Forwarder-Operation fehlschlägt. Die Verzögerung zwischen Wiederholungen wird durch die Häufigkeit der Ausführung der Forwarder-Operationen gesteuert, nicht durch die TTL.

Teil 2: Die Hauptprozessor-Operation konfigurieren

Schritt 2: Ein retryCount-Feld zur Nachrichten-Payload hinzufügen

Das DLQ-Muster verwendet ein retryCount-Feld in der Nachricht, um zu verfolgen, wie oft die Verarbeitung versucht wurde. Fügen Sie dieses Feld zu Ihrer Nachricht mit einem Anfangswert von 0 hinzu, bevor die Operation zum ersten Mal ausgelöst wird.

Beispiel-Payload

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

Verwenden Sie einen konsistenten Namen auf der obersten Ebene über alle Operationen im Muster hinweg. Das retryCount-Feld ist der einzige Mechanismus zur Verfolgung des Versuchsverlaufs über Läufe hinweg.

Schritt 3: Die On-Fail-Routing-Operation erstellen

Wenn der Hauptprozessor fehlschlägt, muss die On-Fail-Operation die aktuelle retryCount lesen, die Nachricht an die entsprechende Wiederholungswarteschlange weiterleiten und dann die ursprüngliche Nachricht aus der Hauptwarteschlange ablehnen.

  1. Lesen Sie retryCount aus dem Feld messageBody im Antwortschema der Get-Aktivität.

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

  3. Leiten Sie basierend auf der aktualisierten Anzahl an die entsprechende Warteschlange weiter:

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

  4. Schreiben Sie den aktualisierten retryCount zurück in das Feld messageBody des Request-Schemas der Send-Aktivität, wenn Sie zur Zielwarteschlange weiterleiten.

  5. Nachdem die Send-Aktivität abgeschlossen ist, verwenden Sie die NACK-Aktivität mit der Option Reject Messages After NACK, um die Nachricht aus orders.main zu entfernen.

Wichtig

Die Send-Aktivität zur Warteschlange „Wiederholen" muss vor der NACK-Aktivität abgeschlossen sein. Diese Reihenfolge stellt sicher, dass die Nachricht nicht verloren geht, wenn die Send-Aktivität fehlschlägt. Verwenden Sie nicht Requeue Messages After NACK, da dies die DLQ-Routinglogik umgeht und zum Lieferversuchlimit von 20 zählt.

Schritt 4: Konfigurieren Sie die Hauptprozessor-Operation

  1. Öffnen oder erstellen Sie in Studio die Operation, die Nachrichten aus orders.main verarbeitet.

  2. Fügen Sie eine Get-Aktivität hinzu, die so konfiguriert ist, dass sie aus orders.main liest.

  3. Fügen Sie die Schritte hinzu, die jede Nachricht verarbeiten (z. B. Abfrage eines ERP-Systems für den erwarteten Bestellstatus).

  4. Öffnen Sie die Aktionen der Operation und konfigurieren Sie Folgendes:

    • Bei Erfolg: Führen Sie eine Operation aus, die die Acknowledge-Aktivität verwendet, um die Nachricht aus orders.main zu bestätigen.
    • Bei Fehler: Führen Sie die in Schritt 3 erstellte On-Fail-Routing-Operation aus.

Teil 3: Konfigurieren Sie die Retry-Forwarder-Operationen

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

Schritt 5: Erstellen Sie jede Forwarder-Operation

Erstellen Sie für jede Retry-Stufe eine Operation mit den folgenden Schritten:

  1. Fügen Sie eine Get-Aktivität hinzu, um eine Nachricht aus der Retry-Warteschlange abzurufen.

  2. Fügen Sie eine Send-Aktivität hinzu, um die Nachricht an orders.main zu senden und dabei den retryCount-Wert in der Nutzlast beizubehalten.

  3. Fügen Sie eine Acknowledge-Aktivität hinzu, um die Nachricht aus der Retry-Warteschlange zu bestätigen.

Wichtig

Die Send-Aktivität zu orders.main muss vor der Acknowledge-Aktivität abgeschlossen sein. Wenn die Send-Aktivität fehlschlägt, bleibt die Nachricht in der Retry-Warteschlange und wird bei der nächsten Forwarder-Ausführung wieder abgeholt. Das Bestätigen vor Abschluss der Send-Aktivität würde die Nachricht stillschweigend aus der Retry-Warteschlange entfernen, ohne zu garantieren, dass sie orders.main erreicht.

Schritt 6: Planen Sie jede Forwarder-Operation

Fügen Sie einen Operationszeitplan an jede Forwarder-Operation an, mit einem Intervall, das ihrer Retry-Stufe entspricht:

Operation Quellwarteschlange Planintervall
Retry-Forwarder 1m orders.retry.1m Alle 1 Minute
Retry-Forwarder 5m orders.retry.5m Alle 5 Minuten
Retry-Forwarder 30m orders.retry.30m Alle 30 Minuten

Anweisungen zum Einrichten eines Zeitplans finden Sie unter Planen Sie einen Vorgang zur automatischen Ausführung.

DLQ-Inspector-Vorgang (optional)

Erstellen Sie einen Vorgang, der aus orders.dlq liest, um Meldungen zu benachrichtigen oder zu protokollieren, die alle Wiederholungsversuche erschöpft haben. Dieser Vorgang kann eine E-Mail-Benachrichtigung senden, in ein Protokoll schreiben oder einen manuellen Überprüfungs-Workflow auslösen. Anweisungen zum Senden von E-Mails aus einem Studio-Vorgang finden Sie unter Senden Sie eine E-Mail-Benachrichtigung von einem Studio-Vorgang.

Hinweis

Meldungen in orders.dlq erfordern manuelle Intervention. Sie bleiben in der Warteschlange, bis sie explizit bestätigt werden oder ihre TTL abläuft.

Überprüfen Sie die Integration

  1. Stellen Sie das Projekt bereit.

  2. Senden Sie eine Testnachricht an orders.main mit retryCount: 0 in der Nutzlast.

  3. Lösen Sie einen Verarbeitungsfehler im Hauptprozessor-Vorgang aus (indem Sie beispielsweise einen Fehler aus dem Verarbeitungsskript zurückgeben).

  4. Öffnen Sie die Vorgangsprotokolle in Studio und bestätigen Sie, dass der On-Fail-Vorgang ausgeführt wurde und die Nachricht an orders.retry.1m gesendet wurde.

  5. Warten Sie, bis die 1-Minuten-Weiterleitung ausgeführt wird. Bestätigen Sie in den Vorgungsprotokollen, dass die Weiterleitung die Nachricht aus orders.retry.1m abgerufen und zurück an orders.main gesendet hat.

  6. Fahren Sie fort, Fehler auszulösen, um die Nachricht durch die verbleibenden Wiederholungsebenen zu bewegen. Die Warteschlange orders.retry.5m verarbeitet einen Durchgang (retryCount 2), und orders.retry.30m verarbeitet zwei Durchgänge (retryCount 3 und 4). Nach dem fünften fehlgeschlagenen Versuch wird die Nachricht an orders.dlq weitergeleitet.

  7. Öffnen Sie die Seite Nachrichtenwarteschlangen der Management Console und bestätigen Sie, dass eine Nachricht in orders.dlq eingegangen ist.