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 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.
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.
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.)
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:
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.
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.
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.
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.
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.
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.
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.