Custom IDoc framework based on ABAP Objects (Part 1 – Intro)
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.
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.
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.
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.
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.
- Promotes Generalization
- Common logic and functionality pooled together to increase re-usability
- Allows Specialization
- Capability to handle specific requirements that deviate from common scenarios
- 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
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?
Indeed it does look like a suitable candidate 🙂
Also, Eng, please check this: http://scn.sap.com/community/abap/blog/2014/04/01/the-last-runtime-buffer-youll-ever-need
It might be an interesting alternative to the buffer you have. It's a dynamic buffer, so you wouldn't need to create a method for each kind of idoc data you are saving.
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.
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 🙂
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 😉
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.
I must say that either you're very lucky to have a nice customer or you are good at convincing people 😛
Maybe it's a little bit of both 😎