Forward Error Handling – Part 1: Outline

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:

• Lecture notes of CD267 in SAP TechEd 2010
• SOA Learning Map of SAP Business Suite 7 Innovations 2010 on SAP Service Marketplace: https://websmp206.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000717255&
• Help.sap.com: SAP Library -> SAP Business Suite -> Processes and Tools for Enterprise Applications -> Error and Conflict Handler (CA-FS-ECH)

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