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

Lesson 2 of 5

Destinations

10 min

Listen to this lesson

0:00 / 15:59

A destination is a named set of connection details: where the target is, how to get there and how to authenticate. Applications refer to it by name and the destination service supplies the rest at runtime. That separation is what lets the same build of the fleet app run in development, test and production: the code asks for CMC_S4HANA, and each subaccount answers with its own target.

What a destination contains

PropertyMeaningFleet app value in cmc-ext-test
NameUnique name the app asks forCMC_S4HANA
TypeHTTP, RFC, LDAP, MAIL or TCPHTTP
URLFor OnPremise: the virtual URL exposed in the Cloud Connectorhttps://s4-test.cmc.virtual:443
ProxyTypeInternet, OnPremise or PrivateLinkOnPremise
AuthenticationHow the call authenticates (lesson 4)BasicAuthentication with the CMQ communication user
Location ID (CloudConnectorLocationId)Which Cloud Connector to use when several serve one subaccountEmpty (one Cloud Connector)
Additional propertiesExtra settings, such as sap-client or URL.headers. and URL.queries. entriessap-client = 100

Destination properties and the values Contoso uses in the test subaccount. Virtual host names are Contoso's own.

Destinations can be defined at subaccount level, visible to all apps in the subaccount, or at service instance level, attached to one destination service instance and so to the apps bound to it. Contoso keeps shared targets such as CMC_S4HANA at subaccount level and app-specific ones at instance level. Administrators maintain them in the SAP BTP cockpit under Connectivity > Destinations, where a destination can be created from scratch or from a template, edited, duplicated, exported and imported. Destinations can also be created from the MTA deployment descriptor or a configuration file when a service instance is created, which keeps them under version control.

A destination lives either at subaccount level, visible to every app there, or at service instance level, visible only to apps bound to that destination service instance.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203
  1. Request in the appThe CAP remote service needs sales orders and names destination CMC_S4HANA
  2. Destination lookupThe app's bound destination service returns the configuration of the current subaccount
  3. AuthenticationCredentials, or a token the destination service fetched, are added to the request
  4. RoutingOnPremise: through the connectivity proxy into the Cloud Connector tunnel; Internet: straight out
  5. TargetThe virtual host is mapped to the internal host of CMQ; the API answers
What happens when an app uses a destination at runtime.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203

Check Connection, and what it does not prove

The Destinations editor has a Check Connection button. For Internet destinations, SAP's documentation says the check fails only on HTTP status 500 or above; every status below 500 counts as success. For OnPremise destinations, it reports specific messages, such as the back end not being in the Cloud Connector's list of system mappings, the resource not being accessible, or the back end not reachable from the Cloud Connector. The check only proves that a connection is possible; it does not prove that the target service works or that the credentials are right. A destination that returns 401 Unauthorized can pass the check.

Check Connection proves a connection is possible, not that the credentials or the service work: a 401 can pass it.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203

Good practices

  • Same name in every stage. CMC_S4HANA exists in dev, test and prod; only the values differ.
  • No credentials in code or in the MTA. Secrets live in destinations or are fetched as tokens.
  • One owner per destination. Name the responsible team in the description so changes are not made blindly.
  • Export before you change. Exported destinations (without secrets) are the before-and-after evidence for a change.
  • Compare stages before testing. A destination list per subaccount, compared side by side, catches a test subaccount pointing at production.
SubaccountCMC_S4HANA URL (virtual)sap-clientCredentials
cmc-ext-devhttps://s4-dev.cmc.virtual:443Development client of CMDCMD communication user
cmc-ext-testhttps://s4-test.cmc.virtual:443100CMQ communication user
cmc-ext-prodhttps://s4-prod.cmc.virtual:443Production client of CMPCMP communication user
One destination name, three stage-specific configurations.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-203

What would you do?

A tester reports that Check Connection on CMC_S4HANA in cmc-ext-test shows success, yet the fleet app shows "401 Unauthorized" when reading orders. What does that tell Priya?

Key points
  • A destination holds name, type, URL, proxy type, authentication and additional properties.
  • Destinations exist at subaccount or service instance level and can be created in the cockpit or from deployment files.
  • Keep one name across stages with stage-specific values; never put secrets in code.
  • Check Connection proves reachability, not credentials: below 500 counts as success.
  • Export and compare destination lists per stage as evidence before testing and go-live.

Check your understanding · not graded

Lesson check

  1. 1. What does an OnPremise destination's URL contain?

  2. 2. When does Check Connection report failure for an Internet destination?

  3. 3. Why keep the same destination name in dev, test and production?

  4. 4. Which property selects a specific Cloud Connector when several serve one subaccount?