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:
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:
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:
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
- SAP Managed Tags:
7 Comments
