IDOC queue filtering based on message type

[Former Member]

Hi All,

This is PI Single stack

I have a concern regarding the IDOC's..

Assume, sap ecc generated 500 idocs in a day in which 300 idocs reached to PI and 200 idocs wherenot reached to PI due to which PI Server was down.

I have a doubt ifiam correct or not, how many times will ECC will try torepushtheidocs to PI.

I have checked in sm58, in queue levelican able to see huge data which was stuck. Iam not knowinghow to filterparticular message typerelatedidocs whichwas stuck inecc.

Give me any solution in such a way that when PI serveris up the ecc system should repush all the idocs which wherestuck in sm58..

[former_member183908]

please follow as per Harish suggestion it makes things simpler when we don't have a straight approach.

Export the SM58 entries to local file ( System -> List-> save -> local file)

Copy the TID values

go to EDIDS table (se16) -> paste the above values under TID field.

You'll get the corresponding IDOC numbers.

Once you have the IDOC number's it's not a big deal to find out the message type they belong to.

Thanks

[Former Member]

Thanks for your reply,,

while i am monitoring sm58..

the screen appeared as attached.

when i click on caller, its showing binary code and i am fully confused which is this idoc number in sap.

Suggest me how to look a particular idoc number in sm58 or smq1..because, when i choose particular destination and execute..its showing huge entires,,not able to find.

And also, suggest me for what purpose we use smq1 or smq2 for the stuck idocs( we are using pi single stack)..

this is actually outbound idoc from ecc..So, should we need to check even in smq2(inbound queues)?

We create only tcp/ip rfc connection..so what is the need for checking in smq1, smq2(this is actually for qrfc monitoring only know..) how come we can able to check qrfc destination for this case.

[former_member184720]

Did you check my reply on how to retrieve IDOC number using TID from SM58 ?

SMQ1 and SMQ2 got nothing to do if you are sending the IDOC's over TRFC.

[PriyankaAnagani]

Hi Ram,

As I see the error message in the screenshot it looks the user Id used in connection is locked because of too many failed attempts with wrong password. Please check if the user I'd used in connection is locked in PI. Also check the ECC user Id used in XI_DEFAULT_DESTINATION is locked in ECC. If locked please unlock the same. Then restart Idoc sender channel and reprocess the Sm58 entries. Also make sure you enter correct password in the connections.

Regarding smq1& smq2, I'm talking about queues in ECC system and not in PI as its single stack. Also as your Idocs are outbound ones, you've nothing to do with inbound queue smq2. But you need to check outbound queue in Smq1 if you are sendingidocs by qRFC.

This can be enbled by checking queueprocessing check box in port/partner profile.

If you don't have any such sequencing enabled, then you need to check only in tRFC sm58.

Regards,

Priyanka

[nitindeshpande]

Hello Ram,

As Hareesh told, IDOC has nothing to do with qRFC, which are monitored through the tcode SMQ1 and SMQ2. But IDocs are tRFCs hence these can be viewed in tcode SM58.

Please go through the below blog of mine on the queues, you will get a complete idea -

http://scn.sap.com/community/pi-and-soa-middleware/blog/2015/07/13/queues-issues-in-sap-pi-and-ecc-s...

To view, which IDoc is stuck you can click on the function module IDOC_INBOUND_ASYNCHRONUS and there navigating down, you can find the complete data, which also consists of IDoc number and message type.

Regards,

Nitin Deshpande

[PriyankaAnagani]

Hello Nitin,

Outbound Idocs can get stuck in smq1 if they are processing in sequence as I mentioned earlier. Idocs by default go through tRFC but if we want sequencing of Idocs we can enable it and such Idocs go through smq1 and through sm58. We've multiple Idoc sender sequencing scenarios and we did face the issue multiple times Idocs getting stuck in smq1.

However in this case the Idocs are there in sm58 with logon no longer possible error as per screenshot.

Regards,

Priyanka

[PriyankaAnagani]

Hi Ram,

Your troubleshooting depends on the Idoc processing whether they are processing through tRFC or qRFC.

If IDocs are processing through tRFC :  as you are aware of the date/time when PI server was down,

• Go to SM58 in ECC system and enter the respective date
• Enter the tRFC destination(as you are in PI single stack you need to provide the TCP/IP connection you created in ECC to PI).
  
  Once the selected list is displayed, you can double check whether its the same IDoc or not by double clicking on the first column(caller) that displays IDoc number and its data. Then you can reprocess them by selecting Execute LUWs from the Edit menu.

If Idocs have sequential processing(qRFC):

• In ECC system, to go SMQ1 and enter the qRFC destination name(same as mentioned above). Then you can reprocess the IDocs.

Regards,

Priyanka

[iaki_vila]

Hi Ram,

AFAIK IDOC tracing (IDX5) is not supported in PI single stack. You only can try to search them in the PI IDOC monitor ().

Regards.

[Former Member]

Hi Vila,

My concern is when the PI is down, i am unable to find the remaining 200 IDOCs in the PI. I have checked completely. It got stuck in the queue sm58. Here, i am not knowing how to find for which message type this idoc belong too.?

[former_member184720]

Export the SM58 entries to local file ( System -> List-> save -> local file)

Copy the TID values

go to EDIDS table (se16) -> paste the above values under TID field.

You'll get the corresponding IDOC numbers.

Once you have the IDOC number's it's not a big deal to find out the message type they belong to.

[pvishnuvardan_reddy]

Hi Ram,

In ECC SM58 transaction, there is no option provided to search based on specific message type/IDOC type. But you have the option to search by giving RFC destination created to route the IDOCs to PI in the parameter TRFC destination on the selection screen.

Coming to retrying, we can repush the failed ones manually just by going into SM59 tcode in ECC system and selecting the failed one's and by pressing the reprocess option available in the window.

Can you check the below blogs which might be helpful in your case.

SAP XI/PI: Alerts for tRFC(SM58) Errors

Entries in Transaction SM58 are in status "Transaction recorded" - ABAP Connectivi...

Regards

Vishnu