Fehlerbehandlung 

Verwendung

Es gibt folgende Fehler, die Sie mit Hilfe der ABAP-Proxy-Laufzeit behandeln können:

●      Systemfehler, die durch die Laufzeit ausgelöst werden. Dabei kann es sich zum Beispiel um einen Übertragungsfehler auf Grund eines ausgefallenen Servers handeln.

●      Anwendungsfehler, die allein durch eine Anwendung ausgelöst beziehungsweise behandelt werden. Ein Beispiel wäre die Anforderung von Daten zu einem Material, das im Empfängersystem unbekannt ist.

Die Behandlung von Anwendungsfehlern ist hauptsächlich für den synchronen Fall interessant. In diesem Fall kann ein Empfänger einem Sender mitteilen, dass ein Anwendungsfehler bei der Verarbeitung einer Request-Message aufgetreten ist.

Funktionsumfang

Behandlung von Systemfehlern

Fehler, die bei der Übertragung einer Message aufgetreten sind, können Sie mit Hilfe der Ausnahmeklasse CX_AI_SYSTEM_FAULT abfangen. Systemfehler werden über Fehlerkodes unterschieden, die systemübergreifend verwaltet und dokumentiert werden. Die Anwendung kann mit Hilfe der Attribute CODE und ERRORTEXT der Ausnahmeklasse eine Fehlermeldung ausgeben.

Behandlung von Anwendungsfehlern

Für die Behandlung von Anwendungsfehlern sind in WSDL Fault-Messages (Fehlernachrichten) vorgesehen. Die Proxy-Generierung generiert daraus Ausnahmeklassen (Präfix CX_).

Ausnahmeklassen für Anwendungsfehler sind von der Basis-Ausnahmeklasse CX_AI_APPLICATION_FAULT abgeleitet. Sie können sie verwenden, um unabhängig von dem genauen Fehler eine Fehlersitiuation festzustellen oder in einem CATCH-Zweig all die Fehler abzufangen, die bis dahin nicht behandelt worden sind.

Fault-Message-Typen in XI

Für Service-Interfaces im Enterprise Services Repository können Sie diese explizit anlegen (siehe: Fault-Message-Typ). Mit Hilfe der Fault-Messages können Fehler behandelt oder zu Monitoring-Zwecken persistiert werden, die durch die gerufene Anwendung ausgelöst werden:

Service-Interface	Möglichkeiten zur Fehlerbehandlung
Synchrone Kommunikation (Inbound/Outbound/Abstrakt)	Auslösen eines Fehlers beim Empfänger, der einen Service bereitstellt und Behandeln dieses Fehlers beim Sender, der den Service aufgerufen hat.
Asynchrones Inbound-Interface	Fault-Messages dienen hier nicht dazu, einen Fehler beim Sender zu behandeln. Die durch den ausgelösten Fehler erzeugte Fault-Message wird statt dessen für das Monitoring persistiert.