Skip to Content

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_CFG.png

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.

ZBC_V_IDOC_CFG.png

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).

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

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.

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

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.

ZCL_IDOC_BASE.png

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.

ZCL_IDOC_DB_BUFFER.png

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.

ZCL_IDOC_INPUT.png

The public method EXECUTE_INBOUND is called by the Process Code function module. This controls the sequence of logic executed during inbound processing.

EXECUTE_INBOUND.png

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.

ZCL_IDOC_INPUT 2.png

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.

ZCL_IDOC_INPUT_SO.png

Shown below is the implementation of abstract method PROCESS_IDOC_FM, whereby the standard SAP function module related to this IDoc type is executed.

PROCESS_IDOC_FM.png

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)

UPDATE_LOGS.png

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.

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

To report this post you need to login first.

8 Comments

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

  1. Suhas Saha

    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

    (0) 
    1. Eng Swee Yeoh Post author

      Hi Suhas

      You are right. The code below shows the implementation of PROCESS_IDOC_FM at subclass ZCL_IDOC_INPUT_SO.

      PROCESS_IDOC_FM.png

      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.

      EXECUTE_INBOUND.png

      I will try to update my blog later so that this is clearer. ūüôā

      Thanks for the feedback!

      (0) 
      1. Paul Pendleton

        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

        (0) 
        1. Eng Swee Yeoh Post author

          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

          (0) 
  2. Maricela Valenzuela

    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.

    (0) 
    1. Eng Swee Yeoh Post author

      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

      (0) 

Leave a Reply