No receiver could be determined

[Former Member]

Hello,

No receiver could be determined, is the error and the messages are stuck in SMQ2.

its on production system, i am new to project, i checked the cache and it is fine.

the interfaces are running perfectly since 2010, what will be the issue.

how to clear SMQ2.

attached is the screen shot.

[MichalKrawczyk · Accepted solution]

Hi,

a) check the message flow in ID (Test scenario from the menu) to be able to check if there is a receiver for this message

b) you can also check in the cache if the reciever is there (open the CPA cache and search for the object from ID)

c) you can clear the SMQ2 by saving the LUW from the menu (it will go to SMQ3 and you can reprocess it later) but enver delate the LUW on PRD systems - cancel the message instead in SXI_MONITOR (or RWB) this will also "remove the SMQ2 entry but in a correct way)

Regards,

Michal Krawczyk

[anupam_ghosh2]

Hi Phani,

                   Obtain the inbound payload from production system. Now in development system go to ID. Then in ID inder main menu bar---->Test configuration. Here paste payload, fill up details of service , interface namespace as that of production. Be careful as service names might be different for development system. Now run the scenario and check if the configuration is correct.

You have not mentioned the scenario. You need to replicate same scenario in development server as that of production to do an end to end testing. If development server is also giving same errors then there is a problem in    revceiver determination condition in ID, wrt payload. Check this and correct this. In case in development the scenario is performing OK with asme paylosd then compare each object in development with that of production. In case the objects are also same  then this might be a cache issue, consult your BASIS team.

Regards

Anupam

[iaki_vila]

Hi Phani,

Are you sure that there aren't any changes in XI/PI SLD or someone changed accidentally the configuration?

What kind of scenario has this problem?, may be the client is calling wrong now, you should check your client call. From my point of view you can try the same call in production system with a correct payload  that it has failed (with SOAP sender with SOAPUi for example ) or more secure trying to reproduce the call in test enviroment.

Regards 

[former_member184681]

Hi,

I have one more idea that was not mentioned yet. Maybe your Receiver Determination has conditions, and none of the conditions were met, because of some unexpected value in the field based of which the receiver is determined? The fact that your scenario is already live in production for two years, seems to confirm my idea. If I'm right, you have two options: influence the value of the field on the sender side, or add a new condition in RD forr this value.

Regards,

Greg