Skip to Content

Every time you create a custom IDoc receiver scenario, you have to take care of a few technical things related to IDoc communication. First of all, you have to create the IDoc structure manually, with all its segments. Then, you also have to implement a function module that processes the message, and assign it to an inbound process code. At a high level, each of such function modules has to handle the following processing steps:

20120723-01.PNG

This means you not only have to implement the  business logic, but also some technical processing steps related to IDoc handling. Before the business logic can be started, you have to read the IDoc contents into some more convenient internal structures and tables. Only then can you execute the logic itself. And finally, you have to write the results into IDoc statuses, to enable monitoring. As a result, you cannot really focus on the business part.

Fortunately, SAP gives you a standard functionality to automate this process and have whole the technical part generated automatically. This means that not only IDoc structure can be generated, based on your real business requirements, but also processing logic for steps 1 and 3 in the diagram above. It sounds like your manual work gets significantly reduced thanks to that, and you can focus on what is really important: the business logic.

The steps to follow are quite simple. First of all, you need to implement the business logic function module. It can contain any input parameters that you consider required for your business scenario, it should be RFC-enabled and should contain a return structure or table named RETURN and of type BAPIRET2, that will be converted to IDoc status later on. As an example, I have created a function module Z_BAPI_BOR_DEMO_CREATE that takes a table input parameter for messages to be written to the standard system log SLG1 (and of course returns a BAPIRET2-typed RETURN table for processing results). It is also important to know the outcome IDoc statuses, based on the messages returned.

Return parameter type

Message type

Result IDoc status

Structure

A

Status 51 (Application document not posted, with DB rollback)

Structure

E

Status 51 (Application document not posted, no DB rollback)

Structure

W, I or S

Status 53 (Application document posted)

Tables

A

Status 51 (Application document not posted, with DB rollback)

Tables

E

Status 51 (Application document not posted, no DB rollback)

Tables

No A or E messages

Status 53 (Application document posted)

As a second step, you have to create a custom Business Object in transaction SWO1, say we call it ZBORDEMO. You also have to specify a few attributes, including object name (in contrary to object type we specified before, which is purely technical) and main program for the object. Once you do this, here comes the important part. From the top menu, choose:

20120723-02.PNG

In the next popups:

  • specify the function module name you created earlier,
  • choose a method name,
  • mark importing and exporting (RETURN!) parameters,
  • choose that you do want to have a template automatically created.

Finally, you have to change the status to released (top menu -> Edit -> Change Release Status -> Object Type -> To implemented and then To released). Your BOR objects is ready now, and you can proceed to generating the IDoc (“ALE interface”), as normally, in transaction BDBG (more details here if required). Here are the parameters that I specified:

20120723-03.PNG

Remember:

  • if you are only interested in inbound processing, you can leave the “ALE Outbound Processing” part empty,
  • you have to release the IDoc type and all of its segments, before you can download this IDoc’s metadata to PI,
  • when creating partner profiles for this new IDoc type, choose the inbound process code BAPI, just like you would do with standard BAPI-generated IDocs.

So Experts, how do you feel about that feature? Have you been using it to cover your inbound IDoc scenarios? Do you find it useful?

P.S. There is some more to be explored with BOR objects. Have a look at my continuation on this topic, explaining how you can do same thing for outbound IDocs, and how this all can work with SMD (Shared Master Data) tool for automated processing based on change pointers:

Generating IDocs for BOR Objects – part 2: outbound IDoc and Shared Master Data (SMD) tool

To report this post you need to login first.

7 Comments

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

  1. Trevor Naidoo

    Hi Grzegorz,

    I’m no expert but I think it’s a pretty nifty feature!

    Have to ask though, wouldn’t this be more beneficial from an Abap perspective? I know cross-skilling is great and as a PI person you would need the Abap advantage (especially for Abap mappings) but I haven’t had this as a requirement from a PI / Integration deliverables perspective. Just asking, maybe others have and maybe it’s becoming a requirement from a PI person 😉

    (0) 
    1. Grzegorz Glowacki Post author

      Hi Trevor,

      Thanks for your opinion. In fact, I think what you’re asking about depends on the segregation of duties in particular companies, and on the developers themselves. Myself, I have created scenarios end-to-end most of the times, so not only PI development, but also ECC part was my deliverable. But I agree that ABAP developers might also be interested in the topic – maybe not instead of, but rather in addition to us, the PI guys?

      Regards,

      Greg

      (0) 
      1. Trevor Naidoo

        Yep, I’m in agreement, in addition to.

        For me personally, it’s very useful. I always like to know exactly what is going on all around me so I don’t get the wool pulled over my eyes 😛

        (0) 
  2. Michal Krawczyk
    (0) 
  3. Nageshwar Reddy

    Very informative. Using BDBG to generate idocs, message types and function modules will definitely save time. Specially when threre will be changes in interface. Four years back I had implemented a custom idocs solution along with object serialization that involved similar work with manual creation of involved elements.

    These days I have not seen requirements that involves this kind of work. Mainly because of the ore delivered content by sap. How many times have you used this solution? Did you face any issues at all? Thanks for sharing.

    (0) 
    1. Grzegorz Glowacki Post author

      Hi,

      Thanks for your comment. I have used this feature twice so far. One of the scenarios has passed really extensive testing and is already live, the other one is just about to go live. I did not experience any issues with the technical operation of the generated IDoc. And frankly speaking, I meet a requirement to develop custom IDoc type quite often, so I will probably be using it many times in the days to come.

      Regrads,

      Greg

      (0) 

Leave a Reply