In the Forward Error Handling – Part 1: Outline of this weblog series I explained the concepts behind forward error handling. Now I will discuss how to set up Error and Conflict Handler Framework and look how the framework is used with SAP Business Suite. The reason is very simple: if you want to understand a framework in detail you should analyze how it is implemented within SAP standard.
Then we need some to insert some code snippets into the proxy implementation.
And this is how it goes. Let’s have a look at Service Interface CreditLimitChangeRequestERPChangeRequest_In:
You can see that there is only one operation and exception. When the service is called it delegates to a method EXECUTE_ASYNCHRONOUS of a generated proxy class. So let’s have a look at the generated server proxy especially at the method EXECUTE_ASYNCHRONOUS:
The implementation is very small: SET UPDATE TASK LOCAL is common for Enterprise Services that change data. Then the call is delegated to an implementation class:
DATA lo_serv_impl TYPE REF TO cl_ukm_clcr_impl_chgrq.
The input parameters from the web service payload are mapped into an internal format.
Then with the business logic with those input parameters is called.
In both cases errors can occur and given to method lo_feh_registration->collect. Then an exception is raised.
Within ECH framework the error will be persisted as orders within PPO framework. There some action like discard, finish, retry and so on can be executed manually or automatically. These actions will be delegated to those actions defined in interface IF_ECH_ACTION of the action class CL_UKM_CLCR_IMPL_CHGRQ which is shown above.
We can customize this behavior in many ways which I describe now. An error of a specific Enterprise Service will be assigned to a component (often corresponding to an application) and a process within in that application. We can define how to persist the error situation and the action class. The latter is important because its methods will be called by PPO. And this information will be stored in table ECHS_PROCESSES:
So the implementation class of a web service has two purposes: it implements the service logic which contains passing the error data to ECH framework. ECH can perform error processes because the implementation class is from the point of view of ECH an actions class containing a special interface whose methods will be called for retry, discard and so on… And this logic is stored in table ECHS_DEFLTRESOL. For each error scenario we can define error categories (format error, processing error, authorization error, lock request and many more) and for each combination further parameter:
In our case the error is persistent and so submitted to PPO. Retry Group S40 means that is rescheduled every 40 minutes automatically but can retried manually (retry mode 3). Finish resp. fail mode 2 mean that those actions only can performed manually.
In Ehp 4 those tables are system tables but in later releases they will have proper category “E” as well as customer namespaces which is necessary when you want to define own error processes for custom developed enterprise services.
This is customer customizing that can be defined in SPRO above using “Define Resolution Strategy” by creating a condition by creating condition and target:
Now you can define possible values:
Summary & Outline
So far we looked into SAP Business Suite. If you want to use this framework in custom used error processes you should
analyze classes that implement interface IF_ECH_ACTION,
the customizing tables in ABAP package FS_ECH_BASIS and