FEH (Forward Error Handling) & ECH (Error Conflict Handler)

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

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.

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

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

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.

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.

Assigned tags

Related Blog Posts

Related Questions

nice work on the Blog. I’d set up our FEH some time ago and it is working. We now want to ONLY allow regional groups of employees to be able to process messages related to their region. We have dozens of regions.

Let me simplify the scenario. We have a Work Orders coming in from North and the South region. We only want employees responsible for the North to ONLY access their orders.

[I have set up North and South Worklist. Config for Assigning Worklist to Business Process will only 1 entry per business process. The /SAPPO/WL_CHANGE is only at the Component/Worklist level and does not allow restriction at business process. Even the ECH_MONI_SEL will not allow restriction on Worklist.]

as I noted the SAP standard does not allow a Process to have more than 1 work list, nor is it conditional. We need to determine the Work List based on the location of the work. The configuration is overridden by our own BAdI implementation of Work List determination via enhancement spot /SAPPO/CREATE_ORDER. This will get the Plant Section/Location and use that as the Work List.