Idoc in status 12 doesnt reach sap pi

Question

Hi folks,
I have an Idoc2file scenario which is working fine in most cases but occasionnaly a message gets lost:
SAP is sending the Idoc to port (goes to stat 03).
There is no rfc error, SM58 and table ARFCSSTATE is empty.
I run RBDMOIND and status goes to 12 meaning delivery is ok.
However in PI, transaction IDX5 I dont see the above Idoc and of course nothing in msg monitoring as well.
Have you any idea?
I am sending the same Idoc type and 20 Idoc goes fine through PI but 1 fails as described above.
Thus it is definitely not a configuration issue, please dont post howto links or blogs.
thanks

Answer 1

I'd agree with Werner's analysis above, there is (usually) a simple reason - a missing [COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm] (and that's the only reason I've encountered so far). The explanation is quite simple: If you have checked in the partner profile send immediately and create an IDoc, the IDoc layer will attempt to send the IDoc in an update process. Without the COMMIT WORK, the update function for sending the IDoc is never triggered and your IDoc ends up in status 03.
The next time you run BD75 (or program [RBDMOIND|http://help.sap.com/saphelp_nw70/helpdata/en/0b/2a66af507d11d18ee90000e8366fc2/frameset.htm]) for converting the IDoc status from 03 to 12 for successfully transmitted IDocs, SAP will check the outbound RFC queue and not find anything (due to the missing sending attempt in the update function) and thus change the IDoc status from 03 to 12 (despite the fact that SAP never even attempted to send it, but at this stage this is no longer known).
So in your sending SAP system everything looks completely fine and you have absolutely no indication that anything went wrong. This got me in trouble the first time I encountered this, because I kept arguing with somebody on the receiving side, that they must have received the IDoc and everything is completely fine on my sending side. What I had missed is that I shouldn't make such bold statements without actually checking the code generating the IDocs (and in my case it was custom code that I hadn't seen before)...
Once you change your partner profile to collect IDocs the sending is no longer triggered in the update process, but instead has to be triggered manually (or job) via report [RSEOUT00|http://help.sap.com/saphelp_nw70/helpdata/en/0b/2a6613507d11d18ee90000e8366fc2/frameset.htm]. Similarly WE19 has a completely different COMMIT handling, which is one reason why I never like to do any real testing there.
Anyhow, now I'm smarter and as suggested by Werner my checklist includes analyzing the code that generates the IDoc. One classic example I can think of for successfully sending some and not all is IDoc generation via change pointers, where the COMMIT WORK is often done infrequently (like every 20 IDocs). Here sometimes the COMMIT WORK for the remainder of the IDocs is missing (e.g. if 23 IDocs are created, a COMMIT is done after the first 20, but not for the remaining 3).
For those interested, check out function [EDI_OUTPUT_NEW|http://help.sap.com/SAPhelp_nw70/helpdata/en/dc/6b7ec743d711d1893e0000e8323c4f/frameset.htm] (it's so great that we can actually read the SAP code to figure out what's going on) - you'll see that the sending process is triggered (if send immediately is checked in the partner profile) via update task. Note that this means that [database commits via native SQL or implicit commits|http://help.sap.com/abapdocu_70/en/ABENDB_COMMIT.htm] are not sufficient to trigger the sending process.
Cheers, harald
p.s.: And if you don't have any custom code, then it might help to check [OSS|https://service.sap.com/notes] for any bugs that could cause this. See for example [OSS note 1501225 - Generated IDOCs are not sent occasionally|https://service.sap.com/sap/support/notes/1501225] for the very specific component BW-BCT-ISR-PIP (though unfortunately this note doesn't say if there actually are entries in the outbound RFC queue).