Reporting and Handling Errors

The options for error handling depend on the type of communication chosen:

Asynchronous Communication: On the sender side, the application can only handle errors that occur when the message is being sent (for example, the outbound queue is full). You can catch and persist these errors by using the exception class CX_AI_SYSTEM_FAULT. On the receiver side, as in the synchronous case, you can define fault messages that are then only forwarded to monitoring (and not to the sender).
If you want to define how the sender is to process asynchronous errors, refer to the Acknowledgments chapter.
In the case of synchronous communication, you can use fault messages to handle errors that have occurred on the receiver side. To confirm an error, the proxy runtime sends the fault message from the receiver back to the sender, which can then respond to it.

Process

The example used here works with the XI runtime standardized structure. When using the Web service runtime, follow the same procedure to trigger an exception on the receiver side and handle it on the sender side (indicated in the source text by the comments with a hash symbol #). The fault message structure is defined by the WSDL description in both cases and is found in the exception class.

Error Handling Example
Call at the Sender and Error Handling	Service Called at the Receiver
`DATA:` `lo_mes TYPE REF TO` [Client Proxy Class], `l_sys_exc TYPE REF TO cx_ai_system_fault,` `l_app_exc TYPE REF TO cx_ai_application_fault.` `CREATE OBJECT lo_mes.` `TRY`. `CALL METHOD lo_mes->EXECUTE_SYNCHRONOUS` `EXPORTING` `OUTPUT = ls_request` `IMPORTING` `INPUT = ls_response.` `[...]` `CATCH cx_ai_system_fault INTO l_sys_exc.` `* handle system error EXIT.` `CATCH cx_fault_1 INTO l_app_exc.` `* handle application error 1` `[...]` `* ############################` `CATCH cx_fault_n INTO l_app_exc.` `* ############################` `* handle application error n` `CATCH cx_ai_application_fault INTO l_app_exc.` `* handle other * application errors` `ENDTRY.`	`METHOD EXECUTE_SYNCHRONOUS.` `DATA:` `l_standard_data TYPE [StandardFaultDataType],` `l_detail_data TYPE [DetailType],` `l_additional_data_1 TYPE [AdditionalFaultData_1],` `[...]` `l_additional_data_n TYPE [AdditionalFaultData_n].` `[...]` `IF` `IF [error condition n].` `l_standard_data-fault_text = ...` `l_standard_data-fault_url = ...` `l_detail_data-severity = ...` `l_detail_data-text = ...` `l_detail_data-id = ...` `l_detail_data-url = ...` `APPEND l_detail_data TO l_standard_data-fault_detail.` `l_additional_data_n = ...` `* ####################################` `RAISE EXCEPTION TYPE CX_FAULT_N` `EXPORTING` `standard = l_standard_data` `addition = l_additional_data_n.` `* ####################################` `ENDIF.` `ENDMETHOD.`

If an application on the receiver side triggers an error, the ABAP proxy runtime converts the corresponding exception class to a fault message and transfers it to the sender system.
In the sender system, the ABAP proxy runtime interprets the fault message and triggers the exception for the consumer proxy.
In the sender system, the application can catch and handle the exception using a Try/Catch block. With the help of the super exception class CX_AI_APPLICATION_FAULT, you can catch all other application errors in a CASE statement, similar to using the statement WHEN OTHERS.