cancel
Showing results for 
Search instead for 
Did you mean: 

403!!-Outbound Communication to S4 On-Premise(OData) from BTP ABAP Environment-Free tier(Steampunk)

vishnucta
Active Participant
781

Team,
I am following below blogs for Outbound communication to access OData service in S4 on-premise. Ended up with "403" forbidden error.

(Additional step 3 of adding SAP_COM_0200 into a communication Arrangement. SAP_COM_0200 is not available in steampunk instance)
https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/outbound-communication-from-c...

in Step 4 of below tutorial(S4 public is used in tutorial),
https://developers.sap.com/tutorials/abap-environment-business-partner-outbound-call.html#0664684a-3...

I have added my virtual host and made 'Cloud Connector' switch on with an optional SCC ID given.

vishnucta_0-1718372958997.png

But after all this configuration , the check fails in Communication Arrangement

 

vishnucta_2-1718373057174.png

Error as follows:

vishnucta_3-1718373154435.png

Can anyone point our what i am missing!!!

Below my SAP CC config

vishnucta_0-1718374384324.png

Communication scenario:

vishnucta_1-1718374463484.png

CC Log: Request getting logged in Cloud Connector

vishnucta_0-1718615842508.png

 



Best regards,
Vishnu

@Mani_P_S   @ariannamussobarcucci  @FrankJentsch  Any help appreciated. @merveyalcin 







julieplummer20
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi Vishnucta, By “Steampunk” instance, do you mean a Trial instance? If so, you need a license. Best wishes, Julie Plummer.
vishnucta
Active Participant
0 Kudos

Hi @julieplummer20 @, Thanks for the response. We have a free tier instance.if I am not wrong I guess it's partner tenant. 

ABAP Platform version 2405

@julieplummer20 can you please confirm or guide me to a document/Note regarding outbound communication to Onpremise Http?

Hope Free tier can do outbound communication.

vishnucta
Active Participant
0 Kudos
@thomaswiegand any new inputs?? 🙂
View Entire Topic
thomaswiegand
Advisor
Advisor

Hi Vishnu,

as the requests reach your Cloud Connector: Do they also reach your backend system? Any additional logging available there?

The 403 coming from the backend system would usually indicate that the user does not have sufficient authorisations to access the service (authentication worked, otherwise 401 would be returned).

Are you able to directly call the service (e.g. from postman / browser) with the user at the backend system?

Best Regards,

Thomas

 

vishnucta
Active Participant
0 Kudos

Hello @thomaswiegand , Thanks a million for the response.

The user "vvishnu" have the enough auth to execute and query information in Backend system.

thomaswiegand
Advisor
Advisor
0 Kudos
Hi Vishnu,
thomaswiegand
Advisor
Advisor
0 Kudos
Hi Vishnu, do the requests reach the backend? E.g. do you see any entries in SU53 for the user, which would indicate further authorisation issues? I would also suggest to set the principal type to None in your SCC configuration as you are not using principal propagation, but technical authentication. Best Regards, Thomas
vishnucta
Active Participant
0 Kudos

@thomaswiegandthere is not SU53 entries for that user and even i disable principal propagation. Still the same issue.

Bild (1).png

vishnucta_0-1718624154768.png

Even after this the error is same. "403" 

 

thomaswiegand
Advisor
Advisor
0 Kudos
Reiterating 🙂 Do you have any indication whether the requests reach the backend (and are not blocked in SCC already)?
vishnucta
Active Participant
0 Kudos
@thomaswiegand the SCC logs have no such information that its getting blocked
vishnucta
Active Participant
0 Kudos

@thomaswiegandEven the traces shows the request coming to the backend system

vishnucta_0-1718634072872.png

 

thomaswiegand
Advisor
Advisor
0 Kudos
And in the response in the backend you also see the 403 HTTP Code or is the call successful from backend perspective?
vishnucta
Active Participant
0 Kudos

@thomaswiegandIts successful from BE perspective

vishnucta_0-1718635827706.png

 

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos

Activate the ICM trace in transaction SICM. It will show you, why the backend replies with 403.

Also helpful might be to activate the Payload Trace in the SCC. Then you can take a look at the HTTP Body of the 403 response, which might give further error details.

vishnucta
Active Participant
0 Kudos

Hello @Ulrich_Schmidt , thanks for your response.
I have checked the SCC log and no entries corresponds to 403.

There is a temporary redirect 307 but no 403 in response.

vishnucta_0-1718702375255.pngvishnucta_1-1718702461504.pngvishnucta_2-1718702504296.png

vishnucta_0-1718702994967.png

 

SMICM:

vishnucta_3-1718702548349.pngvishnucta_4-1718702642413.png

My question would be if 403 is returned by backend then OData trace should also reflect the same ? Please correct me if i am wrong.
Gateway Trace:

vishnucta_0-1718703326514.png

 


Regards,
Vishnu



Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos
You checked the wrong log: the "http_access.log" records only UI requests from the browser to port 8443, it has nothing to do with http requests to backend systems. As I said, these can be seen only in the Payload Trace. (Files traffic_trace_xxxx.trc.)
vishnucta
Active Participant
0 Kudos

@Ulrich_Schmidt      First screenshot in the above list of screens is from "traffic_trace_xxxx.trc".

Let me attach the same again.

vishnucta_1-1718732634649.png

 

 

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos

Ah, it was so small, my old eyes couldn't recognize it...

Ok, then I have an idea: the original request runs into a 307. The HTTP client on Cloud side then tries to follow that redirect, and this follow-up request then runs into the 403, before reaching the backend (or even the SCC).

Question is: the URL in the "location" header, is that on a different host, or same host and only the path is different? (Unfortunately some parts are blotted out in your screenshot, so I can't see it.)

If it's a different host, then one possibility would be: in the SCC, you have created a hostname mapping only for the first host, but not for the second. (Or if the scenario works with destinations, a problem could also be, that only a destination for the first host exists in the Cockpit, but not for the second host.) In that case you would see an error message in the SCC's "Audit Log", like "Denying access to system ...."

If only the path is different, one problem could be, that in the "Access Control" settings for the host you have not allowed the second path. Again there would be an error in the Audit Log.

If there is no entry in the Audit Log, this means the 403 for the second request must be coming from a component, before the request reaches the SCC. In that case we would need to check some cloud-side logs in more detail. (I hope, the HTTP client in the Cloud App also traces some low-level details?!)

vishnucta
Active Participant
0 Kudos

@Ulrich_SchmidtThanks a lot for spending some time helping me . Coming to your question i would be great if you can tell me which "location" header you are referring to. There are url configured in "outbound communication" and in "communication Arrangement" ?

Are you referring to this ? when you mean "location" header

vishnucta_0-1718742872774.png

 

 

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos
You can see the "location" header at the very end of the Response data for the 307 Temporary Redirect. The HTTP client (in the cloud) will trigger a second HTTP request to exactly the URL specified in this field.
vishnucta
Active Participant
0 Kudos

@Ulrich_SchmidtThe URL in "location" header is virtual/proxy url that is used in the SAP CC configuration

vishnucta_0-1718743514166.pngvishnucta_1-1718743572613.png

vishnucta_0-1718743717323.png

Access Path:

vishnucta_0-1718744554653.png

 

In Addition to above:

2nd request goes without a port and 1st request is to port 443. I have highligted in below screenshot.


vishnucta_0-1718744101968.png

And in Audit i can see "Deny Access...."

vishnucta_1-1718744162085.png

Is that the 2nd request from cloud http client is picking up default port 80????

I am expecting it to pick up 443 since that what coming from Communication System.

vishnucta_0-1718744971337.png

Is the UI hostname i gave in above screenshot creating problem? As per my understanding UI hostname is an optional field and it gets defaulted anyway with normal host.

 

 

 

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert

That's it, I have seen that problem before. 😞

Somewhere along the path back, the port 443 gets omitted (because it is the "default port" for the https protocol, so why bother mentioning it...). Then at some other point, the information about "https" gets lost, and the client then thinks its "http". (Probably in the Cockpit/destination, which can be defined only with "http", because the tunnel is already SSL-encrypted?!)

Now the "default port" of the http protocol is 80, so the client (thinking the redirect is for http), "re-adds" the port 80... And the SCC does not have a mapping for port 80, so it denies the request with a 403 error. (So in fact, the statement in the beginning "the SCC logs have no such information that its getting blocked" was wrong, wasn't it?)

Unfortunately, I don't remember the solution. Some component along the line HTTP Client --> Connectivity Agent(Proxy) --> SCC --> Backend needs to be fixed.

But if you want to have a quick&dirty fix, the following workaround fixes the problem: in the SCC, create a second host-mapping, where everything is the same, only the "virtual port" is set to 80. (Real port needs to be the same 443 and protocol "HTTPS".) Then the second redirected request should go through fine as well.

The only thing I don't quite understand yet: the original URL and the URL in the location header look identical (unless I didn't read the screenshots correctly). Why did the backend re-direct the request "to itself"?? That doesn't make sense?! (However, if there is a small difference between original and re-directed request, you could also change the application/HTTP client to use the re-directed URL in the first place, instead of the original one. Then you safe one roundtrip (better performance!) and don't run into the problem with the default ports getting confused.

vishnucta
Active Participant
0 Kudos

@Ulrich_SchmidtYou are absolutely right , i missed the entry in Audit. 😞 😥

The quick/dirty fix will work but i have configured my Communication System to talk to backend via Cloud Connector (I have switched it off while creating the system)

vishnucta_0-1718784386450.png

My understanding was it wont use the destination service rather route the request via virtual host mentioned in SAP CC Access Control. Cockpit/Destination , as you mentioned in your reply have "http" but will it be relevant since i have switched off in Communcation System.

You mentioned "Some component along the line HTTP Client --> Connectivity Agent(Proxy) --> SCC --> Backend needs to be fixed.
Are you talking about something in SCC Settings or Server related settings in S4 Backend system? Do we have some Apps or  Eclipse ADT steps to configure something at ABAP Cloud in BTP ?

Only BTP configuration that we do is Communication system/Arrangement. Is there anything else in ABAP Cockpit i can leverage for trouble shooting this redirect?

Thanks a lot for your response .

 

 

 

vishnucta
Active Participant
@thomaswiegand Thanks a lot for your suggestions @Ulrich_Schmidt Thanks a lot for guiding me in the right direction and your solution.
Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos
To find out, where exactly the accidental switch from https/443 to http/80 is happening, we would need to look at the logs of the Connectivity Agent (and perhaps also the logs of the HTTP Client used by the application).