JMS Connector: Listen- und Acknowledge-Aktivitäten in Transaktionssitzungen in Jitterbit Design Studio

Zweck

Eine Transaktionssitzung für eine JMS Listen-Aktivität ermöglicht einem Benutzer, eine Nachricht zu empfangen und mit ihren Daten zu arbeiten - alles innerhalb einer Transaktion.

Während die Nachricht an das Jitterbit-System gesendet wird, führt der Broker (wie Apache ActiveMQ) sperrt die Nachricht, sodass andere Listener die gleiche Nachricht nicht abrufen können. Wenn der Benutzer mit der Verarbeitung der Nachricht zufrieden ist, verwendet er eine Bestätigungsaktivität, um den Broker zu benachrichtigen, dass er die gesperrte Nachricht aus der Warteschlange entfernen soll (Aktion: JBXCommit); mit anderen Worten, die Nachricht wurde erfolgreich verarbeitet und wird nicht mehr benötigt.

Es gibt Fälle, in denen es - während der Verarbeitung der Nachricht im Prozessablauf - angebracht ist, die Nachricht wieder in die Warteschlange freizugeben, damit sie erneut oder von einem anderen Listener verarbeitet werden kann. In diesen Fällen kann die Acknowledge-Aktivität verwendet werden, um den Broker darüber zu informieren, dass die Sperre der Nachricht aufgehoben und sie erneut verarbeitet werden soll (Aktion: JBXRollback).

Ein solcher Fall sind Fehlerereignisse. Normalerweise werden Nachrichten an das Jitterbit-System und dann an einen privaten Jitterbit-Agenten gesendet. Während der Operation die Geschäftslogik durchläuft, kann es sein, dass der Agent abstürzt, der Server herunterfährt oder eine Ausnahme auftritt. In jedem dieser Fälle, bei denen kein explizites JBXCommit an den Broker zurückgesendet wurde, führt der Broker ein Rollback der Nachricht durch, um Datenverlust zu vermeiden. Rollback bedeutet, dass die Nachricht wieder in die Warteschlange freigegeben wird, damit sie von allen aktiven Verbrauchern dieser Warteschlange erneut verarbeitet werden kann.

Übersicht

Um Transaktionssitzungen mit dem Jitterbit JMS Connector zu verwenden, müssen bestimmte Einstellungen verwendet werden. Dieses Dokument behandelt diese Einstellungen und zeigt Beispielszenarien, die zeigen, wie Transaktionen verwendet werden können.

JMS Listen-Aktivität

Die JMS -Listen-Aktivität wird wie unter JMS -Connector-Listen-Aktivitäten beschrieben eingerichtet. Um die Vorteile der clientbasierten Bestätigung nutzen zu können, muss die Eigenschaft Transacted Session auf True gesetzt werden.

Wenn ein Transacted JMS Listener eine Nachricht aufnimmt, wartet er, bis:

• Empfängt eine Bestätigung von JBXCommit:
  In diesem Fall wird die Sitzung bestätigt und die Nachricht vom Broker entfernt.
• Empfängt eine Bestätigung von JBXRollback:
  In diesem Fall wird die Sitzung zurückgesetzt, die Sperre vom Broker entfernt und die Nachricht wieder in die Warteschlange gestellt.
• Trennung der Verbindung oder Sitzung mit dem Broker (privater Agent gestoppt oder abgestürzt, Server heruntergefahren oder abgestürzt usw.):
  In diesem Fall führt der Broker ein automatisches Rollback durch, um die Nachricht zu erhalten. Das Rollback wird nur durchgeführt, solange kein explizites JBXCommit vom Broker empfangen wurde.
• Bestätigungs-Timeout erreicht:
  In diesem Fall wird automatisch eine Rollback-Bestätigung an den Broker gesendet, um die Nachricht wieder in die Warteschlange freizugeben. Dieser Schwellenwert dient dazu, Fälle zu behandeln, in denen ein Operation in einem sehr lang andauernden Zustand stecken bleibt, der außerhalb des akzeptablen Bereichs der Nachrichtenverarbeitung liegt.

JMS Bestätigungsaktivität

Mit der JMS Bestätigungsaktivität können Sie das Schicksal einer Nachricht steuern, indem Sie entweder die Aktion JBXCommit oder JBXRollback senden. Dies wird erreicht, indem die Aktivität in der Bestätigungsanforderungstransformation angegeben wird.

• AcknowledgmentAction
  • Gültige Werte: "JBXCommit" oder "JBXRollback"
  • Groß-/Kleinschreibung wird nicht beachtet, aber die Schreibweise muss wie angegeben sein.
  • Wenn Sie es in die Transformation eingeben, schließen Sie die öffnenden und schließenden Anführungszeichen ein, da es sich um einen String-Typ handelt

• AcknowledgmentMessageID

  • Gültiger Wert: Die JMS Nachrichten-ID der vom JMS Listener empfangenen Nachricht

  • Diese ID kann beim Empfang der Nachricht in der Listen Response Transformation extrahiert und in einer globalen Variable gespeichert werden (siehe Screenshot)

    

  • Die globale Variable kann dann für die Eigenschaft AcknowledgmentMessageID in der Acknowledge Request Transformation verwendet werden

Bestätigungs-Timeout

