No receiver could be determined for ICO PI 7.3

[former_member235717]

Hi All,

I have created an ICO in PI 7.3. I have maintained necessary Integration engine configurations in ECC system SXMB_ADM to point to AAE .

This interface was working fine in Development but when we moved to QA, it is now throwing following error in PI abap stack.

I tried stopping the sender SOAP channel but still the message is coming in to the PI system and failing with following error:

<SAP:Code area="RCVR_DETERMINATION">NO_RECEIVER_CASE_ASYNC</SAP:Code>

<SAP:Stack>No receiver could be determined </SAP:Stack>

I'm not sure why this coming into ABAP stack . Could you please help me if I'm missing anything.

Thanks

[vadimklimov]

Hello Swetha,

Can you please check if there are any conditions set in receiver determination rules in the ICo, and if specified receiver communication component(s) is(are) correct / exist in QA environment?

@Venkata: if the issue would have been in attempt of invocation of the configuration scenario / ICo that does not exist in a called Adapter Engine (for example, because it was deployed to a different Adapter Engine, etc.), then the error should have been related to CPA object not found exception.

Regards,

Vadim

[Former Member]

I tried stopping the sender SOAP channel but still the message is coming in to the PI system and failing with following error:

<SAP:Code area="RCVR_DETERMINATION">NO_RECEIVER_CASE_ASYNC</SAP:Code>

<SAP:Stack>No receiver could be determined </SAP:Stack>

I'm not sure why this coming into ABAP stack . Could you please help me if I'm missing anything.

Hi Vadim,

Being an ICO it should not hit the ABAP stack of PI that is point of concern

[former_member186851]

Hello Venkata,

Check whether Soap channel has been used in other scenario?

Also check the cache status as other experts suggested.

[vadimklimov]

That's true. But assuming the ICo was maintained (and not classic configuration scenario), and if IS_URL is ECC has invalid configuration and attempts to call classic dual stack scenario (which would explain reason why the message is seen in ABAP stack of PI), I would expect to observe the error saying the object was not found in CPA cache. Based on the error Swetha provided, it looks like PI runtime found the configuration scenario in the cache, called it, but failed during receiver determination step. Which all together raises questions about:

• If ICo is used at all? As you correctly pointed out, looks like no - otherwise, Integration Engine of PI would have not been involved in message processing,
• Are conditions in receiver determination rules correct and do receiver components exist?

Regards,

Vadim

[former_member182412]

Hi Vadim,

But assuming the ICo was maintained (and not classic configuration scenario), and if IS_URL is ECC has invalid configuration and attempts to call classic dual stack scenario (which would explain reason why the message is seen in ABAP stack of PI), I would expect to observe the error saying the object was not found in CPA cache

ABAP stack of PI does not look in CPA Cache, it looks in SXI_CACHE, Swetha created ICO but not Classic configuration so the object exist in CPA Cache not in SXI_CACHE.

When the message reach to PI ABAP stack while executing receiver determination step, system is checking receiver determination exist in the SXI_CACHE, there is no entry in the SXI_CACHE for the sender component, interface and namespace and the system is raising error NO_RECEIVER_CASE_ASYNC.

Regards,

Praveen.

[vadimklimov]

Hi Praveen,

Absolutely agree with you: if we are about to use classic dual stack scenario, then ABAP Integration Server cache will be queried (my comment above was about ICo, which shall only be cached in CPA runtime cache). Still, if any runtime cache does not contain the object at all, then the expected error shall indicate which object key was looked up in the cache and was not found. But here the error is more like when the routing object was found in the queried cache, but receiver determination rules didn't yield to any receivers.

Regards,

Vadim

[former_member235717]

Hi Vadim,

I do have specified a condition in Receiver step, the receiver component is a valid and exists in QA .

I tried removing the condition and tested again. Still getting the same error.

We tried CPA cache refresh, re-imported all the objects again and recreated the SXMB_ADM ( IS URL and necessary configurations again). Still no luck.

[srikanthe_sapxi]

Hello Swetha,

Can you post your Dev and QA Receiver Determination condition screens for better understanding.

Thanks,

Srikanth E

[former_member235717]

I do not have any conditions now. I have removed the conditions and testing the plain ICO again. Still getting the error.

Here are the steps which I maintained:

In ECC

1. SM59 - AAE HTTP Destination type G

2.SXMB_ADM - IS_URL and Sender/Receiver ID parameters ( SI and namespace)

In PI:

Create SOAP sender channel with XI message protocol

I have clear Cache, re-imported the objects.

I have also deleted the objects in development re-created them and tested them which worked fine and then I re-imported them to QA . Again the same issue.

[former_member182412]

Hi Swetha

it is defnately wrong configuration of parameter IS_URL in sxmb_adm, can you put the screen shots which I asked above.

Regards

Praveen

[former_member235717]

Praveen,

Here is the screenshot

SXMB_ADM

[former_member182412]

Hi Swetha,

Some how your system is taking the IS_URL from the global configuration instead of interface specific IS_URL, you can find this in the trace of the message in SXI_MONITOR in ECC.

If it is taking from global configuration you can see the trace like below.

If it is taking from interface specific IS_URL then you can see the trace like below.

I tried with same configuration which you maintained in sender ID (Party = * and Component = *) and it is working from my side but try remove the * from the party field and maintain the ECC business system in the component field same like your ICO configuration in the sender ID.

Regards,

Praveen.

[former_member235717]

I do not see the trace level as specified by you in SXMB_MONI.

I did try without "*" but still resulting in the same error. Do we required any NWA settings?

[former_member182412]

Hi Swetha,

You can find the trace like below.

To be make sure 100% it is not typo error can you copy and paste from sxi_monitor of ECC system and paste it in sender ID after you save the sender ID, if you trigger from SPROXY or ABAP program you must reopen the transaction (by typing /nsproxy or /nse38) because if you are in the same screen then system will get the details from cache not from the table.

Regards,

Praveen.

[Former Member]

Hi Swetha,

As per your inputs the message is sent to PI ABAP stack  from there it is unable to find any further configuration so it is error out with No receiver found because it looking for Classical Scenario but in your case its ICO

To avoid this by maintaining  IS_URL configuration with respect to Namespace and service interface then the things will fall in Sync

Hope this helps

[former_member235717]

Hi Venkat,

I did maintain the SXMB_ADM config . This was working fine in Dev and only throwing error in QA. I tried switching to Classical scenario in QA and it did work . Issue is with only ICO.

[Former Member]

Hi Swetha,

Try a CPACache refresh.

Thanks Faith

[Harish]

Hi Swetha,

Please check if the destination is configured in PO QA env. Please check your configuration with the below document

and blog -

regards,

Harish

[former_member235717]

I did maintain the SXMB_ADM configurations in the ECC system.

The AAE_PI destination is also maintained .

Still getting the error.

I have tested with classic design and it worked fine. Not sure what I'm still missing with ICO

[former_member182412]

Hi Swetha,

Make sure you maintained same sender component, interface name and namespace in Sender ID configuration in ERP and ICO configuration in PI. If you have any spelling mistakes then it will not work.

Sender ID:

ICO:

Regards,

Praveen.

[former_member235717]

Hi Praveen,

I did maintain those configurations . As specified this worked fine in our development. I replicated and cross checked all the configurations in QA still getting the error. We have tried Cache refresh also.

Not sure why this is still pointing to IE

[former_member182412]

Hi Swetha,

Can you put the screen shots of sender ID and ICO like me? and provide IS_URL parameter with sub parameter in SXMB_ADM?

Regards,

Praveen.