cancel
Showing results for 
Search instead for 
Did you mean: 

Idocs take time to reach XI from R/3.

Former Member
0 Kudos

Idocs trigerred from R/3 takes around 45 mins to reach XI.

What could be the possible reasons for the same??

Accepted Solutions (1)

Accepted Solutions (1)

rajasekhar_reddy14
Active Contributor
0 Kudos

it looks problem in ECC end,check with basis team to check Logs in ECC.

Answers (5)

Answers (5)

Former Member
0 Kudos

Hi,

Please check the TCODE :We20 in ECC side

Collect IDOC or Trigger Immediately.

Then Check SMQ2 and SMQ1 and try to clear all

Regards,

Jude

Former Member
0 Kudos

hi,

In WE20, you certainly have your idoc in "collect Idocs" and not "transfer immediatelly". And so your outbound idocs are in waiting status (e.g 30). And so you use program RSEOUT00 to pick-up all your waiting idocs in order to send them to PI.

According to me, here's some reasons why you have to wait 45 mins:

1. maybe your scheduled abap job (SM37) on program RSEOUT00 is scheduled every 45 mins.

2. maybe in RSEOUT00 selection-screen, you have precise "maximum number of idoc = 1", and maybe in WE20 (partner profile) you have also "packet size = 1", so idocs are sent one by one... and maybe you want to send a huge quantity of idocs, so you need time !

regards.

Mickael

Former Member
0 Kudos

Hi,

Check this from SAP help regarding mass IDOCs settings.

Mass processing refers to bundling IDocs into packets that are then dispatched and processing in the receiving SAP system. Only one RFC call is needed to transfer several IDocs. Performance is considerably better if you dispatch optimal packet sizes.

To set mass processing parameters, in ALE Customizing choose: Modeling and Implementing Business Processes ® Partner Profiles ® Generate Partner Profiles. For a given message type you can define the outbound parameters, packet size and processing mode.

If the processing mode is set to Collect IDocs and transfer, outbound IDocs of the same message type and receiver are sent in a scheduled background job in an appropriately sized IDoc packet. The IDocs can be dispatched in a scheduled background job or in ALE Administration.

Some distribution scenarios cannot support mass processing of inbound IDoc packets. This is especially true if the application sending the IDocs uses the ABAP command CALL TRANSACTION USING. In this case the outbound parameter PACKETSIZE must be set to "1".

You can find a list of function modules for mass processing in ALE Development by choosing IDocs ® Inbound processing ® Function module ® Define attributes (BD51). These function modules have input type 0.

Check this note as well

Note 706521 - IDoc: Performance improvement when you create IDocs

Regards,

Venkata S Pagolu

former_member184681
Active Contributor
0 Kudos

Hi,

Here are some ideas on what to check:

1. Check what takes so long: is it really the IDoc despatch from ECC to PI? Or maybe you are using some custom logic during IDoc creation and this is what takes so much time? Check the time when the IDoc was added, for instance in we02. Does it match the time when it was triggered by the application?

2. Check the partner profiles - is queue processing used in your scenario? Maybe the queues are blocked, or just a big number of messages are created and it takes so much time to process them one by another?

3. You might want to consider packaging multiple IDocs into one RFC call, which also should help you improve the performance. This is also a setting of the outbound partner profile.

4. Try testing the connection to your PI system itself in sm59, maybe you will find something like a long response time or similar.

Hope this helps,

Greg

Former Member
0 Kudos

Have your Basis guys check the IDOC processing transactions in R/3. They may be waiting to be processed. Trans. BD87 may be your first check point.