Reporting and Handling Errors 

Purpose

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, which are then only forwarded to monitoring (and not to the sender).
If you want to define how the sender is to process asynchronous errors, see the Acknowledgments section. The Web service runtime only supports synchronous communication.

●      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 Flow

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.

Troubleshooting 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 [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.

 

...

       1.      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.

       2.      In the sender system, the ABAP proxy runtime interprets the fault message and triggers the exception for the consumer proxy.

       3.      In the sender system, the application can catch and handle the exception using a Try/Catch block. Using the super exception class CX_AI_APPLICATION_FAULT you can - in a similar way to the statement WHEN OTHERS in a CASE statement - catch all remaining application errors.