Destinations Fundamentals: Purpose, Anatomy and Runtime Role

Explanation

A destination in SAP BTP is a named, centrally managed configuration object that describes how an application or service should connect to a target system - it captures the URL, proxy type, authentication method, and additional properties needed to reach that system, without hardcoding any of this information into application code. This matters because in a cloud landscape you typically have many consumers (custom UI5 apps, CAP services, Integration Suite flows, SAP Build process automations) that all need to reach a mix of on-premise ERP systems, SuccessFactors, Ariba, third-party REST APIs, and other BTP services. Without destinations, every consumer would need its own hardcoded connection logic, credentials, and URLs, making rotation, environment promotion (dev to test to prod), and auditing extremely painful. Structurally, a destination has a Name (the logical identifier code references), a URL (the target endpoint), a Proxy Type (Internet for publicly reachable systems, OnPremise for systems reached via Cloud Connector), an Authentication type (NoAuthentication, BasicAuthentication, OAuth2ClientCredentials, OAuth2SAMLBearerAssertion, PrincipalPropagation, ClientCertificateAuthentication, and others depending on scenario), and optional additional properties such as HTML5.DynamicDestination, WebIDIEnabled flags, or custom key-value pairs that specific SDKs or SAPUI5 runtime consume (for example proxying rules in an approuter). Destinations can be defined at two main levels: subaccount level (visible to all applications in that subaccount, managed via BTP cockpit under Connectivity > Destinations) and application/instance level (scoped to a specific app binding via a Destination service instance, often provisioned through mta.yaml or cf create-service). At runtime, when application code calls the Destination service client library (or an approuter proxies a request configured with a destination name), the Destination service resolves the destination definition, retrieves any required credentials from a connected credential store or the destination's own configuration, and returns an effective connection descriptor - including, for OnPremise proxy type, routing information so the request is tunneled correctly through the Cloud Connector to the customer's internal network. It is important to distinguish destinations from a generic HTTP client configuration: destinations are looked up by name at runtime, meaning the actual URL and credentials can change without redeploying application code - only the destination configuration changes. This indirection is central to BTP's operational model and is why almost every SAP-delivered service (Integration Suite adapters, Business Application Studio wizards, Workflow, Event Mesh consumers) expects you to reference a destination name rather than an inline URL. For beginners, the key mental model is: application code asks 'give me destination X', the Destination service answers with 'here is the resolved URL, auth, and proxy details for X in this environment', and the application uses that to make the actual call. Understanding this separation is foundational before moving into proxy types, authentication flows, and Cloud Connector integration in later lessons.

Code example

// Example: consuming a destination from a Node.js application using the SAP Cloud SDKconst { executeHttpRequest } = require('@sap-cloud-sdk/http-client'); async function getSalesOrders() {  // 'S4HANA_SALES_API' is the destination NAME configured in BTP cockpit  // The SDK resolves URL, auth type, and credentials at runtime via the Destination service  const response = await executeHttpRequest(    { destinationName: 'S4HANA_SALES_API' },    {      method: 'get',      url: '/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder',      params: { '$top': 10 }    }  );  return response.data;} // No hardcoded URL, no hardcoded credentials in application code.// Changing environments (dev -> test -> prod) only requires// re-pointing or re-creating the destination, not redeploying code.

Real project scenario

A project team builds a custom Fiori/UI5 approval app on Cloud Foundry that needs to read purchase order data from an on-premise S/4HANA system and also call a public SAP Ariba REST API. During the design workshop, the architect insists on defining two separate destinations - one OnPremise proxy type routed through Cloud Connector for S/4HANA, and one Internet proxy type with OAuth2ClientCredentials for Ariba - rather than letting developers hardcode base URLs in the UI5 manifest.json. This decision later pays off when the customer migrates from a test S/4HANA system to production: only the destination's URL and Cloud Connector virtual host mapping are updated in the subaccount, with zero code changes or redeployment required.

Common mistakes

• Hardcoding target system URLs or credentials directly in application code instead of referencing a destination by name. • Confusing subaccount-level destinations with application/instance-level destinations, leading to visibility or override issues. • Assuming a destination named similarly in dev and prod automatically has identical configuration - properties like proxy type or auth type can silently differ between landscapes. • Not realizing that changing a destination's properties can take effect immediately for running apps without a redeploy, which can cause unexpected behavior if not communicated to the team. • Treating destinations as a place to store arbitrary secrets unrelated to connectivity, cluttering configuration and complicating audits.

Best practices

• Always reference destinations by logical name in code; never embed target URLs or secrets directly. • Use consistent, environment-agnostic naming conventions for destination names (e.g., S4_SALES_API) so the same code works across dev/test/prod by only changing the destination's backend configuration. • Document each destination's purpose, owning team, and target system in a central connectivity register for the subaccount. • Prefer subaccount-level destinations for shared/common integrations and instance-level destinations for app-specific technical connections. • Review destination configurations as part of environment promotion checklists, since they are not automatically migrated by standard code deployment pipelines.

Interview angle

Interviewers often ask candidates to explain why BTP uses destinations instead of direct connection strings, and to describe the difference between subaccount-level and instance-level destinations. A strong answer highlights the decoupling of code from environment-specific connection details, the role of the Destination service as a runtime lookup, and awareness that destinations are one part of a broader connectivity model that also includes Cloud Connector and Connectivity service for OnPremise scenarios.