Der Broker stellt eine allgemeine Fehlerbehandlung für alle Nachrichtenflüsse zur
Verfügung. Falls diese allgemeine Verarbeitung nicht ausreicht und Sie auf bestimmte
Fehlerbedingungen und -situationen mit besonderen Aktionen reagieren möchten, können Sie Ihre
Nachrichtenflüsse um eine eigene Fehlerbehandlung erweitern. Beispielsweise können
Sie einen Nachrichtenfluss entwerfen, der auf bestimmte Fehler, die Sie auf eine besondere Weise
verarbeiten möchten, wartet. Oder Sie entwerfen einen Nachrichtenfluss, der eine Datenbank
aktualisiert und diese Aktualisierungen rückgängig machen muss, wenn andere Verarbeitungsschritte
nicht erfolgreich beendet werden.
Die zu diesem Zweck verwendbaren Optionen können in
einigen Fällen sehr komplex sein. Die für MQEmpfangsknoten und Zeitlimitbenachrichtigungsknoten bereitgestellten Optionen sind sehr umfangreich, da diese Knoten mit persistenten Nachrichten und Transaktionen arbeiten. MQEmpfangsknoten werden außerdem von den Konfigurationsoptionen für WebSphere MQ beeinflusst.
Da Sie selbst entscheiden können, wie Sie verschiedene Fehler behandeln wollen, gibt es
keine festen Prozeduren, die beschrieben werden könnten. Dieser Abschnitt enthält grundsätzliche
Informationen zur Fehlerbehandlung und beschreibt die verfügbaren Optionen. Sie müssen auf Basis
der in diesem Abschnitt aufgeführten Details entscheiden, welche der auswählbaren Kombinationen Sie
in der jeweiligen Situation benötigen.
Sie können sich in Ihren Nachrichtenflüssen für eine
oder mehrere der folgenden Optionen entscheiden:
- Verbinden Sie das Fehlerterminal jedes einzelnen Knotens mit einer Knotenfolge, in der die
interne Ausnahme des Knotens verarbeitet wird (Fehlerdatenfluss).
- Verbinden Sie das Abfangterminal des Empfangsknotens oder eines
TryCatch-Knotens mit einer Knotenfolge, in der Ausnahmen, die außerhalb generiert werden,
verarbeitet werden (Abfangdatenfluss).
- Fügen Sie einen oder mehrere TryCatch-Knoten an spezifischen Punkten im
Nachrichtenfluss ein, um Ausnahmen abzufangen und zu verarbeiten, die von dem Nachrichtenfluss, der
mit dem Try-Terminal verbunden ist, generiert werden.
- Fügen Sie einen Ausnahmeknoten ein, oder schreiben Sie eine ESQL
THROW-Anweisung, um eine Ausnahme zu generieren.
- Wenn Sie Aggregation verwenden, stellen Sie eine Verbindung mit dem Abfangterminal
des Knotens für Aggregationsantworten her, um Aggregationsausnahmen zu
verarbeiten.
- Sicherstellen, dass alle von einem MQEmpfangsknoten empfangenen Nachrichten entweder innerhalb einer Transaktion oder gar nicht verarbeitet werden.
- Sicherstellen, dass alle von einem MQEmpfangsknoten empfangenen Nachrichten entweder persistent oder nicht-persistent sind.
Falls Sie benutzerdefinierte Knoten in Ihrem Nachrichtenfluss
einschließen, müssen Sie die vom Knoten bereitgestellten Informationen lesen, um
nachvollziehen zu können, wie Fehler auf diesen Knoten behandelt werden. Die Beschreibungen
dieses Kapitels beschränken sich auf integrierte Knoten.
Wenn Sie ein eigenes
Fehlerbehandlungsverfahren entwerfen, beachten Sie die folgenden Faktoren:
- Die meisten der integrierten Knoten verfügen über Fehlerterminals. Dies gilt nicht für
folgende Knoten: Aggregationssteuerung (AggregateControl), Aggregationsanforderung
(AggregateRequest), Empfang (Input), Zieladresse (Label), Senden
(Output), Passthrough, Veröffentlichung (Publication), Echtzeiteingabe (Real-timeInput),
EchtzeitoptimierterFluss (Real-timeOptimizedFlow),
Ausnahme (Throw), Trace und TryCatch.
Wenn in einem Knoten eine Ausnahme erkannt wird,
werden die Nachricht und die Ausnahmeinformationen an das Fehlerterminal des Knotens übergeben.
Falls der Knoten kein Fehlerterminal besitzt oder keine Verbindung mit dem Fehlerterminal besteht,
löst der Broker eine Ausnahme aus und gibt die Steuerung an den nächstliegenden
vorherigen Knoten zurück, der die Ausnahme verarbeiten kann. Dabei kann es sich um einen
TryCatch-Knoten, einen Knoten für Aggregationsantworten oder den Empfangsknoten handeln.
Wenn ein MQEmpfangsknoten einen internen Fehler entdeckt, verhält er sich etwas anders. Bei einem nicht verbundenen Fehlerterminal versucht er, die
Nachricht in die Warteschlange zum Wiedereinreihen zurückgesetzter Nachrichten der Eingabewarteschlange zu stellen oder (falls diese nicht definiert ist) in die Warteschlange für nicht zustellbare Post des Warteschlangenmanagers des Brokers.
Weitere Informationen finden Sie unter:
- Ein kleiner Teil der integrierten Knoten verfügt über Abfangterminals.
Dazu zählen Knoten für Aggregationsantworten, HTTPEmpfangsknoten, MQEmpfangsknoten,
SCADAEmpfangsknoten, JMSEmpfangsknoten, JMSSendeknoten, Zeitlimitbenachrichtigungsknoten und Versuchs-/Abfangknoten.
Eine Nachricht wird nur dann
an ein Abfangterminal weitergeleitet, wenn sie vorher an ein Ziel außerhalb des Knotens
weitergeleitet wurde (z. B. an die Knoten, die mit dem Ausgangsterminal verbunden sind).
- Wenn eine Nachricht an das Fehler- oder Abfangterminal weitergeleitet wird, erstellt der Knoten
eine neue Ausnahmeliste (ExceptionList) und füllt diese mit einer Ausnahme, die den aufgetretenen
Fehler beschreibt. Die Ausnahmeliste wird als Teil der Nachrichtenbaumstruktur weitergegeben.
- Die MQEmpfangsknoten und Zeitlimitbenachrichtigungsknoten verfügen über weitere Verarbeitungen für transaktionsorientierte Nachrichten (andere Empfangsknoten bearbeiten keine transaktionsorientierten Nachrichten).
Weitere Informationen hierzu finden Sie in den folgenden Abschnitten:
- Wenn Sie einen Traceknoten einschließen, der $Root oder $Body
angibt, wird die gesamte Nachricht analysiert. Dadurch können Parser-Fehler generiert werden, die
ansonsten nicht erkannt werden.
Allgemeine Grundsätze der Fehlerbehandlung:
- Wenn Sie eine Verbindung mit dem Abfangterminal des Empfangsknotens herstellen, legen Sie damit
fest, dass der Nachrichtenfluss alle Ausnahmen, die irgendwo im Ausgabedatenfluss generiert werden,
behandelt. Der Broker führt erst dann eine ROLLBACK-Operation oder sonstige Aktion aus, wenn im
Abfangdatenfluss eine Ausnahme vorliegt. Wenn Sie möchten, dass eine ROLLBACK-Operation ausgeführt
wird, nachdem eine Ausnahme ausgelöst und abgefangen wurde, müssen Sie dies im Abfangdatenfluss
bereitstellen.
- Falls Sie keine Verbindung mit dem Abfangterminal des MQEmpfangsknotens oder
HTTPEmpfangsknotens herstellen, können Sie eine Verbindung mit dem Fehlerterminal herstellen
und einen Fehlerdatenfluss zur Behandlung von Ausnahmen, die von dem Knoten generiert werden,
bereitstellen. Der Fehlerdatenfluss wird unverzüglich aufgerufen, sobald eine Ausnahme in dem
Knoten auftritt.
Der Fehlernachrichtenfluss wird auch aufgerufen, wenn eine Ausnahmebedingung in der Folge nach dem MQEmpfangsknoten (entweder im Ausgabe- oder im Catch-Nachrichtenfluss). Es handelt sich um eine transaktionsorientierte Nachricht, und das Zurückstellen der Nachricht in der Eingabewarteschlange lässt den Rücksetzungszähler auf den Grenzwert für die ROLLBACK-Operation steigen.
Die Empfangsknoten HTTPInput und SCADAInput leiten die Nachricht
nicht an das Fehlerterminal weiter, wenn eine Ausnahme außerhalb des Knotens generiert wird und Sie
keine Verbindung mit dem Abfangterminal hergestellt haben.
- Wenn ein Knoten eine Nachricht an einen Abfangdatenfluss weiterleitet und eine andere Ausnahme
auftritt, durch die die Steuerung wieder an denselben Knoten zurückgegeben wird, behandelt der
Knoten die Nachricht so, als würde keine Verbindung mit dem Abfangterminal bestehen.
- Wenn Sie weder mit den Fehler- noch den Abfangterminals des Empfangsknotens eine Verbindung
herstellen, stellt der Broker eine Standardverarbeitung zur Verfügung (die vom jeweiligen Typ des
Empfangsknotens abhängig ist).
- Falls Sie ein umfassenderes Fehlerbehandlungs- und Wiederherstellungsverfahren
benötigen, fügen Sie einen oder mehrere TryCatch-Knoten ein, um eine stärker auf lokale
Anforderungen bezogene Fehlerbehandlung bereitzustellen.
- Wenn Sie über eine allgemeine Prozedur zur Behandlung bestimmter Fehler verfügen, kann es
sinnvoll sein, einen untergeordneten Datenfluss zu erstellen, der die erforderliche Knotenfolge
enthält. Fügen Sie diesen untergeordneten Datenfluss immer dann ein, wenn die zugehörige Aktion
ausgeführt werden soll.
Weitere Informationen hierzu finden Sie in den folgenden Abschnitten:
Wenn Ihre Nachrichtenflüsse Datenbankaktualisierungen einschließen, kann die
Art und Weise, wie Sie die Knoten konfigurieren, die mit den betreffenden Datenbanken interagieren,
die Art und Weise der Fehlerbehandlung beeinflussen:
- Sie können angeben, ob Aktualisierungen festgeschrieben oder zurückgesetzt werden. Über die
Knoteneigenschaft Transaktion können Sie
festlegen, ob Datenbankaktualisierungen mit dem Nachrichtenfluss festgeschrieben oder zurückgesetzt
werden (Option Automatisch) oder ob sie
festgeschrieben oder zurückgesetzt werden, wenn der Knoten selbst beendet wird (Option
Festschreiben). Sie müssen sicherstellen,
dass die Kombination aus diesen Eigenschaften und der Fehlerverarbeitung des Nachrichtenflusses zum
richtigen Ergebnis führt.
- Sie können festlegen, wie Datenbankfehler behandelt werden. Über die Eigenschaften
Warnungen als Fehler behandeln und
Ausnahme für Datenbankfehler ausgeben können Sie
das Standardverhalten der Datenbankfehlerbehandlung ändern.
Weitere Informationen zu koordinierten Datenbankaktualisierungen
finden Sie unter Knoten für koordinierte Nachrichtenflüsse konfigurieren.
Bei der Aggregation von Nachrichtenflüssen sollten Sie einige Dinge einbeziehen, die
nicht in diesem Abschnitt behandelt wurden. Weiter Informationen dazu finden Sie unter
Handhabung von Ausnahmebedingungen in Aggregationsflüssen.
Das Beispielprogramm 'Error Handler' veranschaulicht die Verwendung einer Fehlerbehandlungsroutine zum Erfassen von Fehlerinformationen und Speichern der Informationen in einer Datenbank. Bei der Fehlerbehandlungsroutine handelt es sich um einen untergeordneten Nachrichtenfluss, der unverändert jedem beliebigen Nachrichtenfluss zugeordnet werden kann.
Das Beispielprogramm veranschaulicht zudem die Konfiguration von Nachrichtenflüssen zur Steuerung von Transaktionalität; insbesondere die Verwendung global koordinierter Transaktionen zur Sicherstellung der allgemeinen Datenintegrität.