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