ESQL für die Fehlerbehandlung codieren

Bei der Verarbeitung von Nachrichten in einem Nachrichtenfluss kann es eine Reihe von Ursachen für Fehler geben, und der Entwickler des Nachrichtenflusses muss entscheiden, wie mit diesen Fehler umgegangen wird.

Einführung

Bei der Verarbeitung von Nachrichten in Nachrichtenflüssen können durch folgende Ursachen Fehler auftreten:
  • 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.
  • 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 ü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. Im transaktionsorientierten Modell wird die fehlgeschlagene Eingabenachricht erneut in die Eingabewarteschlange eingereiht, und der Broker startet einen neuen Verarbeitungsversuch. 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 gültigen Nachrichten durch die fehlgeschlagene Nachricht eine Weile aufgehalten, und der Broker fährt fort, ohne die Nachricht verarbeitet zu haben.

Die meisten Datenbanken arbeiten transaktionsorientiert, d. h., alle Änderungen an Datenbanktabellen werden bei der erfolgreichen Nachrichtenverarbeitung festgeschrieben bzw. beim Fehlschlagen zurückgesetzt. Dadurch wird die Datenintegrität garantiert. Dies gilt nicht beim Fehlschlagen des Brokers oder einer Datenbank (z. B. wenn die Stromversorgung der Rechner, auf denen die Datenbank bzw. der Broker ausgeführt wird, unterbrochen ist). 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. Falls diese Eventualitäten für Sie von Bedeutung sind, koordinieren Sie den Fluss, und konfigurieren Sie die betroffenen Datenbanken.

Angepasste Fehlerbehandlung verwenden

In der folgenden Liste finden Sie allgemeine Tipps zur Erstellung von angepassten Fehlerbehandlungsprogrammen.
  • 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).
  • 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 finden Sie unter Ausnahmebedingung ausgeben.
  • Wenn ein Knoten eine Ausnahmebedingung generiert, die nicht vom Fehlerbehandlungsprogramm abgefangen wird, wird der Nachrichtenfluss bei einem verbundenen Fehlerterminal zu diesem Fehlerterminal umgeleitet oder, wenn kein keine Verbindung mit einem Fehlerterminal besteht, von der standardmäßigen Fehlerbehandlung verarbeitet.

    Verwenden Sie Fehlerterminals zum Abfangen von nicht behobenen Fehlern. Fügen Sie einen einfachen Logikablauf an das Fehlerterminal 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; weitere Informationen finden Sie unter Baumstruktur für Ausnahmeliste.

  • 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. Beispiele zur Verwendung finden Sie unter Ausnahmebedingung ausgeben und Datenbankstatus erfassen.

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. Es ist 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 aufgrund von fehlerhaften Informationen zum Nachrichtenformat scheinbar ungültig sind) gestaltet sich schwierig, da der Broker nicht weiß, was die Nachricht enthält. Die beste Vorgehensweise bei diesem Problem ist normalerweise 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:
  • Die Datenbank funktioniert überhaupt nicht (sie ist beispielsweise offline).
  • Die Datenbank funktioniert, verarbeitet aber Ihre Anfrage nicht (es tritt beispielsweise ein Zugriffskonflikt auf).
  • 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.

Datenbank funktioniert nicht
Wenn eine Datenbank überhaupt nicht funktioniert, für die Nachrichtenverarbeitung jedoch erforderlich ist, haben Sie normalerweise nur wenige Möglichkeiten. Das Fehlerbehandlungsprogramm kann nach der Fehlerermittlung folgendermaßen vorgehen:
  • RESIGNAL-Anweisung zum erneuten Auslösen des ursprünglichen Fehlers verwenden und dadurch das standardmäßige Fehlerbehandlungsprogramm einsetzen.
  • Eine 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.

Anforderung wird von der Datenbank abgelehnt
Das Auftreten eines Zugriffskonflikts ähnelt dem Fall "Datenbank funktioniert nicht", da 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.

Eigene Logik zur Bearbeitung von Fehlern in Sendeknoten verwenden

Bei 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.

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 aufgrund ungeeigneter Daten oder das Fehlschlagen beim Zugriff auf ein Nachrichtenfeld aufgrund einer Integritätsbedingung für den Typ. Vom Broker werden zwei Programmierungsstrategien zur Behebung dieser Fehlertypen angeboten.
  • Der Fehler verursacht eine Ausnahmebedingung, die behoben wird oder durch die die Transaktion zurückgesetzt wird.
  • 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 Terminals besser steuern zu können.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:20

ac17140_