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.

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.