Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

Connectivity paths from SAP BTP

9 min

Listen to this lesson

0:00 / 7:53

Contoso's fleet order status app runs in Cloud Foundry in the subaccounts cmc-ext-dev, cmc-ext-test and cmc-ext-prod. It needs sales order data from SAP S/4HANA (CMD, CMQ and CMP, running in SAP's private cloud under RISE with SAP), and a newer feature reads shipment tracking from Lakeside Components' public REST API. Those two targets sit in very different places, and SAP BTP reaches them in different ways. This lesson maps the paths before the following lessons go into each part.

Three proxy types

Every HTTP destination has a proxy type, set in the property ProxyType. SAP's connectivity documentation lists three. Internet, the default, connects to services reachable over the internet, such as a public REST API or a cloud application. OnPremise connects to a back end inside a private network through the Cloud Connector; SAP notes that the on-premise use cases also apply to virtual private cloud environments, which is how a RISE private cloud is usually reached. PrivateLink lets selected SAP BTP services connect privately to services in your own infrastructure provider accounts through SAP Private Link service.

Application (CAP, SAP Cloud SDK, SAP Build)Asks for a destination by name; never stores URLs or passwords itself
Destination serviceHolds the destination configuration per subaccount or service instance and returns it, including tokens it fetches for OAuth types
Connectivity serviceFor OnPremise destinations: a proxy that routes requests into the tunnel of the right Cloud Connector
Cloud ConnectorAgent in the private network: holds an outbound tunnel to the subaccount and forwards only allowed requests
Back-end systemSAP S/4HANA or another system, which authenticates and authorizes the call
The components on the OnPremise path. Internet destinations skip the connectivity service and Cloud Connector.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203

Why the Cloud Connector path matters

SAP describes the Cloud Connector as a link between SAP BTP applications and on-premise systems that runs as an agent in the secured network and acts as a reverse invoke proxy. The Cloud Connector opens the connection outward to SAP BTP, so no inbound firewall port has to be opened for cloud access. Administrators then decide exactly which systems, and which URL paths on them, are exposed. It also supports RFC as well as HTTP, can propagate the cloud user's identity to the back end, recovers broken connections, writes audit logs and can run as a high-availability pair.

The Cloud Connector opens the tunnel outward first, so requests from SAP BTP reach CMQ without any inbound firewall opening.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203
  1. Is the target reachable over the public internet (a SaaS or public API)?Yes → ProxyType Internet · No → continue
  2. Is it in a private network or private cloud reachable by a Cloud Connector?Yes → ProxyType OnPremise through the Cloud Connector · No → continue
  3. Is it a service in your own infrastructure provider account that SAP Private Link supports?Yes → ProxyType PrivateLink · No → involve network and security architects
Choosing the proxy type for a destination.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203
Contoso connectionTargetProxy typeNotes
Fleet app to sales order API (test)CMQ client 100OnPremiseThrough the Cloud Connector serving the RISE landscape
Fleet app to sales order API (production)CMPOnPremiseSame destination name, different subaccount and target
Fleet app to supplier shipment trackingLakeside Components public REST APIInternetOAuth client credentials issued by the supplier
Fleet app to its own SAP HANA Cloud databaseService bindingNot a destinationBound service credentials, not the destination service

Contoso's fleet app connections and how each is reached.

Not every connection is a destination. Services the app consumes in its own subaccount, such as its SAP HANA Cloud database, reach the app as service bindings with their own credentials. Destinations are for targets the app does not own: other systems, other subaccounts and external APIs. Keeping that distinction clear saves time in troubleshooting, because the two fail in different places.

Destinations are for targets the app does not own; its own SAP HANA Cloud database arrives as a service binding, so the two fail in different places.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203

What would you do?

A developer configures the fleet app's sales order destination with ProxyType Internet and the internal host name of CMQ. Calls time out. What is the most likely cause and fix?

Key points
  • Proxy types: Internet (default), OnPremise through the Cloud Connector, and PrivateLink for selected services.
  • Apps ask for destinations by name; the destination service holds the configuration.
  • OnPremise calls go through the connectivity service and the Cloud Connector's outbound tunnel.
  • The Cloud Connector exposes only systems and paths you allow, without inbound firewall openings.
  • Services bound to the app are not destinations; under RISE, agree the connectivity setup with SAP.

Check your understanding · not graded

Lesson check

  1. 1. Which proxy type does a destination to a private SAP S/4HANA system use?

  2. 2. Why does the Cloud Connector not require an inbound firewall opening?

  3. 3. What is the default value of a destination's ProxyType?

  4. 4. How does the fleet app usually reach its own SAP HANA Cloud database?