Skip to Content
0

SM58: Failed to resolve repository reference-@XI_IDOC_DEFAULT_DEST_XXX

Nov 15, 2016 at 03:07 AM

636

avatar image
Former Member

Hi Experts,

we are facing issue on SM58 where IDOCs entries are stuck.

I read all the below blogs but nothing help much.

https://archive.sap.com/discussions/thread/3914635 https://archive.sap.com/discussions/thread/3474239

Problem here is that, when i retrigger, it pushed successfully. so I couldn't confirm that configuration issue, IDOC issue as it passed by reprocess.

Flow - SAP ECC to SAP PI

Right now we manually reprocessing it everyday, but it is not ideal and would like to fix it permanently. please suggest us- what need to be check.

Regards

Prabhakaran

SAP Netweaver Consultant

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Mario De Felipe Nov 15, 2016 at 01:17 PM
0

Hello Prabhakaran

in our system we have hourly jobs that execute the following reports to reprocess tRFC and qRFC

RSARFCEX: Restart tRFC LUWs

RSQOWKEX: Restart QOUT qRFC LUWs

RSQIWKEX: Restart QIN qRFC LUWs

With them you will not have to reprocess manually.

Show 3 Share
10 |10000 characters needed characters left characters exceeded
Former Member

thanks for the suggestions.

but we are looking for cause of the issue. Why it is not pushing at first instance but passing successfully while reprocess it.

Regards

Prabhakaran

1

sure, that is worth a look, but in production enviroments that fails happen frequently, tRFCs and qRFCs run very frequent and failures happen, its quite normal to reprocess the failing one by a background job.

good luck!

0

forgot to say, it will be a difference if ECC to PI communication is based on Integration Engine or Advance Adapter Engine

in first case the communication is done through RFC and you can check logs in RFC devs, in second case if it goes through AAE proxy you will need to check in default trace of Java to see what errors in Java might have been caused not to accept the communications, maybe PI java is under heavy load and no threads are available.

0