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.