FEH – Forward Error Handling
FEH (Forward Error Handling) is used for Error handling in Asynchronous Services.
Asynchronous inbound service operations should support service-oriented error handling: if an error is detected while executing a service call, performing the requested service is not rejected immediately. In particular, no immediate “rejection message” containing error information is sent back to the service consumer.
Also Read: SAP ABAP 7.5 Certification Preparation Guide
Instead, measures shall be taken to try to resolve the issue on the provider side, e.g. by trying to re-execute the service call after a certain while if the issue is expected to be temporary only, or by triggering a business user to resolve the issue.
Asynchronous Service can be can be registered in the PI, or directly consumed from CPI (Cloud Platform Integration).
The FEH framework uses the following components from the Reuse Library:
- The Postprocessing Office (PPO), as platform where received messages can be stored and as user interface to process resulting tasks. Any Payload of the Asynchronous service that results in error, is created as a Post Processing Order. Using the standard framework of PPO the end user can edit the payload and re-process the same.
- The Error Conflict Handler (ECH) which supports forward resolution of asynchronous messages.
- The Hierarchical Derivation Service (HDS) that enables the customer to define the resolution strategy based on the error categorizes determined in the FEH implementation.
ECH (Error and Conflict Handler): The ECH framework is instantiated from the Asynchronous Proxy Method. This is responsible for processing the Inbound Proxy logic. In case the Inbound proxy is not executed completely due to any error, the ECH framework would throw an exception and create a Post Processing Order that can be re-processed or discarded as per the generated Error message. The ECH framework is generated using the Interface IF_ECH_ACTION. This interface can be directly used in the Inbound Proxy class, but for simplified understanding and better implementation it is recommended to create a separate class.
Below are the steps in detail of how to use the FEH to handle Asynchronous Service Calls.
Step 1: Create a class that implements the IF_ECH_ACTION interface as shown below. Apart from the Interface methods add 3 more methods CREATE, PROCESS & EXECUTE. These methods are explained in more detail in the below steps
Role of each Interface method.
- IF_ECH_ACTION~S_CREATE : Generates the class Instance
- IF_ECH_ACTION~RETRY : This method is called when re-process the
- IF_ECH_ACTION~FINISH : Confirm the PPO, Action Completes the PPO if no further processing is required
- IF_ECH_ACTION~FAIL : Discard the PPO. Similar to Finish, just marks the PPO as discarded.
- IF_ECH_ACTION~NO_ROLLBACK_ON_RETRY_ERROR : This method can be used to rollback work in case reprocessing ends in error.
- IF_ECH_ACTION~FINALIZE_AFTER_RETRY_ERROR : Closing Operations after Business Error During a Repeat
Step 2: Add a Protected static attribute Object (GO_ECH_ACTION) of the same class as shown below for persistence.
Step 3: Implement the CREATE, PROCESS & EXECUTE method added in Step 1 with below code and Signature
Method EXECUTE signature
Code:
METHOD execute.
* Variable Definition
DATA: lo_exception TYPE REF TO z***_cx_standard_message_fault,
lo_fehreg TYPE REF TO cl_feh_registration.
DATA: ls_bapireturn TYPE bapiret2,
ls_standarddata TYPE z***_exchange_fault_data,
ls_logdata TYPE z***_exchange_log_data.
*Implementation of Forward Error Handling
*Create instance of CL_FEH_REGISTRATION
TRY.
IF lo_fehreg IS INITIAL.
lo_fehreg = cl_feh_registration=>s_initialize( ).
ENDIF.
CATCH cx_ai_system_fault.
ls_logdata–severity = ‘HIGH’.
MESSAGE ID gc_message_class TYPE ‘S’ NUMBER ‘007’ INTO ls_logdata–text.
APPEND ls_logdata TO ls_standarddata–fault_detail.
CLEAR: ls_bapireturn,ls_logdata.
* Raise Exception
RAISE EXCEPTION TYPE z***_cx_standard_message_fault
EXPORTING
“previous = lo_exception
standard = ls_standarddata.
ENDTRY.
TRY.
* Executing the process method
CALL METHOD me->process
EXPORTING
input = is_input
i_ref_registration = lo_fehreg
i_reprocess = abap_false
IMPORTING
es_return_message = ls_bapireturn.
* Catch the Exception
CATCH z***_cx_standard_message_fault INTO lo_exception.
* get the first (should be only) header record
ls_logdata–severity = ‘HIGH’.
ls_logdata–text = ls_bapireturn–message.
ls_standarddata–fault_text = ls_bapireturn–message.
* ls_standarddata-fault_url = lo_fehreg->
APPEND ls_logdata TO ls_standarddata–fault_detail.
CLEAR: ls_bapireturn,ls_logdata.
* Raise Exception
RAISE EXCEPTION TYPE z***_cx_standard_message_fault
EXPORTING
previous = lo_exception
standard = ls_standarddata.
ENDTRY.
ENDMETHOD.Execute method will be call from the Asynchronous Inbound service to register the FEH framework and create the PPO. Internally Execute calls the Method Process which would generate the PPO in case the Inbound service ends into error. Please make sure the Inbound Service has a Standard Fault Message (Exception Class) that must be propagated back to the Inbound Service and raised so the SRT_MONI framework can capture the Exception.
Method PROCESS Signature and Code.
METHOD process.
DATA: ls_object TYPE ech_str_object,
lv_obj_key TYPE awkey,
lv_obj_type TYPE awtyp,
lv_obj_sys TYPE awsys,
lv_belnr type belnr_d,
ls_bapiret TYPE bapiret2,
lv_error TYPE char1,
ls_standarddata TYPE z***_exchange_fault_data,
ls_logdata TYPE z***_exchange_log_data.
FIELD-SYMBOLS: <fs_return> TYPE bapiret2.
CLEAR: es_return_message.
* Forward Error Handling
IF i_ref_registration IS BOUND.
* provide information for feh
ls_object–objcat = ‘1’.
ls_object–objtype = ‘ZJPST_OBTY’. “ZPAY_OBJTY’ Object Type defined
ls_object–objkey = input–documentheader–obj_key. “Payment lot and filename
ls_object–objlogsys = input–documentheader–obj_sys.
ENDIF.
******Call the SAP Internal BAPI / Class/ API to perform the Inbound Service action and receive the ****** Error in the BAPIRET2 Structure.
READ TABLE mt_return ASSIGNING <fs_return> WITH KEY type = gc_type_error.
IF sy–subrc <> 0.
CLEAR: mt_return.
es_return_message–type = gc_type_success.
es_return_message–id = gc_message_class.
es_return_message–number = ‘006’.
es_return_message–message_v1 = lv_obj_type.
es_return_message–message_v2 = lv_obj_key.
es_return_message–message_v3 = lv_obj_sys.
APPEND es_return_message TO mt_return.
ELSE.
****** Raise Fault Message
ls_bapiret = VALUE #( id = gc_message_class number = ‘015’ type = gc_type_error message_v1 = input–documentheader–obj_type
message_v2 = input–documentheader–obj_key message_v3 = input–documentheader–obj_sys
message_v4 = input–documentheader–ref_doc_no ).
MOVE-CORRESPONDING ls_bapiret TO es_return_message.
TRY.
* Error symptom transferred to the FEH Instance using the collect method
CALL METHOD i_ref_registration->collect
EXPORTING
i_single_bo = input
i_error_category = ‘DCE’
i_main_message = ls_bapiret
i_messages = mt_return
i_main_object = ls_object.
CATCH cx_ai_system_fault.
MESSAGE ID gc_message_class TYPE ‘S’ NUMBER ‘007’ INTO ls_bapiret–message.
CLEANUP.
ENDTRY.
* Populating the Fault Message Type
* set the fault data
ls_logdata–severity = ‘HIGH’.
ls_logdata–text = ls_bapiret–message.
ls_standarddata–fault_text = ls_bapiret–message.
APPEND ls_logdata TO ls_standarddata–fault_detail.
* Raising the Fault Message
RAISE EXCEPTION TYPE z***_cx_standard_message_fault
EXPORTING
standard = ls_standarddata.
ENDIF.
ENDMETHOD.The Collect method of the CL_FEH_REGISTRATION would create the PPO. Please note that the Importing table i_messages must be passed with the Error messages for the PPO to be created. If the Importing Parameter is not passed with error messages no PPO would be created. After calling the Collect method of CL_FEH_REGISTRATION propagate the Fault message back to the Inbound Service Interface.
STEP 4: Implement the remaining Interface methods as shown below.
Step 5: Post Implementing the FEH Class. We need to instantiate the same from the Inbound Service Call.
Step 6: Configuration for the ECH-PPO Process. Open Transaction SPRO and traverse to the Path below
Activate Error and Conflict Handler
Create Software Componenet
SPRO->Cross-Application Components ->General Application Functions – >Postprocessing Office ->Software Components->Define Software Components to define the SWC for your specific Process.
ECH – Business Process
SPRO->Cross-Application Components ->General Application Functions ->Error and Conflict Handler ->Define Business Processes
PPO Business Process
SPRO->Cross-Application Components ->General Application Functions ->Post processing Office ->Business Processes->Define Business Processes
Map ECH business process to PPO business process.
SPRO->Cross-Application Components ->General Application Functions ->Error and Conflict handler ->Define Business Processes for Postprocessing Office
Assign Caller to a Business Process.
SPRO->Cross-Application Components ->General Application Functions ->Error and Conflict handler ->Assign Caller to a Business Process.
Maintain the Interface created for the Proxy along with the Method of the Proxy which would be called by WS Runtime.
Object Type for Logging the Error.
This can be used as a Selection Criteria for Segregating the Post Processing Orders in the PPO Worklist
SPRO->Cross-Application Components ->General Application Functions ->Post processing Office ->Object Types->Define Object Types
Activation of Creation of Postprocessing Orders.
SPRO->Cross-Application Components ->General Application Functions ->Postprocessing Office ->Business Processes ->Activate Creation of Postprocessing Orders
Define Work Lists.
SPRO->Cross-Application Components ->General Application Functions ->Postprocessing Office ->WorkList->Define WorkLists.
Assign Work List to Business processes.
SPRO->Cross-Application Components ->General Application Functions ->Postprocessing Office ->WorkList->Assign Worklists to Business processes.
Edit Notifications for Orders in the WorkList.
SPRO->Cross-Application Components ->General Application Functions ->Postprocessing Office ->WorkList-> Process Notifications for Orders in the WorkList
Once the Setup is complete you can run the Inbound Service and process the PPO repeatedly in the Service Provider system by changing payload or Master Data as required to successfully process the PPO.
In case the Service is created in PI the log would be available in SXMB_MONI transaction but in case the Inbound service is consumed via WSDL runtime (as a Direct Web Service Call) the log would be available in SRT_MONI.
In our case we were consuming a Web Service directly.
We can traverse to the PPO directly through the SRT_MONI from the Actions button as shown above and Goto Ext Application, or you can directly open the /SAPPO/PPO2 transaction to search for the PPO. Use the selection criteria to shortlist the PPO you are searching
Initial screen shows the Error.
In the Detail Screen it provides you all the options to process the PPO.
Repeat / Confirm / Discard buttons on the top are the action Buttons for the Interface method
IF_ECH_ACTION~RETRY / IF_ECH_ACTION~FINISH / IF_ECH_ACTION~FAIL respectively.
Processing methods Display / Change can be used to check and change the Payload. This PPO can be used to fix the Payload and reprocess it. Once successfully processed or Discarded you would not be able to use the PPO again.
Double click on “Change” under Processing methods to edit the Payload in the Post Processing Order. After making changes you can save with comments for later reference.
The Post Processing Order can now be reprocessed after correcting the Payload. This would now pick the revised Payload and process the Inbound Service again. In case the Inbound Service again throws the error the Post Processing Order would still be available for making further changes and Reprocessing.
Once Successfully processed as shown in the below screenshot, the PPO would only be available in future for Display only.
This way the PPO can be reprocessed at the Service Provider side.
The FEH(Forward Error Handline) and the ECH (Error and Conflict Handler) provide us a framework to handle the failed Asynchronous Service Errors without intervention from the Consumer Side. This is really helpfull, as a lot of times we face Functional Errors(due to incorrect master data) which make have no relevance for the End User. The relevant Business Users / Functional consultants can check the PPO and reprocess the same.
