"To Err is Human" said Alexander Pope. Any business process that involves humans is prone to errors and hence are inevitable in any interface architecture. SAP PI/XI is a great tool to design a scalable and efficient interface architecture for an enterprise and it does come with many out-of-the box tools for error handling. However, these tools are very generic and hence may not meet specific customer requirements. This is especially true in case of inbound interfaces to ECC where business data is posted to the application. In almost all cases, there is a need to provide tools for the business user and end user community to react to errors when they happen and perform data level corrections before posting successfully.
The problem with out of the box tools is that it requires some understanding of how the tool works and is a challenge for the end user community to adopt the same. A good example is SXI_MONITOR which is a great tool for error handling and monitoring but its effectiveness stops with technical folks. Because of this, many times, the business user requires the technical folks to help in data manipulation which is an issue from auditing and controls perspective. So, there is a need for an interface architecture that is rugged enough to support complex interfaces but flexible enough to support error handling requirements.
In this blog series, I will share some of my experience in building custom tools for interfaces using ABAP proxies. These tools provide a easy to use interface for end-users to correct the errors and a generic framework for achieving the same. The generic framework uses dynamic programming (RTTS) supported by ABAP stack to provide a modularized, easy to use classes and modules that reduces development effort, maintenance and total cost of ownership.
Before we deep-dive in to the solution, here is a process flow of an interface that is built using an ABAP proxy.

One of the biggest advantage of ABAP proxy is that it can deal with huge volumes of data. Moreover, for performance reasons and controls reporting requirements, it is required to bundle many LUWs in one single message and proxies are an ideal choice.
However, as you can see, the main disadvantage of this design pattern is that there is no way to change the data in the payload. Now, I do understand that it is not the best business practice to alter the data in the target system. Data discipline, demands any corrections to be made in the source and then replicated to the target so that both source and target are in synch. But we know this not always practical, especially when you consider interfaces with external parties where correcting the data at source may take days if not weeks. Also, many times errors are transient in nature; like for e.g., material number is locked or wrong customizing. In such cases, we need a way to reprocess only specific LUWs that are in error instead of reprocessing the whole message.
On the other hand, IDOCs have been traditionally used for batch based interfaces and have proven to be a very stable architecture. It supports parallelization and has out of the box tools like BD87 for error handling. However, many standard IDOCs are not designed for multiple LUWs in a single message and hence don't support batch level control reporting.
So, we see both Proxies and IDOCs have their pros and cons but interestingly some of the cons of proxy framework are pros of the IDOC framework and vice-versa. So, it is logical to provide a way of coupling both technologies to leverage the best of both worlds.
Here is process flow for the combined framework :-

In this combined approach pattern, we can post as many LUWs as in parallel using aRFC and when and only when there are errors in a particular LUW, we create an IDOC. This way, all the errors are staged as IDOCs and gives the end user an opportunity to view and fix the errors at a later point. We also use alert framework to raise error alerts and spools to write control reports.
To achieve this solution of combined approach, we use out-of-the box BAPI-ALE interface to generate IDOC definitions for BAPIs (if one doesn't exist already) and then a custom utility class is used that leverages RTTS to dynamically create IDOC data based on the input signatures of the BAPI function module. By using these techniques, we greatly reduce the development effort where as provide a uniform approach for error handling and monitoring.
Here is the key components of the solution :-

As depicted above, not only we are able to dynamically create IDOCs for LUWs in error but we are also able to write a control report for the entire message that gives an overall picture of what happened in a particular interface run.
In the next parts of this blog series, I will cover the following topicsYou must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 3143 | |
| 1916 | |
| 1916 | |
| 1212 | |
| 1079 | |
| 757 | |
| 755 | |
| 742 |