BTP Destinations Part 1: What the Destination Service Does
The destination service stores how to reach remote systems — URL, authentication and proxy details — so apps, integration flows and SAP Build tools can connect without hard-coded settings. Learn destination levels (subaccount vs service instance), types (HTTP, RFC, MAIL, LDAP), and how consumers read them.
What this complete series covers
Learn Destinations in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.
- Who it is for
- Best for SAP consultants, developers, and learners who want a practical understanding of Destinations.
- Prerequisites
- A basic understanding of SAP BTP helps. Hands-on steps may require a BTP subaccount and access to the relevant Integration Suite or BTP service.
- Final outcome
- By the end, you should be able to explain Destinations clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.
- Part 1: BTP Destinations Part 1: What the Destination Service Does
Understand what a BTP Destination is, why it exists as an abstraction between application code and target systems, and how its core properties are structured and resolved at runtime.
- Part 2: BTP Destinations Part 2: Proxy Types, Authentication Methods and Cloud Connector
Learn how to configure destinations correctly for Internet and OnPremise proxy types, choose the right authentication method for a given target system, and understand how Cloud Con
- Part 3: BTP Destinations Part 3: Choosing the Right Authentication and Proxy Type
A practical guide to selecting and configuring authentication types (NoAuthentication, BasicAuthentication, OAuth2, PrincipalPropagation, ClientCertificateAuthentication) and proxy
System and release assumptions: SAP BTP services evolve regularly. Capability names, screens, and setup steps can differ by region, entitlement, and tenant version; the core design principles remain the same.
Explanation
📌 KEY POINTS
✅ Destinations centralize connection data (URL, auth, proxy) outside the application code.
✅ They exist at subaccount level (shared) or at destination service instance level (app-specific).
✅ Types: HTTP (most common), RFC, MAIL, LDAP.
✅ Consumers: app router, SAP Cloud SDK/CAP, SAP Build, HTML5 apps, integration tools.
⚠️ A same-named destination at instance level overrides the subaccount one — know the lookup order.
━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS
Part 1: What the destination service does
Part 2: Proxy types, authentication and Cloud Connector
Part 3: Choosing the right authentication
━━━━━━━━━━━━━━━━━━━━
▶ 1. PURPOSE
- Decouple connection data from code.
━━━━━━━━━━━━━━━━━━━━
▶ 2. LEVELS
- Subaccount vs service instance.
━━━━━━━━━━━━━━━━━━━━
▶ 3. TYPES
- HTTP, RFC, MAIL, LDAP.
━━━━━━━━━━━━━━━━━━━━
▶ 4. CONSUMERS
- App router routes, CAP/Cloud SDK, SAP Build.
━━━━━━━━━━━━━━━━━━━━
▶ 5. OPERATIONS
- Check connection, certificates, transport.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Create a subaccount-level HTTP destination.
- Consume it in an app router route.
- Check connection.
✅ CHECKPOINT: the app reaches the target via destination name only.
Code example
===== xs-app.json route (app router) ====={ "source": "^/s4/(.*)$", "target": "$1", "destination": "S4H_ODATA", "authenticationType": "xsuaa" } ===== CAP (package.json excerpt) ====="cds": { "requires": { "API_BUSINESS_PARTNER": { "kind": "odata-v2", "credentials": { "destination": "S4H_ODATA" } } } }Real project scenario
A team had the same destination name at subaccount and instance level pointing to different S/4 systems; test calls hit production. Renaming and removing duplicates fixed it.
Common mistakes
- Hard-coded URLs.
- Duplicate names.
- Secrets in code.
- Wrong level.
- No check connection.
Best practices
- Central destinations.
- Unique names.
- Store secrets in destinations/certificates.
- Choose level deliberately.
- Test connections.
Interview angle
Questions: "What is the destination service?", "Subaccount vs instance level?", "How do apps consume destinations?"
Strong answer: purpose, levels, types, consumers, operations.
Practice this lesson
Quick check
1. A destination with the same name is defined both at the subaccount level and at the level of a specific application/service instance in the BTP cockpit. When an application looks up this destination by name at runtime, which configuration takes precedence?
2. Which SAP BTP service is primarily responsible for storing and providing runtime lookup of destination configuration data (such as URL, authentication type, and additional properties) to consuming applications?
3. An SAPUI5 application deployed in the HTML5 Application Repository needs to route calls through the SAP Approuter to a backend using a destination. Which additional property must be set on that destination to expose it to the Approuter for this purpose?
Interview questions
1. What are the core concepts of Destinations, and how would you explain them clearly in an SAP interview?
Answer it in your own words first, then compare.
2. Test calls from a BTP app hit a production S/4HANA system. Explain how destinations are resolved and how you'd fix this.
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.