IDoc Has Left The Building

SAP IDocs are a tried and true interface methodology. But as with any interfacing technology the most brittle component is the connection between the two systems (in the case, SAP and the subsystem). In scenarios where SAP is sending IDocs to a subsystem via the transactional RFC, one question is paramount:

How do you know when an Outbound IDoc has physically left SAP?

It’s a simple fact that if your subsystem never receives an IDoc from SAP, the subsystem will not be able to route or process the IDoc. I have always gone by the notion that once the subsystem has successfully received the IDoc, the subsystem now has all the responsibility to process and route the IDoc, but before that time, SAP has the responsibility to ensure that the IDoc is fully dispatched. The subsystem should have processes in place to determine if the IDoc has been received at the target system successfully or not. In this blog I will focus on the handshake between SAP and the subsystem. This will entail Outbound IDoc status and a couple of batch jobs that should be setup to ensure a better chance of a successful handoff between SAP and the subsystem.

First, let’s cover the normal, expected progression of statuses for outbound IDocs. The following graphic shows the collection of status records for a random outbound IDoc.

The status records at the bottom of the list depict the IDoc status before the status records at the top of the list. So, in this example, the IDoc started in status “01 – IDoc generated”, then progressed to status “30 – IDoc ready for dispatch (ALE service).” These two statuses usually are created in rapid succession for outbound IDocs and mean that the IDoc has been created in the SAP system and is ready to be sent via tRFC to the subsystem. The next two IDoc status, 03 and 12, can be a little confusing. They both seem to mean that the IDoc has been dispatched from SAP. What is the difference? I have found that sometimes there is some confusion on weather the IDoc has left SAP or not. After I explain the difference, I will show 2 batch jobs that should be setup in order to update the status if the Outbound IDoc has physically left SAP.

So what do statuses ‘03’ and ‘12’ really mean?

The status ‘03’ actually means “Data passed to port OK” which basically means that the IDoc has been dispatched to the tRFC queue and an attempt was made to send the IDoc to the subsystem. However, that does not necessarily mean that the IDoc has left SAP. There could be many reasons why SAP would fail to send the IDoc. One example could be that the subsystem was down during the transmission of the IDoc. Errors during data transmission would cause the IDoc to remain in the tRFC queue. Thus, the IDoc would still remain in SAP and remain with a status of ‘03’.

When the Status changes to ‘12’; a successful connection was made to the subsystem and the IDoc was sent. This status represents that the Outbound IDoc is no longer in the tRFC queue and, therefore, has physically left SAP. The IDoc is in the hands of the subsystem which is now responsible for processing or routing the IDoc.

But what if I never see a status of ‘12’ on IDocs that were successfully sent?

For one reason or another, sometimes the batch job to update the status to ‘12’ is not scheduled. In Production this batch job is usually set up, however in the QA or Dev environment this may or may not be setup depending on the client.

1) The following job should be setup in order to process a status ‘12’. I typically set this to every 10 minutes depending on the client.

Program: RBDMOIND – Schedule this program in order to check whether the IDoc have been successfully sent out of the tRFC queue. If the IDoc has been sent successfully to the subsystem, the program RBDMOIND will change the status of the IDoc from status ‘03’ to status ‘12’. This means that the handshake with subsystem was successfully and the IDoc has physically left SAP.

2) There may be times when the subsystem is unavailable at the time the SAP is trying to send the Outbound IDoc. By default, SAP will only make one attempt to transmit the IDoc. By scheduling the following program in a batch job, SAP will try to resend the Outbound IDoc again at a specified time interval. I also usually set this at job every 10 min, depending on the client.

Program: RSARFCEX – Schedule this program in a batch job in order to resend any IDocs that have are stuck on the tRFC queue.

Ok I have set up these jobs, but the status does not change. Now what?

Sometimes an Outbound IDoc could remain stuck on the tRFC queue and never get sent out successfully. Some issues could be that the RFC Destination for the subsystem is configured incorrectly or there could be an authorization issue. These types of errors need to be fixed before the batch job for RSARFCEX will send the IDoc out successfully. You may need to get some additional detail of the problem. Execute the following transaction below.

Transaction SM58 – This will check what is currently on the tRFC queue. Once you display the list, you also have the ability to drill down and get some additional detail of what has caused the failed transmission.

Conclusion

Typically you won’t see many issues with Outbound IDocs. From time to time, IDocs will get stuck on the tRFC queue and if not managed properly, could be stuck there a long time. This blog should give you more visibility in respect to IDoc status to ensure that the Outbound IDoc has successfully left SAP for processing.

Steve Park is a senior SAP Interface Consultant of DataXstream, an SAP-focused consulting firm. He has a Bachelors of Science Degree from Indiana University (1999) and majored in Business Process Management, Operations Management, and Finance. Steve has been with DataXstream for 5 years and previously worked with clients such as Northrop Grumman, Lumber Liquidators, and Fererro.

Great Post…Thanks for the info. But we have 41 status to confirm that idocs have been sent successfully to the sub system. Can you please let me know what is the difference between status 41 and status 12.

You are receiving a status ’41′ because this particular subsystem that received the IDoc is actually sending back an IDoc for message type ALEAUD. This ALEAUD IDoc will update the status of the Outbound IDoc that was sent initally out of SAP.

The Status update that you will see on the Outbound IDoc is either:
Status ’40′ Application document not created in target system or
Status ’41′Application document created in target system

You may realize now that status ’12′ tells you it left SAP, and ’41′ tells you its been received at the subsystem.
So among the three main status ’03′, ’12′, ’41′ you have derive a pretty good idea where your IDoc stands.

This is excellent Post…Thanks for the info,I am facing below issue ,
We have scenario From ONE SAP system ( HRMS) sends the HRMD_A message type IDocs to another SAP system nad normally we can see the Target SAP system Inbound Idoc in HRMS system in BD87.

But some cases,we are not able to see the Inbound Idoc numbers in HRMS system, we are getting the ZEROs instead of Idoc number in BD87

I will appriciate for your urgent help, currrently in production we have ran a program to archive customer, which has created more than 100000 IDOCs, now – this all idocs are stuck with status 03 and are converted to status 41 very slowly ( @ 400 IDOCs per Hour) via tRFC to legacy system. whereas, our the weekend, spped was 4000IDOCS per hour converted to status 41.

Now, during working days – having big iisue in production, because user createds details are not yet passed to legacy system, as the big queue is pending.