Spend Management Blogs by Members
Check out community member blog posts about spend management and SAP Ariba, SAP Fieldglass, and SAP Concur solutions. Post or comment about your experiences.
Showing results for 
Search instead for 
Did you mean: 
Former Member

SAP SRM system being envisioned as global procurement system is often linked to multiple SAP or non-SAP backend systems. Right from initial days of SRM, SAP provided SOA (Service Oriented Architecture) based interfaces to connect to multiple backend or partner systems. Over the years the list of interfaces were only increased thus adding the need for monitoring and Error handling of all these interfaces. To monitor the SOA based integration scenarios SAP provided basic tools like local integration engine and also advanced tools like Error Conflict Handler (ECH). Objective of this Blog is to focus on the ECH as a tool to monitor errors and post processing of those errors.

SRM SOA Coverage

To understand the SRM Context of the topic lets first look at:

  • What is SOA in SAP SRM context? and

  • What are the standard integration scenarios are available in SRM?

SOA (Service Oriented Architecture) in SRM context simply means that SAP has exposed certain SRM business functions, or parts of the business processes in the form of

web services for other applications to consume.

Following are the integration scenarios and interfaces between SAP SRM and ECC backend system.

If we look at the first integration scenario "Central Contract Management" then first interface "Request purchasing Contract Replication" is a service exposed by SRM Central Contract Management process so that backend ECC system can consume it to create operational contract.

In the ideal world everything would always work but in reality this interface may fail in consumer system due to a reason as simple as background user in consumer system does not have create authorization for operational contract creation transaction (ME31K).

The above interface is asynchronous hence cannot be restarted from consumer application because the consumer does not know the status (message in error). This provides the opportunity to implement a set of monitoring and error handling functions.

A few of the most commonly used application for monitoring SOA integration scenarios in SAP applications systems include:

  1. Local Integration Engine monitor (SXMB_MONI)-standard monitor enabled as standard in all SAP systems.

  2. Forward Error Handling /Error and Conflict Handler (FEH/ECH): additional monitor available in all SAP systems. but not enabled in standard.

  3. SAP Application Integration Framework (AIF): additional monitoring component which can be acquired in order to monitor SOA integration scenarios.

As a SRM consultants most of us already are aware of the first tool "SXMB_MONI" and are aware of the limitations the tool brings.

Understanding Forward Error Handling (FEH) / Error and Conflict Handler(ECH)

Let me start with a statement "Forward Error Handling is a concept/framework whereas Error and Conflict Handler (ECH) is toolset for handling errors".

FEH can be used to implement SOA integration scenarios for inbound messages (service providers). The idea behind the concept is for synchronous communication receiver system to be responsible to resolve the error instead of propagating it back to the sender system.

Most SAP standard enterprise services use the FEH concept and new, custom SOA services should also be developed a in a way in which they can work according to the FEH framework.

Following picture gives the scope of FEH framework which encompasses monitoring , automatic reprocessing, Error Correction and Notifications.

Thus when application issues an error message, the receiver will not reject the message but will try to solve the issue either by restarting the message for temporary errors or will notify business users to help solving it.

Error and Conflict Handler is a tool (transaction "ECH_MONI_SEL") with two internal components.

  1. Post Processing Office (PPO): Responsible for creating and processing orders (all messages processed with PPO are called orders).

  2. Hierarchical Derivation Service (HDS): Responsible for determining the correct resolution strategy.


Following software comes as standard in all SAP systems.

Error and Conflict Handler (ECH) is located in:

  • ABAP package FS_ECH in software component SAP_BS_FND with release >= 7.01

  • Software component SAP_ABA in SAP NetWeaver release 7.11 and 7.30.

It uses:

  • Local PI runtime in every AS ABAP.

  • Post processing office (PPO) software component in package /SAPPO/MAIN in software component SAP_ABA.

  • Hierarchical Derivation Service (HDS) framework in software component SAP_BS_FND

ECH process flow in context to SRM central Contract Management integration

Following image depicts the process for SAP SRM Central contract management integration with FEH enabled and if error occurs.

  1. The ECC server receives a service call through web service runtime.

  2. The relevant proxy forwards it to the implementation service (provider). The service implementation processes the query.

  3. If an error occurs during processing, the error symptom is transferred to ECH

  4. ECH uses the HDS to determine the resolution strategy for error symptom received

  5. A corresponding post processing order is then created in PPO

Global activation of FEH

Activate FEH Globally using following SPRO path in receiver system.

Cross Application Components -> Process and Tools for Enterprise Applications -> Enterprise Services -> Error and Conflict Handler -> Activate Error and Conflict Handler

Using Post Processing Office to monitor and resolve Error

Let's take an example of the central contract management integration scenario where error occurs as the receiving system side back ground user does not have authorization to create contract transaction (ME31K). In the Post Processing Office-over view screen error will be clearly displayed as highlighted below:

Once you click on this error you will be presented the Edit order screen to resolve\reprocess the error. In this case the missing authorization can be provided to the background user post which the order can be processed again.

Linking ECH to own business process

To connect your own business process to ECH, you need to make the Customizing settings in both ECH and PPO. The following settings are mandatory:

  1. In PPO, define a new component to which you want to assign your business process. In Customizing for Cross-Application Components , choose   Processes and Tools for Enterprise Applications   Enterprise Services   Error and Conflict Handler   Postprocessing Office   Software Components   Define Software Components  .

  2. Define a new business process in PPO. In Customizing for Cross-Application Components, choose  Processes and Tools for Enterprise Applications   Enterprise Services   Error and Conflict Handler   Postprocessing Office   Business Processes   Define Business Processes  .

  3. Define a new business process in ECH. In Customizing for Cross-Application Components, choose   Processes and Tools for Enterprise Applications   Enterprise Services   Error and Conflict Handler   Define Business Processes  . When doing so, specify your implementation of interface IF_ECH_ACTION as the action class. Enter class CL_FEH_MESSAGE_PERSISTENCY in the Persistence field and class CL_FEH_REGISTRATION in the Notification field.

  4. Assign the ECH business process you created in step 3 to the PPO business process you created in step 2. In Customizing for Cross-Application Components, choose   Processes and Tools for Enterprise Applications   Enterprise Services   Error and Conflict Handler   Assign Business Processes to Postprocessing Office  

  5. Assign your proxy implementation to the ECH business process you created in step 3. In Customizing for Cross-Application Components, choose   Processes and Tools for Enterprise Applications   Enterprise Services   Error and Conflict Handler   Assign Caller to a Business Process  . Enter the proxy interface in the API Name field and the method of your service operation in the API Component field.

NOTE: Above settings do not include the ABAP code changes and PI changes required for custom error handling to link to own business processes.

I sincerely hope that this blog will help SRM consultants\customers to effectively use FEH for improved error monitoring and effective resolution of most of the errors.