Proxy Error: Couldn't retrieve inbound binding for standard ES Content

[Former Member]

Hi experts,

We have an issue with a generated proxy from standard ES content of an SAP GTS <-> SAP TM integration scenario.

The scenario is:

proxy outbound (SAP GTS) -> PI -> proxy inbound (SAP TM).

Since it is standard ES content, all proxies have been generated automatically based on the ESR content. All proxies in both systems have status green.

Now, if a message is triggered from SAP GTS system for Service Interface "TradeComplianceCheckSUITEConfirmation_Out" (by using the respective GTS transactions), the message fails with the following error:

com.sap.aii.af.service.cpa.CPAObjectNotFoundException: Couldn't retrieve inbound binding for the given P/S/A values: FP=;TP=;FS=<Customer's From Service>;TS=<Customer's To Service>;AN=TradeComplianceCheckSUITEConfirmation_Out;ANS=http://sap.com/xi/GTS/Global2;

I know that this message usually appears when the configuration is missing in the Integration Directory, however the configuration is there. All communication channels are working.

When I manually test the outbound proxy mentioned above in the GTS system (with the proxy test tool), the message goes through via PI to SAP TM system. Even when I paste the payload of the crashed message (with above mentioned error) in the proxy test tool the message goes through.

According to the SAP GTS Master Guides, there need to be some SOAMANAGER settings to enable the GTS system to send data to PI or directly to SAP TM system (depends on the targeted integration). All these settings have been made (based on our experience)  to enable the integration via XI protocol (proxy).

When I check the tracing information of the errorneous message in SXMB_MONI, I see the following:

Does anybody have an idea what the issue could be? Am I missing something?

Thank you very much for your help!

Best Regards

H.

[Former Member · Accepted solution]

All,

Thanks for all your help, however we didn't find a solution yet and SAP moved our OSS ticket to 3rd level support so I assume that this could be a bug. I'll keep you updated on this issue.

Best Regards

H.

Update: SAP responded. Indeed there is an issue with the triggering of the outbound service from GTS. Therefore, the integrated configuration on PI had to be changed by using the virtual receiver option and using the TM system as virtual receiver. Reason for this is that the outbound message from GTS contains TM as a receiving system in the SOAP header what is usually not required when PI is used as integration server (only sender system should be part of the SOAP header => routing is done by PI). After changing the ICO, the scenario works. However since this is only a workaround, we are still in contact with SAP to clarify if a final correction on GTS will be available.

Integrated Configuration with Virtual Receiver settings for TM system:

[pr11061983 · Accepted solution]

offcourse, no need of sender agreement

Specify the Sender Service and Receiver Service in header Mapping of receiver agreement.

Pankaj

[Former Member]

Hello ,

We are currently looking for detailed documentation on the integration of TM 9.0 with GTS 10.1 (Point to Point). We would like to know which business scenario's need to be implemented for compliance and customs? Is there some documentation available to explain the way these business scenario's should be configured in SOA manager.

Thanks in advance

Regds

Frank

[Former Member]

Hi Frank,

Did you check the SAP TM Master Guide? (can be found in the SAP Support Portal)

Also the following link could help:

Best Regards

Harald

[former_member203691]

Thanks for posting that information about the workaround, Harald. 

Question, did you have the same issue with the ExportDeclarationSUITEConfirmation_Out interface as well?  Or did that one work for you?

We are seeing a short dump whenever GTS is trying to create the confirmation message after processing the export declaration from TM. Nothing ever makes it into PI.

Thanks,

Liz Alonso

[Former Member]

Hi Liz,

Yes we had the same issue with ExportDeclarationSUITEConfirmation_Out. The workaround works as well here.

Best Regards

Harald

[former_member203691]

Hmmm... I'm not sure if we don't have some other issue (not that we won't run into the other one later). 

GTS isn't even sending a message to PI so I'm not seeing a PI error at all.  It dies in GTS with a short dump before it can even create the PI message. 

The short dump text says: "No Technical Receiver maintained for Service Group /SAPSLL/SGROUP_OUTBOUND".

I'm not sure if there is something that isn't set up right on GTS, I've never seen this error before.

Anyone seen this?

Liz

[Former Member]

Hi Liz,

Did you perform all the necessary setup steps in transaction SOAMANAGER in GTS? If yes and you still get the error, try to apply the workaround and let me know the status.

Best Regards

Harald

[former_member203691]

Hi Harald,

We have a document titled "Integration of SAP TM with SAP Global Trade Services" which says we can either use 1) PI mediated or 2) point to point connection.  We already use PI ABAP proxies for all the TM/ECC interfaces we have so we chose to do it the same.  I imported the configuration scenario into the integration directory as we normally do (and is also described in the GTS document).  The document does not mention having to do anything at all in the SOAMANAGER for the PI solution, it only mentions it if you use the point to point approach which isn't what we are doing. 

TM is able to send messages into GTS just fine... it's only GTS that has the issue.

I'm not aware of ever having to do anything in SOAMANAGER for ABAP proxies... ?  Am I missing something?

Liz

[Former Member]

Hi Liz,

We have SOAMANAGER settings in GTS.

See below:

Best Regards

Harald

[former_member203691]

Thank you Harald! 

After reading your reponse, I did some digging and found a more detailed document that did mention the configuration in the SOA manger being required for both communication methods. 

I provided our Basis admin the screenshots and the documentation I found, but he's not clear on how the provider business system needs to be set up in there.  Can you provide a sceenshot that shows that part?

Best Regards,

