Skip to Content

Four things you might have not known about IDocs

Most IDoc scenarios using SAP systems are similar: create an IDoc message in your ERP system and deliver it to any other system, sometimes with some custom code (like user exits) included. But it is worth knowing that you can achieve much more with IDocs. Read the examples below for just a few capabilities connected with IDoc processing that you might have been dreaming of and now you have them at your fingertips. I hope you will find them useful and they will help you develop your integration scenarios better than ever before.

1. Updating IDoc status based on the success or failure of RFC connection

It happens many times that although your IDoc monitoring tools say “IDoc sent to SAP system or external program” and the IDoc message has a green traffic light, you cannot see it in receiver system. If you take a closer look at it, you will find that IDoc status says precisely: “Data passed to port OK”, which only means that IDoc has been set to be despatched, but not necessarily reached the receiver system. You have to check transaction sm58 (Transactional RFC log) to make sure your message was delivered successfully. Unfortunately, even if you locate an error in sm58, you will not find IDoc number there. Of course you can always copy the “Transaction ID” from sm58, go to General Table Display (se16n), and search entries in EDIDS database table based on the field TID equal to your Transaction ID. You will find the IDoc number there. But haven’t you ever been wondering if there is no nicer way to do it?

Of course there is. You can schedule the ABAP Report RBDMOIND (Status Conversion with Successful tRFC Execution) to have your IDoc statuses changed from 03 “Data passed to port OK” to 12 “Dispatch OK”. Now you can finally be sure your IDoc message reached the receiver system even while looking at it in IDoc monitoring transactions. For example, before executing the RBDMOIND report, the IDoc monitor in my system has shown:

While after I executed it, it has been confirmed that one of my IDocs for sure has already reached receiver system:

2. Delivering IDocs to HTTP receiver

In one of my previous blogs you might have read that it is possible to send IDocs from any application to your SAP system over HTTP. For further details, see here: Post IDoc to SAP ERP over HTTP from any application

You might now be thinking: for sure this has to be possible also the opposite way. It has to be possible to send IDocs out from SAP to HTTP receiver. And you are right. Moreover, this is equally simple as standard IDoc scenarios over RFC or flat files, and does not go beyond standard system configuration.

So, the trick here is to create an RFC Destination of type “HTTP Connection to External Server” (G) in sm59. For instance, it might look like that:

Remember to provide logon credentials on the “Logon & Security” tab page if required. The next steps are similar to ordinary RFC processing: create a Port in IDoc processing (we21) of type “XML HTTP” and a partner profile entry, using your IDoc port created earlier. And this is it, you are ready to test your scenario!

You will also be glad to notice that IDoc status is set properly, according to the status of HTTP call (automatically, with no further configuration). Here is an example of an IDoc that was passed successfully:

And an erroneous one:

3. Delivering IDocs to a function module (IDoc port of type ABAP-Programming Interface)

For sure you already know that you can send IDoc to an RFC Destination or create an IDoc flat file out of it. After reading the previous hint you also know that you can pass an IDoc to a HTTP server that will process it further. But in some cases, you might require some additional processing inside your SAP system after an IDoc has been created, even instead of sending the IDoc out from your system. In my case, I wanted to pass some data to an ABAP Proxy based on IDoc creation (as a data replication trigger) for some reason, but you may find hundred more applications for this capability.

The steps to follow are again really simple here. First of all, go to transaction we21 (Ports in IDoc processing) and have a closer look at ABAP-PI type. The “PI” there stands for Programming Interface, which is just what we want to do. Now simply create a new IDoc port of this type, giving it a name, description and the function module that you will use for processing the message, for instance:

Now use your port in the partner profile configuration of any outbound message and you’re done. And what is really important, you have a total control over what is happening: you can set any IDoc status after your processing, or do whatever else you need. The important thing here is that your function module can use an input (TABLES) parameter I_EDIDC to get the control record of the IDoc that was passed to it. Based on it, you can use EDI_SEGMENTS_GET_ALL standard FM to get you message contents (remember to precede it with EDI_DOCUMENT_OPEN_FOR_PROCESS and conclude with EDI_DOCUMENT_CLOSE_PROCESS).

