ESQL für die Fehlerbehandlung codieren

Einführung

Bei der Verarbeitung von Nachrichten in Nachrichtenflüssen können durch folgende Ursachen Fehler auftreten:
  1. Externe Ursachen. Beispielsweise ist die eingehende Nachricht syntaktisch ungültig, eine vom Nachrichtenfluss verwendete Datenbank wurde beendet oder die Stromversorgung des Systems, auf dem der Broker ausgeführt wird, ist unterbrochen.
  2. Interne Ursachen. Beispielsweise kann eine Zeile wegen der Überprüfung von Vorgaben nicht in eine Datenbanktabelle eingefügt werden oder eine Zeichenfolge, die aus einer Datenbank gelesen wird, kann nicht in eine Zahl umgewandelt werden, da alphabetische Zeichen enthalten sind.

    Interne Fehler können durch Programme verursacht werden, die ungültige Daten in der Datenbank speichern, oder durch einen Fehler in der Logik eines Nachrichtenflusses.

Die Entwickler von Nachrichtenflüssen müssen Fehler berücksichtigen und über die weitere Vorgehensweise entscheiden.

Standardmäßige Fehlerbehandlung verwenden

Die einfachste Strategie bei der Behandlung von ESQL-Fehlern ist, nichts zu tun und das Standardverhalten des Brokers zu verwenden. Dabei wird die Verarbeitung der fehlgeschlagenen Nachricht abgebrochen und mit der Verarbeitung der nächsten Nachricht fortgefahren. In den Empfangs- und Sendeknoten werden Optionen bereitgestellt, die die Vorgehensweise beim Abbruch der Verarbeitung genau steuern.

Wenn für die Empfangs- und Sendeknoten der Transaktionsmodus festgelegt wurde, stellt der Broker den Status zum Zeitpunkt vor der Verarbeitung dieser Nachricht wieder her:
  1. Die Eingabenachricht, die offenbar aus der Eingabewarteschlange stammt, wird dort erneut eingereiht.
  2. Alle Ausgabenachrichten, die der Nachrichtenfluss offenbar in die Ausgabewarteschlangen geschrieben hat, werden gelöscht.
Wenn für die Empfangs- und Sendeknoten nicht der Transaktionsmodus festgelegt wurde, werden folgende Aktionen ausgeführt:
  1. Die Eingabenachricht aus der Eingabewarteschlange wird nicht erneut eingereiht.
  2. Alle Ausgabenachrichten, die der Nachrichtenfluss in die Ausgabewarteschlangen geschrieben hat, verbleiben dort.

Beide Strategien haben Vorteile. Durch den Transaktionsmodus wird die Konsistenz der Daten gewahrt, während beim nicht-transaktionsorientierten Modell die Kontinuität der Nachrichtenverarbeitung maximiert wird. Beachten Sie, dass die fehlgeschlagene Eingabenachricht beim transaktionsorientierten Modell erneut in die Eingabewarteschlange eingereiht wird und der Broker wieder einen Verarbeitungsversuch startet. Die Nachricht wird wahrscheinlich weiterhin fehlschlagen, bis das Wiederholungslimit erreicht wird und die Nachricht in einer Warteschlange für nicht zustellbare Nachrichten eingereiht wird. Die Fehlerursache bei der Verarbeitung der Nachricht wird im Systemereignisprotokoll (Windows) oder im Systemprotokoll (UNIX) protokolliert. Dadurch wird die Verarbeitung der nachfolgenden fehlerfreien Nachrichten durch die fehlgeschlagene Nachricht eine Weile aufgehalten, und anschließend fährt der Broker fort, ohne die Nachricht verarbeitet zu haben.

Die meisten Datenbanken arbeiten transaktionsorientiert, d. h., alle Änderungen an Datenbanktabellen werden bei der erfolgreichen Nachrichtenverarbeitung festgeschrieben und beim Fehlschlagen zurückgesetzt. Dadurch wird die Datenintegrität garantiert. Dies gilt nicht beim Fehlschlagen des Brokers oder einer Datenbank (wenn beispielsweise die Stromversorgung des ausführenden Systems unterbrochen wird). In diesen Fällen werden die Änderungen nicht immer in den Datenbanken festgeschrieben; es kommt auch vor, dass die Änderungen an der Datenbank, jedoch nicht die Eingabe- und Ausgabenachrichten festgeschrieben werden. Wenn Sie dies vermeiden möchten, sollten Sie einen koordinierten Nachrichtenfluss verwenden und die involvierten Datenbanken für diese Verarbeitungsart konfigurieren.

Angepasste Fehlerbehandlung verwenden

