BTP & Integrationintermediate

BTP SAP Build Part 3: Integration — Destinations, APIs and Identity

Key takeaway

Connect SAP Build tools to systems: destinations with the additional properties SAP Build needs, OData/REST integrations, on-premise access through Cloud Connector, user identity with principal propagation or SAML bearer, and API-first patterns via API Management.

Explanation

📌 KEY POINTS
✅ SAP Build tools consume back ends through BTP destinations (with tool-specific additional properties).
✅ On-premise systems are reached via Cloud Connector (proxy type OnPremise).
✅ User-context access needs principal propagation (on-premise) or SAML bearer/token exchange (cloud).
✅ Prefer stable APIs (released S/4 APIs, API Management proxies) over custom endpoints.
⚠️ A destination with an admin technical user lets every app user act with admin rights.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 chose the approach. Now integration.

━━━━━━━━━━━━━━━━━━━━
▶ 1. DESTINATIONS

Properties required by Build tools.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ON-PREMISE

Cloud Connector.

━━━━━━━━━━━━━━━━━━━━
▶ 3. IDENTITY

Technical vs user propagation.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 4. APIS\n• Released APIs; APIM.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TESTING

Check connection; real calls.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Create a destination with required properties.
Use it in Build Apps or an action project.
Test with a user and check back-end authorization.

✅ CHECKPOINT: back end applies the real user's authorizations.

Code example

ABAP Code

===== DESTINATION (example) =====Name: S4H_SALES_API | URL: https://s4h-virtual:443 | Proxy: OnPremise | Authentication: PrincipalPropagationAdditional properties (examples; verify per tool): HTML5.DynamicDestination=true | sap-client=100 | usage flags for SAP Build tools ===== PATTERN =====Build Apps / Process Automation → destination → (API Management proxy) → released S/4 API

Real project scenario

A Build Apps project used a destination with an admin user; field users could see all sales orders. Switching to principal propagation made S/4 apply each user's authorizations.

Common mistakes

Admin technical users.
Missing destination properties.
Custom endpoints over released APIs.
One destination for all.
No real-user tests.

Best practices

User propagation where needed.
Correct properties.
Released APIs.
Destinations per purpose.
Test with real roles.

Interview angle

Questions: "How does SAP Build connect to S/4?", "How is user identity preserved?", "Why use released APIs?"
Strong answer: destinations, on-prem, identity, APIs, testing.

Practice this lesson

Quick check

1. How do SAP Build tools typically connect to S/4HANA on-premise?

2. Field users of a Build app see all sales orders because the destination uses an admin user. What fixes this?

3. Which practice is risky in SAP Build integration?

Interview questions

1. Explain the purpose, end-to-end flow and key design decisions in "SAP Build integration with destinations, APIs and identity".

Answer it in your own words first, then compare.

2. A project encounters a problem while implementing "SAP Build integration with destinations, APIs and identity". What evidence would you check before changing configuration, code or architecture?