Liz

[Former Member]

Hi Liz,

The screenshots below. Hope it helps!

Access URL is URL of TM system:

Best Regards

Harald

[former_member203691]

Thank you VERY much, Harald!  We will give this a go!

Have a great weekend!

Liz

[former_member282021]

Hi Harald,

I am the Basis contact Liz is working with. Thank you for the help so far. We're a lot further along than we would have been without you. I have a couple of questions:

1. In your screenshots of the provider system. Is that your PI system, the GTS system, or the TM system.
2. On your other screenshot of the Logical Receiver Determination - can you show me what your Routing screen looks like. And let me know what system(s) you have routing maintained for (GTS, TM, or PI)?

Thank you for your time.

Michael

[Former Member]

Hello Michael,

1. That is the TM system. Setting is done in SOAMANGER on the GTS system.

2. Routing screenshot:

Routing is done for TM system only.

Best Regards

Harald

[former_member203691]

Thank you again, Harald! 

We finally got it working.  If it weren't for you, I'm not sure we would have. None of the details at this level were documented in any of the GTS documentation.  It's really pretty sad that SAP can't do a better job of documenting software that customers have paid substantial amounts of money for. I've worked with lots of big software companies over the years and never seen the likes of it.

Holler at me if you are going to be at TechEd in Vegas, I definitely owe you a drink!

Cheers,

Liz

[former_member282021]

Thanks Harald - that was great information and quick responses.

[Former Member]

Hi Liz,

Can you share that document for technical integration with GTS ( we are using point to point) with us, because we are quite struggling with getting the inbound message in GTS.

Thanks in advance

Regds

Frank

[former_member203691]

Hi Frank,

We used one of the configuration guides for most of it. The section about  "System Communication".

https://websmp204.sap-ag.de/~sapidb/011000358700001004102012E/Compliance_Mgmt.pdf

Our Basis admin used the screenshots that Harold kindly provided in the comments here to guide us through the SOA Manager set up (it is not in the guide).  For some reason you need that even if you aren't doing point to point with GTS (we are not doing point to point).  We've never needed that SOA Manager piece for SAP to SAP calls before. The call from TM into GTS were working without it.  After Basis added the SOA Manager configuration the GTS -> TM leg of it started working.

As for the PI admin part, I just imported SAP SLL-LEG 10.1 into the ESR (we already had SAPTM 1.10 and SAPTM IC 1.10 in the ESR).  After that all I had to do was import the TM_GTSExportDeclarationIntegration scenario into the Integration Directory using the Model Configurator.

Liz

[Former Member]

Has anybody any ideas?

Thanks and Best Regards

H.

[markangelo_dihiansan]

Hello Harald,

Have you tried filling out the values in the Header Mapping under Receiver Agreement?

Regards,

Mark

[Former Member]

Hi Mark,

Thanks for your answer. I filled out the header mapping fields for the sender and receiver system, however no success. What I didn't mention in the beginning is, that the messages with the "Couldn't retrieve inbound binding for the given P/S/A values" error are not visible in the PI message monitor. So I guess the messages sent from the SAP GTS system are not even reaching the AEX? Correct?

Best Regards

H.

[ambrish_mishra]

Hi Herald,

aah... so the message has not even reached PI...

please run a few customary checks in GTS system. Do a connection test in sproxy and SLDCHECK as well.

Check if the RFC destination type H to PI system is working....I think you will find the RC in GTS.

Cheers,

Ambrish

[Former Member]

Hi Ambrish,

Please read my first comment carefully: When I do the test via test proxy transaction in SE80, the message goes via PI through to SAP TM. ONLY if the message is triggered inside the business transaction which calls the interface TradeComplianceCheckSUITEConfirmation_Out the message crashes with the error. I assume that this could be to a misconfiguration in transaction SOAMANAGER, but I am not sure.

SLDCHECK is green. RFC destinations to AEX are up and running (connection test successful with HTTP 200).

Best Regards

H.

[ambrish_mishra]

Hi Herald,

I did not realize that you have tested successfully from SE80 and it is failing through actual business transaction. Sometimes you don't read the initial post and respond. Sorry for that!

From my experience with one of the SRM PO change/create interfaces which uses standard proxy triggered through transactions and we followed a cookbook to configure the process flow to send the proxy message to PI.

You are following a Master guide at your end already so probably you need to check if some configuration is missing at the business transaction level. SOAMANAGER would have connection settings from GTS to other systems which should be fine.

Hope it helps!

Ambrish

[markangelo_dihiansan]

Hello Harald,

com.sap.aii.af.service.cpa.CPAObjectNotFoundException: Couldn't retrieve inbound binding for the given P/S/A values: FP=;TP=;FS=<Customer's From Service>;TS=<Customer's To Service>;AN=TradeComplianceCheckSUITEConfirmation_Out;ANS=http://sap.com/xi/GTS/Global2;

It looks like interface determination is failing. Are you using ICO?

Regards,

Mark

[Former Member]

Hi Mark,

Yes we use ICO. However SAP support already checked all the settings of the ICO and that seems to be ok. Also manual testing of the proxies (via proxy test tool) is working and the messages are sent via PI, only during testing as part of the mentioned integration scenario (via business transactions) is failing.

Best Regards

H.

[ambrish_mishra]

Try a delta cache refresh and a full cache refresh if it is a test system.

Hope it helps!

Ambrish

[Former Member]

Hi Ambrish,

I already did a delta and full PI CPA cache refresh. No sucess.

Best Regards

H.