Hier finden Sie einige allgemeine Hinweise zur Erstellung von angepassten Fehlerbehandlungsprogrammen:
  1. Wenn Ihnen die standardmäßige Fehlerbehandlung nicht ausreicht, sollten Sie als Erstes ein Fehlerbehandlungsprogramm verwenden (weitere Informationen dazu finden Sie unter DECLARE HANDLER-Anweisung). Erstellen Sie für jeden Knoten ein Fehlerbehandlungsprogramm, damit alle möglichen Ausnahmebedingungen abgefangen werden können (oder zumindest die Ausnahmebedingungen, die vorhergesehen werden können).
  2. Nach dem Abfangen eines Fehlers verwendet das Fehlerbehandlungsprogramm die für die Fehlerbehandlung geeignete Logik. Alternativ dazu kann durch eine THROW-Anweisung oder einen Knoten eine Ausnahmebedingung erstellt werden, die weiter oben in der Logik des Nachrichtenflusses behoben werden oder sogar den Empfangsknoten erreichen könnte. Die Transaktion wird dadurch zurückgesetzt. Weitere Informationen hierzu finden Sie unter Ausnahmebedingung ausgeben.
  3. Wenn ein Knoten eine Ausnahmebedingung auslöst, die nicht vom Fehlerbehandlungsprogramm abgefangen wird, wird der Nachrichtenfluss bei einem angehängten Fehlerterminal zu diesem Fehlerterminal umgeleitet oder, wenn kein Fehlerterminal angehängt ist, von der standardmäßigen Fehlerbehandlung verarbeitet.

    Verwenden Sie Fehlerterminals zum Abfangen von nicht behobenen Fehlern. Fügen Sie an das Fehlerterminal einen einfachen Logikablauf an. Der Logikablauf kann aus einem Datenbank- oder Rechenknoten bestehen, der einen Protokollsatz in eine Datenbank (wahrscheinlich einschließlich dem Bitstrom der Nachricht) oder einen Eintrag in das Ereignisprotokoll schreibt. Es kann auch ein Sendeknoten enthalten sein, der die Nachricht in eine bestimmte Warteschlange schreibt.

    Die vollständige Baumstruktur für die Ausnahmebedingung wird an einen Knoten weitergeleitet, der mit einem Fehlerterminal verbunden ist. (Eine Beschreibung der Baumstruktur für die Ausnahmebedingung finden Sie unter Baumstruktur für Ausnahmelisten.)

  4. Ihre Fehlerbehandlungsprogramme sind für die Protokollierung jedes Fehlers an einem geeigneten Standort (z. B. dem Systemereignisprotokoll) zuständig.

Der Abschnitt Fehler in Nachrichtenflüssen behandeln enthält ausführliche Informationen zu den Optionen, die zur Fehlerverarbeitung in einem Nachrichtenfluss verwendet werden können. Die folgenden Themen enthalten Beispiele zur entsprechenden Vorgehensweise:

Codierung für die Fehlerermittlung

In den folgenden Abschnitten wird davon ausgegangen, dass der Fehler vom Broker festgestellt wird. Es ist jedoch möglich, dass ein Fehler auch von der Logik des Nachrichtenflusses ermittelt wird. Bei der Codierung der Nachrichtenflusslogik können Sie beispielsweise folgende Funktionen verwenden:
  • IF-Anweisungen, die speziell für die Erkennung von Situationen eingesetzt werden, die nicht auftreten sollten.
  • Die ELSE-Klausel eines CASE-Ausdrucks oder einer CASE-Anweisung für das Abfangen von Codierungswegen, die nicht möglich sein sollten.
Stellen Sie sich als Beispiel für einen von der Logik des Nachrichtenflusses erkannten Fehler ein Feld mit einer Reihe von möglichen ganzzahligen Werten vor, die den Nachrichtentyp anzeigen. In diesem Fall ist es nicht empfehlenswert, den Eingang einer Nachricht, deren Feldwert keinem bekannten Nachrichtentyp entspricht, dem Zufall zu überlassen. Diese Möglichkeit besteht beispielsweise, wenn für das System ein Upgrade zur Unterstützung zusätzlicher Nachrichtentypen durchgeführt wurde, für einen Teil des Systems dieser Upgrade jedoch nicht stattgefunden hat.

Eigene Logik zur Bearbeitung von ungültigen Eingabenachrichten verwenden

Die Bearbeitung von syntaktisch ungültigen Eingabenachrichten (und von Eingabenachrichten, die auf Grund von fehlerhaften Informationen zum Nachrichtenformat scheinbar ungültig sind) gestaltet sich schwierig, da der Broker nicht weiß, was die Nachricht enthält. Die vermutlich beste Vorgehensweise bei diesem Problem ist die Konfiguration des Empfangsknotens, damit die Nachricht vollständig analysiert und ausgewertet werden kann.

