Idocs stuck in SM58 in PI - transaction recorded status

[Former Member]

Dear Experts,

I need your urgent help.

I have a file to Idoc scenario in which one file creates two idocs(WGSREQ and WPUBON).We are creating two idocs using 2 message mapping and included in single interface determination. The idocs are set to process immediately in WE20.

For this scenario, the load of messages is very high. High load is generally for Idoc1(WGSREQ). But the other idoc(WPUBON) is important to get posted in SAP before 9pm. But due to high load of first idocs, second idoc messages also get stuck in SM58 coz of which we missed the timelines.

Please suggest if we split this one interface into two interfaces, can it solve my problem??

Please suggest any other idea to reslove it.

Thanks in advance!!!

[udo_martens · Accepted solution]

Hi Danish,

did you know about Prioritized Message Processing?

/Udo

[Former Member · Accepted solution]

Hi Udo,

Thanks.

But I also want my msgs do not get stuck in SM58.

I have checked the link provided by Beena and we are getting an issue that sometimes we have noticed "not OK" status and most of the times OK status in SMQS. It fluctuate between not ok and ok.

Please suggest

Regards

Danish

[Former Member]

Hi Danish,

Please configure message prioritization in integration engine.

we also had the same issue some days ago and prioritizing the messages has resolved the error.

As of how to do, I see there are links for the same or search in scn, you get clearly mentioned step by step guide.

Regards,

Amarnath

[Former Member]

Hi Experts,

Let me correct onething.

We have many inbound idoc scenarios.

Amongst them, there is a scenario in which two idocs get created from one source file all the time.Between both of the idocs, one idoc is important to get posted prior to 9 pm.There is time constraint for one IDOC to be posted in SAP.

Since messages got stuck in SM58 in inbound processing, so the posting of that idoc get delayed due to which there is a business loss.

@ UDO : Please suggest if we can prioritize the posting of one idoc alone which are stuck in SM58 by that method or any other way by which messages do not get stuck in SM58 ??

[ambrish_mishra]

Hi Danish,

Is it that this file will create both the IDocs on execution. I think no, because you mentioned WGSREQ are created in high volumes.

Is there a dependency between the execution of 2 IDocs ? If not, you can set the IDoc WGSREQ with high message volume to collect mode in ECC (partner profile) and run report RSEOUT00 in background mode with an agreed time gap. For the other important IDoc, it can continue to run in foreground mode.

Also check the system resources and MAXCONN parameter.

These points are given in the link http://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=145719978  given by Beena.

Hope it helps.

Ambrish

[Former Member]

Hi Ambrish,

I apologize for the info in the main question.Later, I corrected myself. Actually, everytime source file creates both the idocs.

You are right that there is no dependency between the execution of 2 IDocs so we can schedule one in background(less priority idoc).

I schedule the report RBDAPP01 in background for inbound posting of idoc but I noticed lots of spool creation in SP01. That's why I have yet not implemented.

Regarding Beena's link, I checked the system resources and I found that sometimes  status shows "not ok" and most of the time it appears to be Ok in SMQS.

Please suggest if this fluctuation of OK and not OK in SMQS could be the problem?? And how to reslove it?

I have also noticed onething, when data backup is scheduled in R/3 then messages get stuck in SM58. If no backup is scheduled then messages do not stuck in SM58. Can the backup also be the reason or it's only my misconception.

Regards

Danish

[ambrish_mishra]

Hi Danish,

In production, you normally have background jobs running to clear the spool periodically. You can take a look at the link http://www.erphome.net/pdf/saezpdf/033saez.pdf. You will find information available on SDN to delete spool data.

Fluctuation of Ok and not Ok may be due to un-availability of system resources. You can also tweak the MAXCONN parameter based on system resources available.

For both of these activities, please work with the basis team and they can take care of these points.

This should resolve your problem.

Hope it helps.

Ambrish

PS: Reward points if helpful

[Former Member]

Hi Danish,

Please check this:

http://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=145719978

Regards,

Beena

[Former Member]

Hi Beena,

Thanks for your reply.

I have checked that link.

In SMQS, qRFC resource shows sometimes "OK" or sometimes "not OK "status.

Please suggest what  could be the problem?

Regards

Danish