Messages stuck in SXMB_MONI with status "Log Version"

[Former Member]

Hello,

I am facing a strange issue in my synchronous scenario: HTTP--> PI--> RFC .

All the messages for this scenario are stuck in SXMB_MONI with status "Log Version" (grey circle sign). Inside SXMB_MONI traces, I can see everything has processed successfully only until Technical Routing step without processing Call Adapter step. After that the message says pipeline processing completed.

Please help how should i proceed. I have already spent half a day searching over SDN and other sites....

Also, is there a way to find out if PI has actually made any RFC call to ECC ?

Please guide.

[nabendu_sen · Accepted solution]

Hi,

Please check in Receiver RFC Adapter from Communication Channel Monitoring of RWB, if you find any error. Also check ST22 (Run-time Dumb) in Receiver SAP system.

This problem occurs for Synchronous scenarios when PI wait for Response back from receiver system, but either the Response never come / take too much time. You need to properly check the Receiver RFC and debug.

[Former Member · Accepted solution]

Hi Nabendu,

I also thought on these lines but unfortunately did not find any clue.

In RWB, the CC does not show any messages.

[nabendu_sen · Accepted solution]

Hi,

Then can ask ECC guys to check whether the RFC is called at all or not. This is some issue related to BAPI/Function Module at their side which needs to be debugged. Can you check whether any other Sync RFC scenario in that system working fine or not?

[Former Member · Accepted solution]

Thanks for your quick response.

It is a standard BAPI_PO_GETDETAIL and this interface was working fine until recently. I tested the BAPI in ECC and it is working fine. Unfortunately, this is the only synchronous scenario in the landscape .

Also, is there a way in ECC to check if a particular BAPI/RFC was called and check the logs ?

Any other pointers please ?

[Former Member · Accepted solution]

Also as i said, Inside SXMB_MONI traces, I can see everything has processed successfully only until Technical Routing step without processing Call Adapter step. so if call adapter has not executed then i wonder how PI could make a connection with ECC ..........and wait for response .......

[Former Member]

Hi Guys,

The same problem occured in SAP ECC side for ABAP inbound proxy side with a synchronous interface waiting forever at scheduled status. (It was not the same issue per note 1791529 - which was for the problem in PI side)..

SAP advised the corection note 1471001 on the ECC side, we are in the process of applying this.

I will update this per results of the note implementation.

Amith

[Former Member]

Hi ,

Please go through the below links once.

http://scn.sap.com/thread/117430

http://scn.sap.com/thread/632393

Regards

Venkat

[Former Member]

Venkat,

As i had said, i already spent half a day on searching SDN and have practically seen all the threads related to this matter.

I would appreciate if you share some experience and knowledge rather then links

[agasthuri_doss]

Gupta,

Can you check the Queue status in ECC & PI.

Cheers

Agasthuri

[Former Member]

Hi Nabendu,

Have you ever resolved this issue? We are running into the same problem with no answers. We even opened up a message with SAP and still being investigated by them.

Issue: Synchronous message stops at one of the pipeline steps, and expires due to timeout. This stop happens in both direction , request or response, but only one of them.

The timeout (keep_live) was at default and has been increased to 15 minutes, and tested with 30 minutes, and these messages expires no matter how big the timeout is.

The payload is small and no difference from succesfull messge payloads. There are no mapping issues because if the message stuck is tested with mapping, it produces the result correctly in no time.

Our version is PI 7.0 SP20. The application server is Windows NT.

Any help is appreciated.

Amith

[Former Member]

Hi Guys,

SAP came up with a solution through an OSS note 1791529. This has a workaround and a permanent fix. We have implemented the workaround in our developments system, and we haven't seen the issue since then. We are still watching this and I will update this as we continue to monitor.

It interesting to note that this effect is obeserved only on WIndows per OSS note.

Hope this helps, if you are still having  this problem not fixed!

Amith