Custom IDoc framework based on ABAP Objects (Part 1 – Intro)

Introduction

In this blog, I will introduce a custom IDoc framework that is based on Object Oriented Programming, implemented through ABAP Objects. The objective of this framework is to establish and enforce a consistent development approach for all IDoc based interfaces in a particular organization. In this first part of a two-part series blog, I will cover the design and architectural aspects of the framework. In part 2, I will cover the the development objects involved.

Background

Since Web AS 620, proxy has been available as an integration technology for SAP systems. In-line with SAP’s SOA strategy, proxy enables development of interfaces with the outside-in approach. Introduction to Service Development details some differences between outside-in approach and inside-out approach. Many of SAP’s newer “standard” interfaces (especially in newer products like SRM, IS-U, etc) are developed using the outside-in approach, and are delivered as Enterprise Services.

In recent years, SAP has introduced technologies like FEH/ECH and AIF to enhance the capabilities of proxy based interfaces. The following blog SXMB_MONI vs FEH/ECH vs AIF provides a comparison of the error-handling capability between these technologies.

Using IDocs

However, in spite of all the advancements in these newer technologies, IDoc remains a preferred and/or popular choice in many organizations for their integration development. This is especially true in the ERP system, where there is a wealth of standard IDocs available for integrating most of the common business documents like sales order, accounting document, customer master, etc. It is a mature and stable technology that has been around for decades, with an extensive coverage of tools in the various areas – development (WE30/31, WE80/81), configuration (WE20, WE21), documentation (WE60, WE64), testing (WE19), monitoring and error handling (WE02, BD87), content search (WE09). It is also a technology that the SAP business user community has become widely familiar with.

Customizing IDoc Interfaces

While it is ideal to be able to use the standard IDocs provided by SAP “as-is”, we all know that more often that not, some level of customization is required to meet the specific needs of an organization. While it is fairly easy to achieve customization for a single IDoc interface, there are challenges to achieve a consistent customization approach when there are a multitude of IDoc interfaces to be developed. Below are some of the common challenges.

Not all IDocs are created the same

Some have extension segments, others do not. Some use call transaction, while others have BAPI-based processing.

Different code enhancement options

Different IDoc processing function modules are developed differently. Some can be enhanced by customer exits, some have BADIs, some do not have either.

Customized logging/validation

If a standard customized logging/validation is required, this logic has to be replicated across the various IDoc function module involved. This leads to a lot of reinventing the wheel every time a new interface is developed.

Overview of IDoc customization

There is no single place where we can get a high level overview of customizations for all the different IDoc interfaces developed.

Extensibility

Customizations are often done per a specific requirement for a specific interface, leaving little room for extension.

Locking of shared objects during development

If more than one interface is being developed that requires customization of the same IDoc, the developers might need to edit the same user exit/BADI, which leads to locking/contention issues.

Object Oriented Solution

The customized framework is designed with the following guiding principles, which is achieved by an object oriented approach using ABAP Objects.

1. Promotes Generalization
   • Common logic and functionality pooled together to increase re-usability
2. Allows Specialization
   • Capability to handle specific requirements that deviate from common scenarios
3. Easily Extensible
   • Capability to extend to new business cases/scenarios

This approach also allows for a distinct separation of development objects, thereby preventing any locking/sharing/contention issues.

Class Inheritance Model

The following diagram displays the inheritance model of the classes in this custom framework. The customized logic that are common to all IDoc interfaces are implemented in the super classes. For each new type of IDoc, a new subclass is created inheriting from the super class. With this approach, the common framework logic (like validation, customized logging) need not be repeated again – only the type specific logic needs to be implemented at this level. Further down, there might be specific interfaces that require even further customization. This can be achieved again by inheriting from the appropriate IDoc type class.

Framework Processing Flow

With this framework, all inbound IDocs are processed by the same custom process code. This executes a custom Function Module, and it is a single point of entry into the framework processing.

During processing by the framework, the class responsible for processing the IDoc will be dynamically determined during runtime. Common logic like validation, customized logging, notification are implemented in super class which are always the same for all IDoc objects processed.

Meanwhile, each interface will implement it’s own logic specific to the interface requirement. These specific logic are implemented in sub classes. These logic can be implemented in the preprocessing/postprocessing methods and establishes a consistent way of adding custom logic – reducing the need to find a suitable exit/BADI.

Continue to Part 2: Development Objects