Destinations (SAP BTP)

An application asks for a destination by name and receives everything it needs to make the call:

1. An administrator creates the destination, for example S4_ALDER, in the subaccount or on a Destination service instance.
2. The application, bound to a Destination service instance, requests S4_ALDER at runtime.
3. The Destination service first searches the destinations of that service instance and, if it finds none, the subaccount.
4. The service returns the configuration and, for many authentication types, the tokens the call needs.
5. For proxy type OnPremise, the call travels through the Connectivity service and SAP Cloud Connector; for proxy type Internet, it goes out directly.

Because the application only knows the name, moving from test to production means changing the destination, not the code. SAP BTP destinations turn connection details into configuration that operations teams own.

Which additional properties a destination needs depends on the consuming tool and scenario; SAP Business Application Studio, for example, lists a destination only when WebIDEEnabled is set, and WebIDEUsage tells it what the destination is for. An SAP BTP destination is therefore a small contract between the platform and each consuming tool.

Strengths

• Credentials out of code: secrets and certificates stay in the platform, and the cockpit can check the connection.
• One pattern for many targets: internet APIs, on-premise systems and SAP BTP service instances use the same object.
• Identity options: principal propagation and OAuth flows let the backend see the real user instead of a shared account.

Where they stop

• Configuration, not integration. A destination does not map data, retry calls or monitor message flow.
• Per subaccount. Each subaccount needs its own destinations. The cockpit can export a destination to a file and import it elsewhere, and the MTA descriptor or the Destination service REST API can create them, but landscapes with many subaccounts still multiply maintenance.
• Backend rights still apply. A working destination proves connectivity, not that the user may run the service.

SAP BTP destinations standardize how apps connect, while authorization and process logic remain elsewhere.

1. Using the real hostname for on-premise targets. The URL must carry the virtual host and port defined in SAP Cloud Connector, exactly as mapped.
2. Forgetting the location ID. With several connectors in the subaccount, a destination without the right location ID goes to the wrong network.
3. Shadowed names. A destination on a service instance with the same name as a subaccount destination wins the lookup, which confuses anyone who edits only the subaccount copy.
4. Technical users everywhere. Basic authentication with one shared user hides who did what in the backend; principal propagation or user-based OAuth keeps the audit trail.
5. Copying properties blindly. Flags such as HTML5.DynamicDestination widen access to any logged-in user and should be set only when a scenario needs them.

Most destination incidents trace back to a naming or mapping mismatch that the connection check would have exposed.