IDOC receiving delay

[raffinkira]

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?

[raffinkira]

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

[diwaneamit]

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

[raffinkira]

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.

[ziolkowskib]

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.

[Muniyappan]

Bartosz is correct.

you may check this blog written by Vadim Klimov

[Former Member]

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

[raffinkira]

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?

[Former Member]

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

[Jelena_Perfiljeva]

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.

[raffinkira]

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?

[Jelena_Perfiljeva]

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?