WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

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 auslösen.
  • Wenn ein Knoten eine Ausnahmebedingung generiert, die nicht vom Fehlerbehandlungsprogramm abgefangen wird, wird der Nachrichtenfluss bei einem verbundenen Fehlerterminal (Failure) zu diesem Fehlerterminal (Failure) umgeleitet oder, wenn kein keine Verbindung mit einem Fehlerterminal (Failure) besteht, von der standardmäßigen Fehlerbehandlung verarbeitet.

    Verwenden Sie Fehlerterminals (Failure) zum Abfangen von nicht behobenen Fehlern. Fügen Sie einen einfachen Logikablauf an das Fehlerterminal (Failure) an. Der Logikablauf kann aus einem Datenbank- oder Compute-Knoten 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 (Failure) 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 auslösen 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 in diesem Fall nicht in der Lage ist, den Inhalt der Nachricht zu ermitteln. 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 (Failure) 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 (Failure) 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 nicht (sie ist beispielsweise offline).
  • Die Datenbank funktioniert, verarbeitet aber Ihre Anfrage nicht (es tritt beispielsweise ein Zugriffskonflikt auf).
  • Die Datenbank funktioniert, Ihre Anforderung 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 Ermittlung der Fehlerursache eine oder mehrere der folgenden Aktionen durchführen:
  • 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.

    Bei einer Vorgehensweise wie dieser sollten Sie vorsichtig sein; 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
Eine Anforderung ist nicht durchführbar, wenn die Datenbank zwar funktioniert, die angeforderte Aktion aber nicht ausgeführt werden kann. Dieser Fehlertyp trifft auf sehr viele Probleme zu.
Wenn in der Datenbank, wie im vorherigen Beispiel beschrieben, keine Tabelle mit dem im Nachrichtenfluss erwarteten Namen vorhanden ist, 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 die erwartete Zeile nicht vorhanden ist (d. h., durch die Aktualisierungsaktion werden 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 unter Umständen sichergestellt werden sollte, dass die darin enthaltenen Werte geeignet sind).

Wenn die Aktualisierung von null Zeilen als Fehler aufgezeichnet werden soll, müssen Sie die Eigenschaft Warnungen als Fehler behandeln im Knoten auf true setzen (dies ist nicht die Standardeinstellung.

Eigene Logik zur Bearbeitung von Fehlern in Sendeknoten verwenden

Bei Fehlern in MQOutput-Knoten 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 Datenbank- und Compute-Knoten ü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 | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:00


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ac17140_