Did you know SAP BTP Destination Fragments and how to consume to integrate ?

Estimated read time 8 min read

In the era of hyper-automation and low-code/no-code platforms, seamless connectivity between services is critical. SAP BTP’s Destination Fragments provide a standardized, reusable approach to managing API endpoints, security configurations, and network policies.

This blog explores how developers can consume Destination Fragments in SAP Build Apps, Process Automation, and other development contexts to accelerate integration, enhance security, and streamline governance.

1. What Are Destination Fragments?

Destination Fragments are reusable configuration components in SAP BTP that define:

Target endpoints (e.g., SAP S/4HANA, SAP SuccessFactors, or external APIs).Authentication methods (OAuth, Basic Auth, Client Certificates).Network policies (e.g., CORS, whitelisting).Custom headers or query parameters.

Fragments are consumed by Destinations, which act as unified gateways for applications to access backend systems securely.

2. Why Consume Destination Fragments?

Reusability: Define once, use across multiple applications.Security Centralization: Enforce consistent authentication and encryption.Governance: Ensure compliance with enterprise policies.Simplicity: Eliminate manual configuration for each service.

3. How to Consume Destination Fragments

Follow these steps to consume a Destination Fragment in your BTP subaccount:

Step 1: Create a Destination

Navigate to SAP BTP Cockpit > Connectivity > Destinations .Define properties:Name: my-fragment.Type: HTTP.URL: https://api.example.com.Authentication: OAuth2ClientCredentials.Client ID/Secret: Stored in BTP secrets.

Step 2: Create a Destination Using the Fragment

you will have to perform API request to create a New Fragment as there is no option of creation via UI in BTP – Destination 

Step 3: Consume in Applications

Applications access the destination via the destination service:

// Example: Resolve a destination with an optional fragment and call its target URL.
// Requires: axios ^1.x

const axios = require(‘axios’);

async function callViaDestination() {
// Replace with your values
const region = ‘eu10’; // e.g., eu10, us10, etc.
const destinationName = ‘AVR’; // your destination name
const fragmentName = ‘APIKey’; // optional: the name of the destination fragment to apply
const accessToken = process.env.DEST_CONF_ACCESS_TOKEN; // bearer token for Destination Configuration service

const baseUrl = `https://destination-configuration.cfapps.${region}.hana.ondemand.com`;
const destUrl = `${baseUrl}/destination-configuration/v1/destinations/${encodeURIComponent(destinationName)}`;

try {
// 1) Resolve destination (apply fragment via header if provided)
const headers = {
‘Authorization’: `Bearer ${accessToken}`,
‘Accept’: ‘application/json’,
};
if (fragmentName) {
headers[‘X-Fragment-Name’] = fragmentName; // apply fragment
}

const { data: destination } = await axios.get(destUrl, { headers });

// destination typically includes properties like URL, headers, and possibly Authorization
// depending on the auth type configured in the destination.
const targetUrl = destination.URL;
const targetHeaders = { …(destination.headers || {}) };

// If the resolved destination returns an Authorization header (e.g., OAuth flow handled by Destination service),
// propagate it to the call below.
if (destination.Authorization) {
targetHeaders[‘Authorization’] = destination.Authorization;
}

// 2) Call the resolved target URL (GET as example)
const response = await axios.get(targetUrl, {
headers: targetHeaders,
// If your destination requires additional headers like sap-client etc.,
// they may be present in destination.properties or destination.headers.
// You can map them into targetHeaders as needed.
});

console.log(‘Status:’, response.status);
console.log(‘Data:’, response.data);
} catch (err) {
// Helpful diagnostics
if (err.response) {
console.error(‘Destination/Target call failed:’, err.response.status, err.response.data);
} else {
console.error(‘Error:’, err.message);
}
}
}

callViaDestination();

4. Use Cases & Diagrams

Use Case 1: SAP Build Apps (Low-Code)

Scenario: A Build App needs to fetch data from SAP S/4HANA Sales Orders.

Fragment: Preconfigured with OAuth2ClientCredentials and S/4HANA endpoint.Consumption: Drag-and-drop the destination into the app’s data source.

Diagram:

Use Case 2: SAP Process Automation

Scenario: A workflow triggers an external payment gateway API.

Fragment: Includes API URL, Basic Auth, and retry policies.Consumption: Use the destination name in a REST API step.

Diagram:

Use Case 3: CAP-Based Applications

Scenario: A CAP service reads data from a custom API.

Fragment: Configured with JWT Bearer token and CORS settings.Consumption: Reference the destination in cds.env.

Diagram:

5. Key Benefits

Accelerated Development: Reduce integration time by 40%+ using pre-configured fragments.Consistent Security: Enforce MFA, encryption, and auditing across all apps.Centralized Control: Update endpoints/authentications once; changes propagate everywhere.Compliance: Align with ISO 27001, GDPR, and enterprise security policies.

6. Conclusion

Destination Fragments in SAP BTP are a game-changer for developers, enabling secure, reusable, and governance-ready integrations. Whether you’re building low-code apps, automating processes, or developing enterprise services, fragments simplify connectivity while maintaining security and compliance.

Next Steps:

Explore the SAP BTP Destination Documentation.Try fragments in the SAP BTP Free Tier.

By leveraging Destination Fragments, you future-proof your integrations and focus on innovation—not configuration chaos.

 

 

