Technical Articles
Custom IDoc framework based on ABAP Objects (Part 2 – Development Objects)
22 April 2019: Source code migrated to abapGit-based GitHub repository
8 April 2014: Updated section on ZCL_IDOC_INPUT and ZCL_IDOC_INPUT_SO, and added runtime flow diagram
In the first part of my article on custom IDoc framework, I have described the design and architectural aspects of the framework. In this part, I will elaborate more on the development objects involved.
The objects and source code described in this article are provided in the SAPLink nugget file attached at the end of this article. For more information on how to extract and install the objects, please refer to the SAPLink wiki. Please note that this article does not cover every aspect of the coding and design of objects and source code provided.
The source codes have now been migrated to abapGit and are hosted in the following GitHub repository:-
https://github.com/engswee/equalize-idoc-framework
Customizing tables
The following customizing tables are used during runtime processing by the framework.
ZBC_IDOC_CFG determines which IDoc processing class is used for a particular interface (unique combination of IDoc direction, Message Type, Message Variant and Message Function)
ZBC_IDOC_OPTIONS determines if there are any other additional custom logic to be used during processing. This allows for configurable customization of the behavior of runtime processing, i.e. which logic to use for material conversion, whether interface should execute duplicate check or not.
Inbound Process Code and Inbound Function Module
The inbound partner profiles are configured using a single process code, ZBC_IDOC_FW. This process code is configured to link to the framework function module (with BD51, WE57 and WE42).
In the framework function module, Z_IDOC_INPUT_FW represents the single point of entry for all IDoc inbound processing. The IDoc processing class is dynamically determined during runtime by the factory method GET_INSTANCE. Subsequently, all further IDoc processing is passed on to the processing class through method EXECUTE_INBOUND.
IDoc Processing Classes
1. Base class – ZCL_IDOC_BASE
This abstract base class is the root superclass of the framework model. It provides the static factory method GET_INSTANCE to dynamically determine the runtime class to be used for processing. It also provides general functionality that can be used by all subclasses.
2. Buffer class – ZCL_IDOC_DB_BUFFER
This class is not part of the inheritance model, however it is a helper class that provides buffered database accesses to improve IDoc processing times.
3. Inbound class – ZCL_IDOC_INPUT
This abstract class is a subclass of ZCL_IDOC_BASE. All the public/protected methods of the superclass are inherited here. Additionally, this class contains the methods that are common for all inbound processing, i.e. validation checks, customized logging.
The public method EXECUTE_INBOUND is called by the Process Code function module. This controls the sequence of logic executed during inbound processing.
This class also defines the following methods, which are abstract at this level. This enforces implementation at the subsequent subclasses level because different IDoc types require different IDoc processing function module, and/or preprocessing & postprocessing.
4. Sales Order processing class – ZCL_IDOC_INPUT_SO
This class is a subclass of ZCL_IDOC_INPUT. It implements all the logic required for sales order processing, in this case, for IDoc message type SALESORDER_CREATEFROMDAT2. The abstract methods from the above superclass are implemented here.
Shown below is the implementation of abstract method PROCESS_IDOC_FM, whereby the standard SAP function module related to this IDoc type is executed.
Additionally, any of the superclass methods it inherited can be redefined here for more specific processing. The following approaches are available when redefining superclass methods:
- Replace – Totally remove superclass logic and implement a new logic for this subclass
- Modify – Copy existing superclass logic, and only modify portions of the logic
- Extend – A mixture of both superclass logic and subclass logic. An example is shown below for method UPDATE_LOGS, where some additional subclass logic is added, and at the end, the superclass implementation is also executed (SUPER->UPDATE_LOGS)
Lastly, this class can be further inherited by a different subclass if required. This will enable implementation of very specific logic for certain specific interfaces.
Program Flow During Runtime Execution
The diagram below displays the flow of execution during runtime. This is based on an example where ZCL_IDOC_INPUT_SO is configured in table ZBC_IDOC_CFG as the processing class for that particular interface. The flow displays that the common methods are executed from the superclass version, while the abstract and redefined methods are executed from the subclass version.
Hello Eng,
If i understand correctly the standard IDoc processing function is called in the method PROCESS_IDOC_FM( ), isn't it?
How & where is it called?
BR,
Suhas
Hi Suhas
You are right. The code below shows the implementation of PROCESS_IDOC_FM at subclass ZCL_IDOC_INPUT_SO.
In the customizing table, subclass ZCL_IDOC_INPUT_SO is configured for this particular interface. So during runtime, an instance of this subclass is created at the inbound function module. The instance method EXECUTE_INBOUND is then called, which in turn calls PROCESS_IDOC_FM.
I will try to update my blog later so that this is clearer. 🙂
Thanks for the feedback!
Eng,
I know some time has passed since this blog was done but it is still relevant. You mentioned you had a nugget file in your post but I assume it was taken down??
Did you decide to not to put that out there?
I have a developer that started doing something similar to what you are doing but we just got started on it. Then I was searching and come across this blog. Very good idea and you hit the nail on the head with this. It is hard to get anyone to buy in to totally changing how things are being done.
I have, for a long time, wanted to change how we are doing our preprocessor activity because it is a pain. Can never make a change for more than one request at a time because of the object lock and cannot easily share common code across idocs while still allowing those little changes that are always requested.
Is the nugget still available anywhere? I do not see it on GITHUB.
Paul
Hi Paul
The migration from SCN to this new SAP Community platform removed all attachments from blog posts.
I have quickly added the nugget file to the my GitHub repository below.
https://github.com/engswee/SCN
Do try it out, since it's been a while I can't remember if the nugget file is synced with what was described in this post. There should be slight differences, but overall the concept should remain the same.
Good luck!
Regards
Eng Swee
Eng,
Great thx. Have it downloaded will try to get it uploaded and play around a little bit.
Hello Eng,
Thanks for sharing this fantastic idea! I surely will implement in my org. (if they allow me to do) ...
I have a question, the core methods are shared between inbound and outbound (init, validation, preprocessing, etc)... is there any specific reason why aren't they inherited from the super class zcl_idoc_base?.
Thanks again, this is a very much helpful post.
Hi Maricela
Inbound processing and outbound processing works a bit different, and it is not possible to define the same parameter that will work for both of them. Therefore it is not defined at super class ZCL_IDOC_BASE.
Regards
Eng Swee
Awesome! Thanks again.!