4. Unknown capabilities of IDoc status segments

Whenever developing a custom IDoc scenario or enhancing a standard one, for sure you have been thinking about error handling procedures. And now you can help your users and administrators more than ever before, using two additional features of IDoc status segments.

The first option is marking a particular segment or even a particular field as erroneous. As a result, you will see the IDoc as follows:

Thanks to this, even in bigger IDocs you can easily locate the segments that caused an error, becaused they are using a red font. You can even hide all correct segments and only display those that were marked as incorrect (in an IDoc monitor like we02, when displaying a single IDoc message):

You might be surprised that this is extremaly simple to achieve. All you need to do is to put the IDoc segment (sequential) number in the SEGNUM field of your IDoc status to mark a segment, or put field name in the given segment to SEGFLD field to mark a particular field. Really helpful, isn’t it?

The second capability to put IDoc monitoring into a higher level is writing IDoc processing details to standard Application Log (transaction slg1) and then inserting the log object number in the APPL_LOG field IDoc status. For instance your IDoc status could look like that:

Now, when you double click the status record, you will find an additional button that is not visible normally:

This button navigates you to processing details in Application Log, directly from IDoc monitors. And of course, some processing details should have been written there already by your IDoc processing routine.

You must be Logged on to comment or reply to a post.
  • Good Blog! Like the Portion on RBDMOIND, something that I was not aware of.
    I am also surprised by how the HTTP XML Port option is not used that often. Ever tried HTTP XML Port + Collect IDocs option in the partner profile? Always recommend using this option to avoid Collect Pattern BPM in XI!


    • Hi Bhavesh,

      Thanks for that. To be honest, I’ve never used HTTP XML Port with Collect IDocs functionality, but I can see no reason why this would not work identically to RFC, like it all does. Give it a try, I think you will succeed 🙂


      • Hi Greg,
        I did it, and one thing is: with RFC you can easily manage Acknowledgment (ALEAUD), and so idoc status is changed in WE02, but with XML-HTTP port, if I remind me we cannot have it, status still equals to 03.
      • hi,

        >>>but I can see no reason why this would not work identically to RFC, like it all does.

        in terms of config this is not an issue
        but in terms of HTTP broken connections and restarting in most cases you cannot use it as per doc from SAP which describes this config


  • Hi Grzegorz- Thanks for the nice information and have below query

    If i create a port of type ABAP-PI and this means after creation of idoc, i can do further processing inside the FM (mentioned in port) but we cant send this idoc to external system, as no RFC destination has been mentioned in port (of type ABAP-PI)
    Is this correct?


    • Hi Vinoth,

      Thanks for the comment. Yes, you are correct, passing an IDoc to ABAP-PI port means that it will not be sent via RFC to any receiver system. You can use some workarounds like calling IDOC_INBOUND_ASYNCHRONOUS to the receiver system, if this is really necessary, but I think this should not be used as a rule. In other words: don’t think of ABAP-PI port as a substitute for user exits in outbound IDoc processing 🙂


  • Hi ,

    I had a question for  “IDoc sent to SAP system or external program”.

    We have written a Java Code which will receive the changes as we have registered the java program  using


    We intercept the HR changes happening on the SAP system.

    We use the RBDMIDOC and select message type HRMD_A to receive the changes .All work perfectly fine.

    My question is  if i stop the java program  .I do some changes in HR data  and run the RBDMIDOC program is gives error that the program “INTERCEPT” is not listening.

    What will happen to such IDoc changes .Will it be lost when the service is stopped.

    Or when the service starts again will this IDoc be transferred again.

    IF it is transferred again ,how much time is the IDoc valid in SAP system so that we o not loose them.