HTTP Destination fails to connect to OnPremise ABAP System

[TobiasMeinzer]

Hi Experts,

I would like to setup a http destination to connect an OnPremise ABAP system with HCP via Cloud Connector.

The following activities were done successfully:

1. Cloud Connector is successfully installed

2. http connection between Cloud Connector and OnPremise System works perfectly

3. Several odata resources are made accessible via access control

4. Cloud Connector is connected to HCP and in status "Connected"

5. The OnPremise system is shown as exposed backend system in HCP cockpit with status "Available"

However, when creating a new destination with exactley the same http connection information I always get "failed" result when using the connection test.

Also when creating a Fiori Application using template wizard I get an error message on this destination indicating wrong user credentials - which I would definetly deny as I have full authorization and the credentials are 100% correct.

Any thoughts?

Many thanks

Tobias

[Ulrich_Schmidt · Accepted solution]

Hi Tobias,

can you activate the "Payload Trace" for a moment and then trigger one call through the SCC by using that wizard? Then we can check, whether the call reaches the backend or breaks down somewhere before that point. Also: does anything get recorded in the SCC's Audit Log, when you set it to "full"?

Best Regards, Ulrich

[TobiasMeinzer · Accepted solution]

Hi Ulrich,

thanks for your reply.

I activated all kind of traces including payload but the only log entries I get are as follows:

2016-02-03 15:50:57,000#TRACE#com.sap.core.connectivity.tunnel.client.PingHandler#tunnelclient-23-1#          #Sending ping for tunnel "account:///x25669cbf"|

2016-02-03 15:50:57,000#DEBUG#io.netty.handler.codec.http.websocketx.WebSocket08FrameEncoder#tunnelclient-23-1#          #Encoding WebSocket Frame opCode=9 length=0|

2016-02-03 15:50:57,000#DEBUG#io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder#tunnelclient-23-1#          #Decoding WebSocket Frame opCode=10|

2016-02-03 15:50:57,000#DEBUG#io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder#tunnelclient-23-1#          #Decoding WebSocket Frame length=0|

2016-02-03 15:50:57,000#TRACE#com.sap.core.connectivity.tunnel.client.PingHandler#tunnelclient-23-1#          #Received pong for tunnel "account:///x25669cbf"|

Still I get "connection check failed" in HCP destination configuration...

Best regards

Tobias

[Ulrich_Schmidt · Accepted solution]

Hi Tobias,

1. Just to make sure: you are using the latest SCC version 2.7.1? Because the "Test Connection" button on HCP destination side requires this version. With earlier SCC versions you will get a warning message (which most people so far misinterpreted as an error message), even though the connection works ok. But anyway: if you also get an error when productively using the destination, then something must indeed be wrong.

2. "... but the only log entries I get are as follows"

You are aware of the fact that the payload trace is written into separate files, not into the ljs_trace.log? (Sometimes you need to press the "Refresh" button, before this new file becomes visible in the SCC UI.) If there is indeed no such file being created when sending a productive request to the destination, then it means the data is not reaching the SCC. As you are getting a response (401 or 403 I assume?), it means that the data must be sent somewhere else... I'm not really familiar with the Cloud side, but there must also be a facility where you can trace the HTTP traffic of the cloud app, so we can see, where the data is being sent to and where this strange authorization error response comes from.

(@Cloud experts: please help out on this one...!)

Best Regards, Ulrich

[TobiasMeinzer · Accepted solution]

Hi Ulrich,

thanks again for your quick reply.

Indeed the problem was that I was using SCC 2.7.0. I upgraded SCC to 2.7.1 and now I get a successfull connection test result in HCP cockpit.

Many thanks for your help!

Cheers

Tobias

[Ulrich_Schmidt · Accepted solution]

Hi Tobias,

ok, great!

And regarding the other problem with the authorization errors when trying "productive" HTTP calls? In this regard there should be no difference between 2.7.0 and 2.7.1 -- did you see anything about this problem in the traces now?

Best Regards, Ulrich