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.
If you want to know the end user uses the PPO tool you should have a look how it a video you’ll find here: https://websmp206.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000717255& for Ehp 5 or in PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict ... for Ehp 4.
Prerequisites
Asynchronous Communication uses an XI infrastructure within AS ABAP which has to be set up first which is described in SAP Library: http://help.sap.com/saphelp_nw70ehp1/helpdata/de/14/80243b4a66ae0ce10000000a11402f/frameset.htm . After setting up the local integration engine you have go to transaction SPRO and activate the error and conflict handler:
Then run report SXMS_FEH_TEST to test whether FEH runs correctly. If everything is OK one message is displayed like in message monitor in transaction SXMB_MONI:
To use this Forward Error Handling you need authorizations for transactions like SXMB_MONI_SEL and for other components like Post Processing Office (transactions /SAPPO/PPO2 and /SAPPO/PPO3).
A look at Enterprise Services of SAP Business Suite
Asynchronous Enterprise Services of SAP Business Suite are using the Forward Error Handling Framework. This works as follows:
- The error process can be set up & customized. SAP Mentor Michael Krawczyk wrote a great blog about Forward Error Handling and showed how to link it to the post processing office: PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict ... .
- 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:
METHOD ii_ukm_clcr_chgrq~execute_asynchronous.
DATA lo_serv_impl TYPE REF TO cl_ukm_clcr_impl_chgrq.
SET UPDATE TASK LOCAL.
TRY.
CALL METHOD cl_fscm_extended_xml_handling=>deactivate_exml_handling.
CATCH cx_ai_system_fault .
ENDTRY.
* get proxy implementation object reference
lo_serv_impl ?= cl_ukm_clcr_impl_chgrq=>get_instance( ).
* execute service processing
CALL METHOD lo_serv_impl->execute
EXPORTING
input = input.
ENDMETHOD.Now let’s look at the implementation-class that is called from the generated service class:
The main method is EXECUTE. Within that method at first the Forward Error Handling Framework is initialized:
DATA:
lo_feh_registration TYPE REF TO cl_feh_registration lo_feh_registration = cl_feh_registration=>s_initialize( ).Then the following steps are performed:
- 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
- the weblog of SAP Mentor Michal Krawczyk who explains PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict ... and explains these details PI/XI: Forward Error Handling (FEH) for asynchronous proxy calls with the use of Error and Conflict ....
ECH framework has been improved in Ehp 5 and there will be even more improvements in Ehp 6. In the next installments of this weblog series I will cover following topics:
- Post Processing Office as generic error handling framework. Therefore we need some additional customizing.
- HDS frameworks for error classification which was shipped in software component SAP_BS_FND in NW 7.01.
- Further development of ECH in Ehp 5 and 6 (as soon as the latter is general available).
1 Comment
