Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
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.
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
DATAlo_exception TYPE REF TO z***_cx_standard_message_fault,
lo_fehreg    TYPE REF TO cl_feh_registration.
DATAls_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.
CLEARls_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.
CLEARls_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.
DATAls_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.
CLEARes_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.
CLEARmt_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.

For further details you may refer to the Standard Documentation at the below links.

Error and Conflict Handler

The HDS (Hierarchical Derivation Service): This is a Rule Engine where we can configure pre-defined rules to handle the Post Processing Order based on the Error categorizations. It is beyond the scope of this Document. You may visit the below link for complete Details.

HDS (Hierarchical Derivation Service)

 

 

 

 
8 Comments