​ In the era of hyper-automation and low-code/no-code platforms, seamless connectivity between services is critical. SAP BTP’s Destination Fragments provide a standardized, reusable approach to managing API endpoints, security configurations, and network policies.This blog explores how developers can consume Destination Fragments in SAP Build Apps, Process Automation, and other development contexts to accelerate integration, enhance security, and streamline governance.Reference : SAP Help Documentation – Destinations with Fragments1. What Are Destination Fragments?Destination Fragments are reusable configuration components in SAP BTP that define:Target endpoints (e.g., SAP S/4HANA, SAP SuccessFactors, or external APIs).Authentication methods (OAuth, Basic Auth, Client Certificates).Network policies (e.g., CORS, whitelisting).Custom headers or query parameters.Fragments are consumed by Destinations, which act as unified gateways for applications to access backend systems securely.2. Why Consume Destination Fragments?Reusability: Define once, use across multiple applications.Security Centralization: Enforce consistent authentication and encryption.Governance: Ensure compliance with enterprise policies.Simplicity: Eliminate manual configuration for each service.3. How to Consume Destination FragmentsFollow these steps to consume a Destination Fragment in your BTP subaccount:Step 1: Create a DestinationNavigate to SAP BTP Cockpit > Connectivity > Destinations .Define properties:Name: my-fragment.Type: HTTP.URL: https://api.example.com.Authentication: OAuth2ClientCredentials.Client ID/Secret: Stored in BTP secrets.Step 2: Create a Destination Using the Fragmentyou will have to perform API request to create a New Fragment as there is no option of creation via UI in BTP – Destination Step 3: Consume in ApplicationsApplications access the destination via the destination service:// Example: Resolve a destination with an optional fragment and call its target URL.
// Requires: axios ^1.x

const axios = require(‘axios’);

async function callViaDestination() {
// Replace with your values
const region = ‘eu10’; // e.g., eu10, us10, etc.
const destinationName = ‘AVR’; // your destination name
const fragmentName = ‘APIKey’; // optional: the name of the destination fragment to apply
const accessToken = process.env.DEST_CONF_ACCESS_TOKEN; // bearer token for Destination Configuration service

const baseUrl = `https://destination-configuration.cfapps.${region}.hana.ondemand.com`;
const destUrl = `${baseUrl}/destination-configuration/v1/destinations/${encodeURIComponent(destinationName)}`;

try {
// 1) Resolve destination (apply fragment via header if provided)
const headers = {
‘Authorization’: `Bearer ${accessToken}`,
‘Accept’: ‘application/json’,
};
if (fragmentName) {
headers[‘X-Fragment-Name’] = fragmentName; // apply fragment
}

const { data: destination } = await axios.get(destUrl, { headers });

// destination typically includes properties like URL, headers, and possibly Authorization
// depending on the auth type configured in the destination.
const targetUrl = destination.URL;
const targetHeaders = { …(destination.headers || {}) };

// If the resolved destination returns an Authorization header (e.g., OAuth flow handled by Destination service),
// propagate it to the call below.
if (destination.Authorization) {
targetHeaders[‘Authorization’] = destination.Authorization;
}

// 2) Call the resolved target URL (GET as example)
const response = await axios.get(targetUrl, {
headers: targetHeaders,
// If your destination requires additional headers like sap-client etc.,
// they may be present in destination.properties or destination.headers.
// You can map them into targetHeaders as needed.
});

console.log(‘Status:’, response.status);
console.log(‘Data:’, response.data);
} catch (err) {
// Helpful diagnostics
if (err.response) {
console.error(‘Destination/Target call failed:’, err.response.status, err.response.data);
} else {
console.error(‘Error:’, err.message);
}
}
}

callViaDestination();4. Use Cases & DiagramsUse Case 1: SAP Build Apps (Low-Code)Scenario: A Build App needs to fetch data from SAP S/4HANA Sales Orders.Fragment: Preconfigured with OAuth2ClientCredentials and S/4HANA endpoint.Consumption: Drag-and-drop the destination into the app’s data source.Diagram:Use Case 2: SAP Process AutomationScenario: A workflow triggers an external payment gateway API.Fragment: Includes API URL, Basic Auth, and retry policies.Consumption: Use the destination name in a REST API step.Diagram:Use Case 3: CAP-Based ApplicationsScenario: A CAP service reads data from a custom API.Fragment: Configured with JWT Bearer token and CORS settings.Consumption: Reference the destination in cds.env.Diagram:5. Key BenefitsAccelerated Development: Reduce integration time by 40%+ using pre-configured fragments.Consistent Security: Enforce MFA, encryption, and auditing across all apps.Centralized Control: Update endpoints/authentications once; changes propagate everywhere.Compliance: Align with ISO 27001, GDPR, and enterprise security policies.6. ConclusionDestination Fragments in SAP BTP are a game-changer for developers, enabling secure, reusable, and governance-ready integrations. Whether you’re building low-code apps, automating processes, or developing enterprise services, fragments simplify connectivity while maintaining security and compliance.Next Steps:Explore the SAP BTP Destination Documentation.Try fragments in the SAP BTP Free Tier.By leveraging Destination Fragments, you future-proof your integrations and focus on innovation—not configuration chaos.    Read More Technology Blog Posts by SAP articles 

#SAP

#SAPTechnologyblog

You May Also Like

More From Author