Mit dieser Eigenschaft kann der Benutzer die Anzahl der Sekunden angeben, nach denen eine Nachricht automatisch zurückgesetzt wird. Dadurch wird verhindert, dass eine Nachricht entweder für immer oder länger als einen akzeptablen Zeitraum in der Verarbeitung hängen bleibt. Diese Eigenschaft muss in der Send/Publish Request Transformation für die JMS SendOrPublish-Aktivität festgelegt werden.

Beispiele

In diesen Beispielen erhalten wir eine Nachricht von einer JMS -Listen-Aktivität, extrahieren die JMS -Nachrichten-ID und speichern sie in einer Variablen. Dann fügen wir eine JMS Bestätigungsaktivität als „Bei Erfolg“ Operation hinzu. Wenn bei der JMS -Listen-Aktivität alles gut geht, führt die Bestätigungsaktivität einfach einen Commit für die Transaktion aus (Entfernen der Nachricht aus der Warteschlange), da wir mit der Verarbeitung dieser Nachricht fertig sind. In ähnlicher Weise kann eine weitere JMS Bestätigungsaktivität erstellt und als „Bei Fehler“ Operation angehängt werden.

Es ist wichtig zu beachten, dass in vielen Anwendungsfällen die JMS -Bestätigung nicht die nächste Operation in der „Bei Erfolg“-Kette sein sollte, wenn mit den Nachrichtendaten noch weitere Arbeiten ausgeführt werden müssen. Stattdessen sollte die JMS Bestätigungsaktivität hinzugefügt werden, wenn alle (oder fast alle) Operationen erfolgreich abgeschlossen wurden und wir die Nachricht nicht mehr benötigen.

Variante 1

JMS Listener mit Commit-Bestätigung bei Erfolg und Rollback-Bestätigung bei Fehlerereignissen.

Variante 2

Diese Variante zeigt die Verwendung einer zusätzlichen Business-Logik Operation, die zusätzliche Arbeit mit den Nachrichtendaten ausführt. Wenn in dieser Variante entweder der Listener oder die Business-Logik fehlschlägt, wird ein Rollback durchgeführt. Wenn alles erfolgreich ist und die Business-Logik erfolgreich abgeschlossen wird, wird die Transaktion festgeschrieben.

Variante 3

Diese Variante ist dem vorherigen Szenario sehr ähnlich. Anstatt jedoch automatisch bei Erfolg der Business-Logik-Operation zu committen, verwenden wir einen Aufruf des Jitterbit RunOperation() Funktion im Customer Logic Script, um genau zu steuern, wann im Script wir ein Commit durchführen möchten:

RunOperation("<TAG>Operations/4. JMS Acknowledge (Commit)</TAG>", true);

und ein ähnlicher Aufruf im Script, wenn ein Fehler auftritt und die Transaktion zurückgesetzt werden muss:

RunOperation("<TAG>Operations/3. JMS Acknowledge (Rollback)</TAG>", true);

Dadurch liegt die Verantwortung beim Entwickler, die Bedingungen für Erfolg oder Misserfolg zu bestimmen. In bestimmten Anwendungsfällen kann dies jedoch für die gewünschte Steuerung von entscheidender Bedeutung sein.

Tipps und Vorschläge

Festlegen des Bestätigungs-Timeouts, wenn das Jitterbit-System nicht verwendet wird

Die Eigenschaft für das Bestätigungstimeout ist verfügbar (bei der Aktivität SendOrPublish), wenn eine Nachricht von Jitterbit aus an eine Warteschlange gesendet wird. Aber was, wenn Sie das Timeout steuern möchten, aber ein anderes System die Nachrichten in die Warteschlange einfügt? Die Lösung: Fügen Sie beim Erstellen einer Nachricht einfach eine Integer-Eigenschaft in der JMS -Nachricht mit dem Schlüssel JBXAcknowledgmentTimeout und einem Wert für das erforderliche Timeout in Sekunden_ hinzu._

JMS Nachrichten werden automatisch übermittelt, auch ohne Aufruf der Acknowledge-Aktivität

Stellen Sie sicher, dass der JMS Listener mit der Einstellung Transacted Session auf True konfiguriert ist. Stellen Sie sicher, dass keine zugehörige Acknowledge-Aktivität ausgelöst wird.

Nachrichten, die fehlschlagen, werden immer wieder abgeholt und schlagen erneut fehl

Wenn - bei einem Fehler - Nachrichten zurückgesetzt werden, werden sie wieder in die Warteschlange gestellt. Da sich ein Listener in der Warteschlange befindet, wird er die Nachricht abrufen und versuchen, sie erneut zu verarbeiten. Eine Lösung besteht darin, die Rücklieferungsrichtlinie des Brokers (z. B. Apache ActiveMQ) anzupassen, um Verzögerungen und Zählung für die Dead Letter Queue (DLQ) zu optimieren.

Nachrichten, die immer wieder fehlschlagen, verschwinden irgendwann

Wenn der Zustellungsmodus einer Nachricht auf PERSISTENT_ eingestellt war,_ ging die Nachricht nicht verloren. Sie wurde einfach in die Dead Letter Queue (DLQ) verschoben, wie vom Broker konfiguriert. Wenn der Zustellungsmodus einer Nachricht NICHT_PERSISTENT_ war,_ ging die Nachricht nach einer bestimmten Anzahl von erneuten Zustellungen verloren (wenn sie die Einstellung des Brokers für maximale erneute Zustellungen überschreitet).