Skip to Content

Forward Error Handling means that the user of an Enterprise Service can “fire” a message and then go on. This concept is equivalent with the concept of “loose coupling” explained in the SAP Guidelines for Best-Built Applications:  “The receiving system must not send an error to the calling system if that error could be handled closer to the receiving system“.

Data Driven Enterprise Architecture

Asynchronous systems scale better than synchronous. Everyone who implemented either AJAX or high volume data replication scenarios in B2B or A2A context knows exactly what I mean. Especially in data driven architectures in banking and insurance area we have a bunch of messages floating through the systems. Most of them will be processed in background processes – in some cases the background process will create online processes like workflows because missing or incomplete information.

To run such an enterprise architecture we need two things: Web Services and a reliable Infrastructure. Why are Web Services important? In most cases we have a heterogeneous architecture consisting of on SAP and non-SAP systems: establishing communication with proprietary standards like RFC, COM, Corba and makes too much effort.

Some people seem to believe that they could always stay in an Enterprise Architecture consisting of SAP systems their whole business life. But what happens in a merging and acquisition scenario? If you are lucky you will have to deal with another SAP system landscape perhaps another FI system. Perhaps you will establish a kind of “federated” scenario with two FI systems one of them containing the general ledger and with an ALE scenario – but what happens if there is a non-SAP FI system? What happens if you have a whole bunch of highly specialized applications that have to be integrated in an enterprise architecture? In this you should consider using well established and non-proprietary standards for integration.

Asynchronous Communication

There are many reasons why synchronous communication has severe drawbacks: we depend on availability and response time of the backend system. But is has severe impact of the design of the calling application which is explained in above mentioned Guidelines for Best-Built-Apps:

So you shouldn’t be surprised that most write-services in SAP ERP are asynchronous.

In ABAP context asynchronous communication works as follows:

  • The signature of the Enterprise Service in ESR contains the information whether this is a synchronous or asynchronous call.
  • The Service doesn’t respond directly: the ABAP server proxy implementation creates an outbound proxy and gives the information back in the same LUW.

At the moment NetWeaver 7.01 there are some drawbacks because there is no “Service Group” concept we know from NetWeaver Composition Environment but this will change in 7.02 and we have better possibilities to maintain communication scenarios.

Reliable Infrastructure for Asynchronous Communication

Asynchronous communication needs a reliable infrastructure. We should use an Enterprise Service bus like SAP PI that guarantees reliable communication and abstraction of backend systems. But this is not enough because many things can happen in the backend system:

  • The business object (think of an sales order) you want to update is currently locked by another process.
  • There is missing or wrong customizing in the SAP backend system which needs to be changed.
  • The backend system call fails because of wrong input parameters – think of conditionally obligatory input parameters.

So we need a framework so that we can deal with those error conditions. Typical use cases for such an error handling framework are:

  • check of the error messages,
  • check of the input parameters,
  • check of the corresponding business objects,
  • restart operation,
  • perhaps manipulation of input parameters.

For good old ALE scenarios we have an infrastructure – think of tRFC queue or asynchronous BAPIs or IDocs – and we need the same for web services if we want to benefit from the advantages of asynchronous communication.

Outline of Error and Conflict Handler

SAP created exactly this and named it “Forward Error Handling”. FEH is a framework located in package FS_ECH which is part of any stack including SAP_BS_FND with release >= 7.01 and additionally in SAP NetWeaver release 7.11 and 730 (located in SAP_ABA). It uses parts of local PI runtime in every AS ABAP and another software component called post processing office (PPO) which is located in package /SAPPO/MAIN in software component SAP_ABA.

The post processing office is a typical application used to error management:

  • An error is represented as an entity that has associations with other entities (f.i. the business object that should be updated using a service).
  • There is a list of error messages.
  • There is a generic callback mechanism containing methods like Retry (restart), Edit and so on.
  • PPO allows assigning the error entity to a user and has interfaces to SAP Connect and Print Workbench to do alerting.

For ABAP architects some aspects are very interesting:

  • Many powerful frameworks from AS ABAP are being reused.
  • The concept of business objects (even good old BOR objects) is still crucial in times of SOA. In fact my collegue Thorsten Franz is writing a blog series about this topic:  Will Business Object Layers Inherit the Earth? Part 1: What is a Business Object?
  • The old BAPIRET2_T containers for messages we know from BAPIs and ABAP-OO exceptions are still being used.

At the moment there is not much information available but this will change. At the moment I recommend:

Summary and Outline

FEH is an example of successful reuse of existing frameworks for business applications. In this weblog series I will cover the following:

  • How can we set up FEH?
  • How can we use FEH for SAP standard Enterprise Services?
  • How can we enhance custom Enterprise Services using FEH?
  • Advanced features
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Tammy Powlas
    I don’t use composite apps, but was struggling with which type of update to use earlier this week – synchronous versus asynchronous and your blog (plus BBA) indicated I made the right choice.

    Thanks Tobias.

  2. Former Member
    This is what I recently implemented in my SAP project, which gets data from DB and create/update tables in IS-U. But I am thinking of general framework that can be use in non-sap systems also. For example, if I’m writing ( create operation) in DB than I assume connected system (DB) should full FEH same as SAP’s FEH. 
    1. Tobias Trapp Post author
      SAP’s approach is aaplication layer centristic and works because because we have generic business object layers and frameworks. I would be very interested in your thoughts in a non-SAP environment we have a web service. Do you mean database web services that insert data directly into rdbms tables? One could persist the payload if the integrity constraints of the db are violated. But this would lead to an approach that are not usable in an AS ABAP. Or do you mean something else?

      Best Regards,

      1. Former Member
        this is specific for abap….but same thing can be added in java proxies. when we implement proxy using java in nwds. a kind of general framework so every provider should system ( in landscape should do it). i will explore it more. just read michal’s blog. sounds intresting from abap side.
  3. Former Member

    Hi Tobias ,

    Really nice blog , just one information here … Is this applicable  only for  Inbound proxy ?

    Or this can be implemented for outbound proxy too ?? Please confirm .



    1. Tobias Trapp Post author

      What a concidence! Some times ago I looked at F1 documentation of transaction SPROXY and found out that this client proxy calls should only called as updated module. If you are thinking about it this makes only sense for response messages of asynchronous web services. Nevertheless, the error behaviour is an interesting topic. In my current project I’m implemententing Web Services scenarios with communication in both directions and at the moment I’m struggling to find out a best practice.

      Nevertheless, the topic is quite complicated and I think it deserves an own blog. I hope you can wait for a response. Nevertheless, as far as I can see ECH is not positioned for this kind of action.

      Best Regards,


        1. Tobias Trapp Post author

          Wow, this is really interesting. I’ll find out how ECH is positioned here. Can yoou sketch how AIF solves this – exspecially if proxy calls are done in update modules like it is recommended by SAP:

          Important Note: Consumer Proxy in Update Task

          If the application data is persisted in an update task, then the XI outbound call also needs to be made in the update. Otherwise, if the update is canceled, the qRFC queue may become blocked due to the unscheduled update task. Since the queues are interlinked, this can have a significant effect on the whole of outbound processing.

          Best Regards,


          1. Michal Krawczyk


            >>>Can yoou sketch how AIF solves this – exspecially if proxy calls are done in update modules like it is recommended by SAP:

            never done that yet – I just know that AIF guides mention the possibility – sorry 🙂


            Michal Krawczyk


Leave a Reply