Fault Message Type Developing Message Interfaces

Use

Fault message types are designed for application-specific errors that occur on the inbound side and that are reported back to the sender or persisted in monitoring.

· In the synchronous case, when an application-specific error occurs on the inbound side, instead of sending a response message back to the sender, the application can send a fault message to handle the error.

· The fault message of the application for an asynchronous ABAP server proxy is persisted for monitoring. In the case asynchronous of Java server proxies, the fault message is part of a negative application acknowledgement (see Acknowledgments).

Application-specific means that the application on the inbound side triggers the error itself because, for example, the request message did not contain sufficient information.

Integration

A fault message type is a special message type that can be used in message interfaces. As with a message type, a fault message type is made up of data types (see below). Fault message types are not permitted for asynchronous outbound message interfaces.

Prerequisites

For more information, see the Prerequisites section in Introduction to Interface Development.

Features

Structure of a Fault Message Type:

Data Part	Use
Standard Data (obligatory)	Use this data part to return the fault message standard information for an error at runtime. All fault message types reference the data type ExchangeFaultData for this part and, indirectly, the data type ExchangeLogData. These data types are automatically created in a namespace when you create the first fault message type there.
Additional Data (optional)	Use this data part to attach any additional application-specific information to the fault message. To do so, reference any data type in the same software component version or in a sub-software component version.

When a proxy is generated from a message interface, an exception class is generated for a fault message type. You use this exception class to handle application errors at runtime (also see the example below).

See also: Fault Messages (ABAP) or Fault Messages (Java)

Activities

...

1. Create a fault message type on the design maintenance screen of the Integration Builder (see also: Creating a New Object).

2. Enter a description for your fault message type.

3. The default setting for XML Namespace is the Repository namespace. If the message type has been copied to another namespace, overwrite the default setting.

4. In the default setting, the fault message only comprises the standard data part. If you require the additional data part, specify a data type in the Additional Data input field. The data type can be in the same software component version or in a sub-software component version.

5. Save your changes.

Example

In the example below, an ABAP receiver reports back to a Java sender that an application error has occurred during inbound processing:

To handle the error, you first create a fault message type Fm in the Integration Repository that is referenced by both message interfaces. When you generate the proxies for the message interfaces, the exception classes FmException (Java) and CX_FM (ABAP) are generated. The figure shows how the error is sent after the application on the ABAP side has transferred the relevant data to the exception class CX_FM and triggered them with RAISE. The proxy runtime then creates a fault message from the exception class data, which is sent to the sender. The exception for the exception class FmException is then triggered at the sender so that the error can be handled there.