Intermittent 500/XHR Errors While Accessing Custom Node.js On-Prem Service via SAP BTP Cloud Connect

[#1]

Hi Experts,

I am facing an intermittent issue while accessing a custom on-premise Node.js service through SAP BTP Connectivity and SAP Cloud Connector. My setup consists of a React frontend running in SAP Business Application Studio (BAS), a Node.js backend deployed in BTP, and an on-premise Node.js server exposed through Cloud Connector using a destination with ProxyType=OnPremise. The architecture is basically: React Frontend → BTP Node.js Backend → Connectivity Service → Cloud Connector → On-Prem Node.js Server.

The strange part is that the issue only occurs with my custom Node.js service and not with SAP systems connected through the same Cloud Connector and destination setup. From the BTP backend, I am able to access the on-prem endpoint consistently without any issue using axios calls. However, when the frontend invokes the backend API, the request intermittently fails with XHR 500 errors or messages like “Access denied to resource … ensure to expose the resource correctly in your cloud connector.” Even more confusing is that the failure happens even when the on-prem endpoint only returns a very small plain-text response (~2 KB). So this does not appear to be related to payload size or backend load.

I have also recently configured a Cloud Connector Location ID and added the same Location ID in the BTP destination configuration. Has anyone faced similar intermittent issues specifically with non-SAP/custom Node.js servers while SAP systems continue to work normally through the same Cloud Connector setup?

Any guidance or troubleshooting suggestions would be greatly appreciated.

[Ulrich_Schmidt1]

The error message is clear:

“Access denied to resource … ensure to expose the resource correctly in your cloud connector.”

This is the SCC's standard error, when a client tries to execute a URL on a backend system, which is not allowed in the corresponding access control settings of the SCC. You said, the problem happens only "intermittently". Therefore I suggest two things to check:

1. You mentioned you have setup an additional SCC with a location ID. Perhaps both SCCs are still active, one has the necessary access control settings, and the other doesn't. For some reason, your client application "sometimes" uses the destination that goes via one SCC, and "sometimes" a destination that goes via the other.
2. Or perhaps the URLs called by the client sometimes look a bit different: some URLs match the allow list in the SCC's access control settings and some don't?!

In any case, whenever you see an access denied error on client side, there should be a matching entry in the SCC's "Audit Log", which shows the exact URL being called, so you can then double-check it with the currently defined access control settings. Also, if there is no Audit Log entry at the time of the error, you know, that another SCC must have received the HTTP request.