Troubleshooting 

Function

Use the ABAP proxy runtime to handle the following errors:

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

●      Application errors that 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 Enterprise Services Repository (see: Fault Message Type). Using fault messages, you can handle errors triggered by the called application or retain them in the database for monitoring purposes:

Service Interface	Error Handling Options
Synchronous Communication (Inbound/Outbound/Abstract)	Triggering an error at the receiver that is providing a service; handling the error at 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 retained in the database for monitoring instead.