Fault Message Type 

Use

Fault message types are designed for application-specific errors that occur at the provider (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 operations of service interfaces. As with a message type, a fault message type is made up of data types (see below). Since fault message types are only intended for use in synchronous communication, you cannot assign fault message types to asynchronous operations of outbound service interfaces.

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 an 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 ES Repository, which is referenced by operations of both service interfaces. When you generate the proxies for the service 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.