Custom proxy framework with FEH/ECH

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.

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

Proxy execution flow

PPO retry flow

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.

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

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

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.

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.

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.

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.

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.

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

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

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

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

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