Dies gilt jedoch nur für vordefinierte Nachrichten wie MRM oder IDOC.

Wenn der Empfangsknoten auf diese Weise konfiguriert ist, wird Folgendes garantiert, wenn die Syntax der Eingabenachricht nicht erfolgreich analysiert werden kann:
  • Die Eingabenachricht tritt nie im normalen Ausgabeterminal des Knotens auf (sie wird an das Fehlerterminal weitergeleitet).
  • Die Eingabenachricht gelangt nie in den Hauptteil des Nachrichtenflusses.
  • Die Eingabenachricht löst keine Datenbankaktualisierungen aus.
  • Es werden keine Nachrichten in Ausgabewarteschlangen geschrieben.

Fügen Sie bei fehlgeschlagenen Nachrichten einen einfachen Logikablauf an das Fehlerterminal an.

Wenn der normale Nachrichtenfluss keinen Zugriff auf alle Felder der Nachricht anfordert, hat diese Strategie den Nachteil, dass die Veranlassung einer vollständigen Syntaxanalyse der Nachricht die Leistung beeinträchtigt.

Eigene Logik zur Bearbeitung von Datenbankfehlern verwenden

Es gibt drei Arten von Datenbankfehlern:
  1. Die Datenbank funktioniert überhaupt nicht (sie ist beispielsweise offline).
  2. Die Datenbank funktioniert, verarbeitet aber Ihre Anfrage nicht (es tritt beispielsweise ein Zugriffskonflikt auf).
  3. Die Datenbank funktioniert, Ihre Anfrage ist jedoch nicht durchführbar (z. B. das Lesen aus einer nicht vorhandenen Tabelle).

Wenn Ihnen die standardmäßige Fehlerbehandlung nicht ausreicht, sollten Sie als Erstes ein Fehlerbehandlungsprogramm verwenden (weitere Informationen zum Abfangen der Ausnahmebedingung finden Sie unter DECLARE HANDLER-Anweisung). Das Fehlerbehandlungsprogramm kann aus dem von der Datenbank zurückgegebenen SQL-Status die Art des Fehlers ermitteln.

Die Datenbank funktioniert nicht
Wenn eine Datenbank überhaupt nicht funktioniert, für die Nachrichtenverarbeitung jedoch erforderlich ist, haben Sie vermutlich nur wenige Möglichkeiten. In diesem Fall kann das Fehlerbehandlungsprogramm nach der Fehlerermittlung folgendermaßen vorgehen:
  • RESIGNAL-Anweisung zum erneuten Auslösen des ursprünglichen Fehlers verwenden und dadurch das standardmäßige Fehlerbehandlungsprogramm einsetzen.
  • Andere Datenbank verwenden.
  • Nachricht in eine bestimmte Ausgabewarteschlange schreiben.

    Gehen Sie bei dieser Strategie aber vorsichtig vor. Da die Ausnahmebedingung vom Fehlerbehandlungsprogramm aufgenommen wird, werden alle Änderungen an anderen Datenbanken oder Einträge in Warteschlangen festgeschrieben.

Die Datenbank verweigert Ihre Anfrage
Das Auftreten eines Zugriffskonflikts ähnelt dem Fall "Datenbank funktioniert nicht". Der Grund dafür ist, dass die Datenbank in diesem Fall nicht nur die fehlgeschlagenen Anforderungen, sondern alle Datenbankänderungen zurückgesetzt hat, die Sie an der aktuellen Nachricht vorgenommen haben. Sofern Sie nicht sicher sind, dass dies die einzige Aktualisierung war, ist die standardmäßige Fehlerbehandlung in diesem Fall die beste Strategie. Ebenfalls geeignet ist möglicherweise das Protokollieren des Fehlers oder das Weiterleiten der Nachricht an eine spezielle Warteschlange.
Nicht durchführbare Anforderungen
Wenn die Datenbank funktioniert, Ihre Anfrage jedoch nicht durchführbar ist, kann dies auf eine Reihe von Problemen zurückzuführen sein.
Wenn in der Datenbank wie im oben genannten Fall einfach keine Tabelle mit einem Namen vorhanden ist, den der Nachrichtenfluss erwartet, ist auch in diesem Fall die standardmäßige Fehlerbehandlung die beste Strategie. Ebenfalls geeignet ist möglicherweise das Protokollieren des Fehlers oder das Weiterleiten der Nachricht an eine spezielle Warteschlange.
Es können aber auch eine Reihe anderer Fehler behoben werden. So kann beispielsweise der Versuch, eine Zeile einzusetzen, fehlschlagen, da diese Zeile bereits vorhanden ist und somit doppelt vorhanden wäre. Auch die Aktualisierung einer Zeile kann fehlschlagen, wenn diese Zeile nicht vorhanden ist (d. h., durch die Aktualisierung wurden null Zeilen aktualisiert). In diesen Fällen kann das Fehlerbehandlungsprogramm jede Logik einsetzen, die Sie für geeignet halten. So kann beispielsweise die fehlende Zeile eingefügt oder eine vorhandene Zeile verwendet werden (wobei wahrscheinlich sichergestellt wird, dass die darin enthaltenen Werte geeignet sind).
Anmerkung: Wenn die Aktualisierung von null Zeilen als Fehler dokumentiert werden soll, muss für die Knoteneigenschaft "Warnungen als Fehler behandeln" 'true' festgelegt werden. Dies ist nicht die Standardeinstellung.

Eigene Logik zur Bearbeitung von Fehlern in Sendeknoten verwenden

Beginn der ÄnderungBei Fehlern in MQ-Sendeknoten wird die Art des Fehlers im SQL-Status aufgezeichnet, und in der Variablen nativer SQL-Fehler finden Sie zusätzliche Informationen. Wenn Ihnen die standardmäßige Fehlerbehandlung nicht ausreicht, sollten Sie als Erstes ein Fehlerbehandlungsprogramm zum Abfangen der Ausnahmebedingung verwenden (weitere Informationen zum Fehlerbehandlungsprogramm finden Sie unter DECLARE HANDLER-Anweisung). Ein Fehlerbehandlungsprogramm enthält normalerweise nur eine einzige PROPAGATE-Anweisung. Ende der Änderung

Eigene Logik zur Bearbeitung anderer Fehler verwenden

Neben den oben beschriebenen Fehlern kann noch eine Vielzahl anderer Fehler auftreten. Dazu gehören beispielsweise der Überlauf einer mathematischen Berechnung, das Fehlschlagen einer Umsetzung auf Grund ungeeigneter Daten oder das Fehlschlagen beim Zugriff auf ein Nachrichtenfeld auf Grund einer Integritätsbedingung für den Typ. Vom Broker werden zwei Programmierungsstrategien zur Behebung dieser Fehler angeboten.
  1. Der Fehler verursacht eine Ausnahmebedingung, die behoben wird oder durch die die Transaktion zurückgesetzt wird.
  2. Die Störung wird als Sonderwert aufgezeichnet, der später überprüft wird.

Beim Versuch, ohne Integritätsbedingung für den Typ auf ein nicht vorhandenes Nachrichtenfeld zuzugreifen, wird der Wert Null zurückgegeben. Nullwerte werden durch Ausdrücke weitergegeben, durch die man das Ergebnis Null erhält. Wenn also ein möglicherweise auch komplexer Ausdruck einen Wert zurückgibt, der nicht Null ist, können Sie sicher sein, dass es sich bei allen für die Berechnung des Ergebnisses erforderlichen Werten nicht um Nullwerte handelt.

CAST-Ausdrücke können Standardklauseln enthalten. Wenn eine DEFAULT-Klausel vorhanden ist, schlagen CAST-Ausdrücke ohne Ausgabe fehl; sie lösen keine Ausnahmebedingung aus, sondern geben einfach den DEFAULT-Wert zurück. Bei dem DEFAULT-Wert kann es sich um eine unschädliche Zahl handeln (z. B. Null für eine ganze Zahl) oder um einen Wert, der im Kontext eindeutig ungültig ist (z. B. um -1 für eine Kundennummer). Null ist möglicherweise besonders geeignet, da sich dieser Wert von allen anderen Werten unterscheidet und er außerdem durch Ausdrücke weitergegeben wird, ohne dass die Fehlerbedingung maskiert werden kann.

Fehler in anderen Knoten behandeln

Ausnahmen, die in anderen Knoten auftreten (d. h. nachgeschaltet in einer PROPAGATE-Anweisung), können wie gehabt von den Fehlerbehandlungsprogrammen abgefangen werden. Die intelligente Behandlung solcher Fehler wirft das Problem auf, dass sehr wahrscheinlich ein anderer Knoten (nicht notwendigerweise der Absender der Ausnahme) an der Fehlerbehandlung beteiligt sein wird, da ein anderer Knoten beim ursprünglichen Fehler beteiligt war.

Zur Lösung dieser Situationen verfügen die Datenbank- und Rechenknoten über vier neue Terminals namens out1, out2, out3 und out4. Des Weiteren wurde die Syntax der PROPAGATE-Anweisung um Zielausdruck, Nachrichtenquelle und Steuerungsklauseln erweitert, um diese zusätzlichen Terminals besser steuern zu können.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac17140_