Idoc in status 12 doesnt reach sap pi

[gabor_hornyak]

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

[former_member624067]

Hi,

this iussue for me was attributable to "full tablespace" on the PI side: following IDOC_INBOUND_ASYNCHRONOUS in debug session I've found the Exception CX_SY_OPEN_SQL_DB with associated Runtime Error DBIF_RSQL_SQL_ERROR.

See the blog https://blogs.sap.com/2015/06/20/runtime-errors-dbifrsqlsqlerrorerror-text-of-the-database-ora-01653...

Cheers, hope it helps

[gabor_hornyak]

Hi All,

I couldnt find any explanation yet for the problem.

Many of you are suggesting to check ports, configuration, commit works etc.

As the problem occurs rarely, I am pretty sure that the config is ok.

In the PI system there is no trace of the Idoc, there is no blocked queue.

It is also not a cache problem as missing Idocs and transferred Idocs are often created in the same minute.

So my guess was resource allocating issue.

What I did is to set Idoc processing to collecting mode instead of immediate processing.

Now I dont have any more missing Idoc.

That solution seems to be working for me but I am still wondering where the missing Idocs are gone. For that reason I dont close the thread maybe somebody comes up with a good explanation.

[Former Member]

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).

[gabor_hornyak]

Hi Sandeep,

we have a 4.6C so no SXMB_ADM available there

anyway that queue monitor is for qrfc and Idoc goes in trfc queue (sm58) am I right?

in we20 I have only Idoc collecting or immediate transfer, no queue option

I am using immediate tr

[Former Member]

Hi Gabor,

You need to run SXMB_ADM in your PI system (not the backend ECC system, where the idoc was sent). Also you can run SMQ2 in PI to check if any entry is stuck in the queue.

Regards,

Shawn

[Former Member]

Hi Gabor,

Were you able to identify the issue here?

We are also facing the same issue in our landscape and the IDoc seems to be lost.

Your inputs will be appreciated.

Thanks & Regards,

Sidhartha

[Werner_Magerl]

Hello,

I very often saw this problem when creating the IDOCs with Z-function modules.

How do you trigger your IDOCs, with SAP standard routines or with self programmed modules?

You have to check to enqueue the IDCO number (see locking table in ERP) and you have to do a COMMIT WORK

at the end of the IDOC processing.

This is alsothe reason why it works in WE19, becuase here the transcation is doing the COMMIT work....

best regards

Werner

[former_member207622]

have you created the port in the format SAP( SystemID ) ? wen you trigger the IDOC check the RFC destination whether its pointing to PI or not .

Regards

Ninad

[Former Member]

Hi,

We are using standard SAP routine for processing and hence commit work is also handled there. Not sure what is causing this issue, though this occurs very very rarely.

Thanks & Regards,

Sidhartha

[Former Member]

Hi Ninad,

The ports are pointing to PI and this happens rarely and hence it does not point to the port having an issue.

Thanks & Regards,

Sidhartha

[gabor_hornyak]

I have duplicated the Idoc in we19

this time it has reached PI with no problem

this means the partner profil and the control record is good

the problem occurs randomly - maybe a performance issue or some locking mechanisme is behind it, I dont know

anyway it doesnt get an error status and I have no chance to resend it automatically

[Former Member]

Hi,

Delete the Idoc metadata from PI and create it again in Idx2. At times there is any issue with structure mismatch and hence data is not further processed in PI.

Regards,

Milan Thaker

[former_member208856]

When you can send it using WE19, when duplicating existing IDoc, it means that Partner Profile & Ports are working fine.

Also when it is there on PI System, it means IDX2 matadata is also working fine.

Just activate the queues on ECC System in SXMB_ADM --> Manage Queue --> Select queues --> Activate.

Also in WE20 (Partner Profile) click on Transfer IDoc Immediately & Queue Processing.

[Former Member]

Check the Control records of that particular IDOC which is not reached into XI, you may get some clue.

[Former Member]

Can you check the port of that certain idoc from your partner profile setup if its in the direction of your PI System?

Regards,

R-jay