Skip to Content

Introduction

In this blog, I will introduce a custom proxy framework with FEH/ECH capability. FEH/ECH is an error handling framework for proxy-based interfaces and is widely used in SAP’s pre-delivered Enterprise Services. In my previous blog, FEH/ECH setup for custom asynchronous proxy, I have described the steps to complete the FEH/ECH configuration for custom processes/interfaces. The design and architecture of the framework is similar to the Custom IDoc framework that I have blogged about recently in the ABAP Connectivity space. In this section, the focus will be on the ABAP development objects for this framework.

The main purpose for this framework is to streamline the development of proxy interfaces with FEH/ECH capability, and also to simplify the development effort required. With this framework in place, new interfaces can be developed rapidly – the developer just have to implement interface-specific application logic and do not need to worry about adding the necessary logic in place to enable FEH/ECH.

Source code

The objects and code for this framework can be found in the following public repository on Github.

Github repository for Proxy_FEH_Framework

Framework object

Base input class – ZCL_PROXY_INPUT

This is the root superclass of the framework model. It provides the factory methods to dynamically determine the runtime class used for processing. This class implements interface IF_ECH_ACTION to enable processing from the Post Processing Office (PPO) – retry, confirm, fail.

/wp-content/uploads/2014/04/base1_433885.png

This class controls the sequence of logic executed during processing from either proxy execution or PPO.

Proxy execution flow

/wp-content/uploads/2014/04/proxy_433899.png

PPO retry flow

/wp-content/uploads/2014/04/retry_433900.png

It also contains the common methods for inbound processing (validation checks, custom logging.)  PROCESS_INPUT_DATA is empty at this level and has to be redefined in subclass for interface specific processing.

/wp-content/uploads/2014/04/method_433929.png

With all the common FEH registration/retry logic implemented at this super class level, there is no longer any need to recode this when creating a new interface.

Steps to implement a new interface

Below is a step-by-step guide to develop a new interface using this framework. The example shows a create purchase order interface.

1) Create service interface in ESR

/wp-content/uploads/2014/04/si_433938.png

2) Generate proxy in backend system (i.e. ECC)

/wp-content/uploads/2014/04/proxy_433899.png

3) Create subclass for processing this PO interface

Class ZCL_PROXY_INPUT_PO is created with superclass ZCL_PROXY_INPUT. All the methods are inherited.

/wp-content/uploads/2014/04/po_class_433970.png

PROCESS_INPUT_DATA method is redefined in this class to include the logic to create PO. At this subclass level, the input data from the message can be dynamically retrieve with method GET_INPUT_DATA. Also, if there are any processing error, exception ZCX_PROXY_PROCESS_ERROR is raised to pass the messages collected into the FEH/ECH.

/wp-content/uploads/2014/04/process_input_433972.png

4) FEH/ECH configuration

The setup for custom proxy interface needs to be completed following the steps in FEH/ECH setup for custom asynchronous proxy

In step 3 of the linked blog, the custom class created above is entered as the action class. The entries in these customizing tables are also used by the framework factory methods for dynamic determination of runtime processing class.

/wp-content/uploads/2014/04/setup_433988.png

5) Code proxy method

The method for the proxy created in step 2 above. Static factory method S_GET_INSTANCE is called to instantiate the dynamic runtime class. The values for the input parameter must match the entry in table ECHC_PROCESSES above. Subsequent, call the method EXECUTE_IN to start processing by the subclass.

/wp-content/uploads/2014/04/proxymeth_433951.png

6) Configure scenario in ID

Configure the scenario as per normal in integration directory and then the interface is ready to be tested.

Runtime and testing

When a message with error is processed by the proxy, the error will be transferred to PPO and the following will appear in SXI_MONITOR.

/wp-content/uploads/2014/04/moni_434005.png

The application error can be viewed from the message, and also is available in PPO as shown below.

/wp-content/uploads/2014/04/error_618028.png

The order in error can be viewed via transaction /SAPPO/PPO2

/wp-content/uploads/2014/04/ppo1_434011.png

/wp-content/uploads/2014/04/ppo2_434015.png

The contents of the message can be edited directly from PPO.

/wp-content/uploads/2014/04/change_434017.png

/wp-content/uploads/2014/04/change2_434021.png

After that, the order is submitted for reprocessing and completed successfully.

/wp-content/uploads/2014/04/reprocess_434022.png

/wp-content/uploads/2014/04/reprocess_ok_434023.png

Finally, the status of the order is updated in both PPO and SXI_MONITOR.

/wp-content/uploads/2014/04/status_ppo_434030.png

/wp-content/uploads/2014/04/status_moni_434889.png

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply