Skip to Content

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.

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

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.

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

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.

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

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.

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

Continue to Part 2: Development Objects

To report this post you need to login first.

7 Comments

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

  1. Suhas Saha

    Hello Eng,

    Nice approach to objectify the IDoc processing 😎 Really happy to see quality content in SCN. Maybe you should collaborate with Bruno Esperança and contribute to the Project Objectify.

    I’m pretty much sure most of the customers who use SAP would not agree to replace a stable/reliable solution with a completely custom one. How did you manage to convince the customer? Did your customer agree to this as part of an upgrade project or was it fresh SAP implementation?

    Cheers,

    Suhas

    (0) 
      1. Eng Swee Yeoh Post author

        Hi Bruno

        Nice one on the buffer – I will definitely consider using that the next time I need a buffer. I read through the whole post, including all the comments at the bottom… some pretty interesting conversation going on there!! πŸ˜‰

        I’ve just signed up for Github and followed you there. Let me know how I can upload this framework nugget into Objectify’s repository. Do let me know also if there are any rules, guidelines, naming convention, etc.

        Rgds

        Eng Swee

        (0) 
        1. Bruno Esperança

          Hi Eng!

          Great to see you’re interested in contributing πŸ™‚

          I will provide you with a proper reply to your request as soon as I have time πŸ™‚

          Thanks!!

          Best,

          Bruno

          (0) 
    1. Eng Swee Yeoh Post author

      Hi Suhas

      This custom framework is not a 1-to-1 replacement of the standard SAP IDoc framework. It should really be seen as an “enhancement” of the existing IDoc framework, accomplished by adding an extra “layer” to handle customization in a more streamlined manner. It still works very much the same way as standard IDocs processing, just that it is channeled through an OO encapsulated logic.

      I did a similar implementation of this few years back to resolve a number of development issues we faced – difficulty in finding the suitable exits/BADIs in the IDoc function modules to handle custom logic for pre/post-processing, developers working on different interfaces using the same IDoc type were locking one another’s objects, etc.

      There wasn’t much convincing required back then as it was a fresh ERP implementation.

      This time round, a little bit more convincing was required though πŸ˜‰ The customer already had some form of customized solution done in classical ABAP – a customized inbound function module that performs logging to customized tables, which calls the standard IDoc function module, which then calls user exits to manipulate/massage the IDoc data. This was already working in the production system on one IDoc type. However, with new requirements for interfaces using other IDoc types, that would have meant replicating that whole logic across few new customized function modules. It wasn’t ideal, so I managed to convince them by emphasising the reusability and extensibility of an OO-based solution πŸ™‚

      Thanks again for your feedback and pointing out Project Objectify – continued. I am definitely interested in working with Bruno on that. I do have codes that have been modelled into classes and I bring them onto any new projects I work on. I’ll check to see if any of those are suitable to add to Objectify’s repository πŸ˜‰

      Rgds

      Eng Swee

      (0) 
      1. Suhas Saha

        This custom framework is not a 1-to-1 replacement of the standard SAP IDoc framework

        I understand that, internally you are calling the standard inbound processing function πŸ™‚ I think this is a kind of custom implementation of the IDE framework used in ISU.

        It wasn’t ideal, so I managed to convince them by emphasising the reusability and extensibility of an OO-based solution

        I must say that either you’re very lucky to have a nice customer or you are good at convincing people πŸ˜›

        Cheers,

        Suhas

        (0) 

Leave a Reply