Performance issue loading bundled IDOCs

[Former Member]

Hello, we are using XI 3 with SP23.

We are using IDOC Bundling to send MATMAS updates to our ERP system.

It takes about an hour to load 800 records and we'd like to load 50,000. They seem to leave XI OK (checkered flag appears in matter of seconds) and then the records all turn yellow for about an hour in SAP. Then they finally turn green nearly altogether. So it appears the bottleneck is on ERP side? Since they seem to act in a single threaded way when loading on ERP side, is there a way to control this behavior?

Does anyone have suggestions on how I can troubleshoot, pinpoint bottleneck, or improve the situation?

Best regards,

Aaron

[Former Member · Accepted solution]

ask your basis team to increase the table space on r/3 side..

[Former Member · Accepted solution]

We asked our BASIS team to investigate this. They said the process was completely CPU bound, no memory or disk constraints, and that the DB was only taking a tiny slice of time compared to general processing. So they had no recommendations to improve speed.

We tried an alternate approach of sending one IDOC at a time through XI (no bundling) and though it goes slower through XI it goes much faster in ERP. It took only 1 hour for 5000 records this way. So 10 hours to load our master parts data rather than a week I guess is a big win. But still it seems slow to me and it seem that IDOC bundling should be the preferred approach.

If anyone can shed further light on this I will re-open and award points, but am closing for now because we have an acceptible solution.

Thanks,

Aaron

[Former Member · Accepted solution]

Hi,

my question is, whether you could check that IDocs are really "waiting" in ERP (monitor through SM58 - you should see a lot of messages there) and are just finally processed after one our. Or if they are processed (no / few entries in SM58) in ERP and just set to "processed" after an hour because the report that changes the staus of the IDoc runs every hour.

What exactly is your configuration in WE20 for the inbound of these IDocs?

Thanks,

Kai

[Former Member · Accepted solution]

Hello Kai,

Our BASIS team says the CPU is almost totally consumed for the whole hour and then they finally committ at the end.

Our partner profile in this case for MATMAS uses process code AFSA, cancel processing after syntax error, and Trigger immediately. Are there any other pertinent settings in Partner Profile I'm missing?

Thanks,

Aaron

[Former Member · Accepted solution]

Ok - settings in WE20 seems to be okay.

Now what about the messages in SM58?

Also you might consider following:

Although you set "trrigger immediately" in WE20, if the system has no resources left to process the messages immediately it will automatically schedule a job (SM37) for each message. Please check SM37 for the specific time.

Also ask you basis guys whether enough work processes are available. They need to check this.

Maybe there is a process running in background or on DB level (Statistic job, ....) that causes delay on your message processing.

Kai

[Former Member]

Hi,

We too faced the same Issue a long back,and we raised OSS also

For this you have to do it on R/3 side like increasing the parameters in Tables to process the records in a fast manner

Check with basis team..

Regards

seshagiri