Error Handling 

Use

You use the ABAP proxy runtime to handle the following errors:

·        System errors, which are triggered by the runtime. These might be errors during transfer, due to a failed server, for example.

·        Application errors, which are triggered or handled by the application alone. An example would be a request for data about a material that is unknown in the receiver system.

Application error handling is essentially of interest in the synchronous case. In this case, a receiver can inform a sender that an application error has occurred during processing of a request message.

Features

Handling System Errors

You catch errors that occur when transferring a message by using the exception class CX_AI_SYSTEM_FAULT. You distinguish system errors using error codes; these are managed and documented centrally for all systems. The application can display an error message by using the attributes CODE and ERRORTEXT of the exception class.

Handling Application Errors

Fault messages are provided in WSDL for handling application errors. The proxy generation functions use these to generate the exception classes (prefix CX_).

Exception classes for application errors are derived from the basis exception class CX_AI_APPLICATION_FAULT. You can use this exception class to determine an error situation, independently of the exact error, or in a CATCH branch, you can use it to catch all the errors that have not yet been handled.

Fault Message Types in XI

You can create fault message types explicitly for message interfaces in the XI Integration Repository (see: Fault Message Type). You can use fault messages to handle errors triggered by the called application or persist them for monitoring purposes:

Message Interface	Error Handling Options
Synchronous Communication (Inbound/Outbound/Abstract)	An error is triggered at the receiver that is providing a service; the error is handled by the sender that called the service.
Asynchronous Inbound Interface	Fault messages are not used here to handle an error at the sender. The fault message generated by the triggered error is persisted for monitoring instead.