topic IDOC receiving delay in Application Development and Automation Discussions

IDOC receiving delay

raffinkira — Thu, 04 Aug 2016 05:53:25 GMT

I am fixing a problem.

My client has two systemes, let's say A and B.

Some days ago, he told me that systems B received IDOC data from A, delayed for one week.

Sending data is 20th July and receving data is 27th July.

IDOC is using tRFC, so I checked SM58 but I cannot find any infomation of RFC request.

I have two questions:

1, How it is possible to have this data delayed receiving happend?

2, How many days SM58 keeps the information of RFC request?

Re: IDOC receiving delay

diwaneamit — Thu, 04 Aug 2016 07:39:40 GMT

Hello Ming,

There might be a possibility that your idocs has been stuck in the queues (SMQ1 & SMQ2). As queues might have got cleared now the idocs are posted.

Regards,

Amit

Re: IDOC receiving delay

raffinkira — Thu, 04 Aug 2016 09:27:40 GMT

Thanks for the reply.

Actually, after checking WE02, I found the status of sended IDOCs are successful, which means they are sended immediately, not getting in stuck.

So question is why the receriver received IDOC 7 days later? Where were these IDOCs in that 7 days?

BTW, as my client said, this case occasionally happened, and just for some continous IDOCs in a few seconds.In most cases it works well.

Re: IDOC receiving delay

Former Member — Thu, 04 Aug 2016 11:35:20 GMT

Hi Ming,

If your systems are two separate boxes, what is the middleware system that your client is using? There might be a possibility that the idoc were stuck in the middleware system and released to the receiving system after 7 days, although this depends upon what middleware system is deployed.

There is no limit that SM58 can hold a specific amount of data. You can check the relevant info in table ARFCSSTATE & ARFCSDATA.

If you did not find anything in SM58, then probably the idoc was transferred successfully to the middleware system hence that particular transaction id was removed if your client has that kind of landscape.

Regards,

Sampat

Re: IDOC receiving delay

ziolkowskib — Thu, 04 Aug 2016 11:43:27 GMT

Actually status in WE02 does not prove it was really successfully transmitted. If it got stuck in queue or SM58 you would also see that IDoc with status 03.

Re: IDOC receiving delay

raffinkira — Fri, 05 Aug 2016 02:35:29 GMT

I have confirmed that there is no middleware system. A connect to B directly by ABAP connection in SM59.

Through WE02, I can find tRFC ID of IDOC, can I use the ID to trace the history of sending status in ARFCSSTATE & ARFCSDATA, although no information can be found in SM58?

Re: IDOC receiving delay

Former Member — Fri, 05 Aug 2016 07:33:36 GMT

Hi Ming,

I don't think you can trace the transaction ID from ARFCSSTATE & ARFCSDATA since you say the idoc has already reached your destination system. You might wanna check with your basis consultants to find any logs if generated of the ID.

Since the idoc is going through tRFC, SAP doesn't need to check whether the remote system is active or not at the point of sending. If the idoc was not received at the correct time, it could be the remote system was inactive for long and the transaction was present in the queue for 7 days ( check with the basis guys for more detailed info ).

Also try to check the program RSARFCSE run in batch mode. SAP executes this program if the specified period gets lapsed when the idoc coudn't be transferred to the destination system. This specific period can be customised and so varies.

Regards,

Sampat

Re: IDOC receiving delay

Jelena_Perfiljeva — Fri, 05 Aug 2016 21:27:37 GMT

RFC connection trouble?

It's not an ABAP question really. RFC queue could be stuck for a month (maybe even more but haven't happened so far with us) when Basis is asleep at the wheel. Then when the Basis guys fill up on coffee and kick the connection then the floodgates open, so the target system will get all the data that was stuck there.

Ask Basis admin if there were any RFC connection issues, maybe they'll fess up. Other than possibly system log it's impossible to confirm after the connection has been restored because it just clears the entries.

Since this is an IDoc interface then you could try and build in a confirmation mechanism. So that you get an actual confirmation back from the receiving system. For example, we had these weird issues with EDI invoices because of some connection problems. But what we didn't realize that even though IDocs were "green" they didn't actually have the "confirmed" status (12, I think). Our EDI integrator sends a confirmation back when everything is fine. Now we check for this status, not just the first "green" one. As Bartosz also noted above, unless it's fully confirmed it only means that IDoc was passed to RFC port.

Re: IDOC receiving delay

raffinkira — Sat, 06 Aug 2016 00:51:28 GMT

Thank you for your reply.

Actually, only some IDOCs in a few seconds missed and most of IDOCs are received in the remote system in time. Do you have any idea of that?

Re: IDOC receiving delay

Muniyappan — Sun, 07 Aug 2016 12:10:16 GMT

Bartosz is correct.

you may check this blog written by Vadim Klimov

Re: IDOC receiving delay

Jelena_Perfiljeva — Mon, 08 Aug 2016 13:30:44 GMT


Ming Yu wrote:

 Do you have any idea of that?

Several people have already shared their ideas here. Are these insufficient? If so then why?