Four things you might have not known about IDocs

[former_member184681]

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.