
Fault-Message-Typen sind für anwendungsspezifische Fehler konzipiert, die beim Provider (Inbound-Seite) auftreten und an den Sender zurückgemeldet beziehungsweise im Monitoring persistiert werden:
Anwendungsspezifisch heißt, dass die Anwendung auf Inbound-Seite den Fehler selbst auslöst, weil zum Beispiel nicht genügend Informationen in der Request-Message vorhanden waren.
Ein Fault-Message-Typ ist ein spezieller Message-Typ, der in Operationen von Service-Interfaces verwendet werden kann. Genau wie bei einem Message-Typ wird ein Fault-Message-Typ daher aus Datentypen aufgebaut (siehe unten). Da Fault-Message-Typen für synchrone Kommunikation konzipiert sind, können Sie asynchronen Operationen von Outbound-Service-Interfaces keine Fault-Message-Typen zuweisen.
Aufbau eines Fault-Message-Typs
| Datenteil | Verwendung |
|---|---|
|
Standarddaten (obligatorisch) |
Mit Hilfe dieses Datenteils können Sie zur Laufzeit der Fault-Message Standard-Informationen zu einem Fehler zurückgeben. Alle Fault-Message-Typen referieren für diesen Teil den Datentyp ExchangeFaultData und indirekt den Datentyp ExchangeLogData. Diese Datentypen werden automatisch in einem Namensraum angelegt, wenn Sie dort den ersten Fault-Message-Typ anlegen. |
|
Zusatzdaten (optional) |
Mit Hilfe dieses Datenteils können Sie beliebige weitere anwendungsspezifische Informationen an Ihre Fault-Message hängen. Dazu verweisen Sie auf einen beliebigen Datentyp in der gleichen oder einer unterliegenden Software-Komponentenversion. |
Bei der Generierung eines Proxy aus einem Message-Interface wird für einen Fault-Message-Typ eine Exception-Klasse generiert, mit der Sie Anwendungsfehler zur Laufzeit behandeln können (siehe auch das Beispiel unten).
Siehe auch: Fault-Messages (ABAP) beziehungsweise Fault-Messages (Java).
In dem folgenden Beispiel meldet ein ABAP-Empfänger einen Anwendungsfehler an einen Java-Sender zurück, der bei der Inbound-Verarbeitung auftritt:
Um den Fehler zu behandeln, wurde dazu zunächst ein Fault-Message-Typ Fm im ES Repository angelegt, der von Operationen beider Service-Interfaces referenziert wird. Bei der Generierung der Proxies zu den Service-Interfaces werden dabei die Exception-Klassen FmException (Java) und CX_FM (ABAP) generiert.Die Grafik zeigt die Übermittlung des Fehlers, nachdem die Anwendung auf der ABAP-Seite die entsprechenden Daten an die Exception-KlasseCX_FM übergeben und sie mit RAISE ausgelöst hat:Die Proxy-Laufzeit erzeugt anschließend aus den Daten der Exception-Klasse eine Fault-Message, die an den Sender übertragen wird. Dort wird dann die Ausnahme zur Exception-Klasse FmException ausgelöst, so dass der Fehler beim Sender behandelt werden kann.