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“.
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.
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:
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.
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:
So we need a framework so that we can deal with those error conditions. Typical use cases for such an error handling framework are:
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.
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:
For ABAP architects some aspects are very interesting:
At the moment there is not much information available but this will change. At the moment I recommend:
FEH is an example of successful reuse of existing frameworks for business applications. In this weblog series I will cover the following: