Blog Co-Author by: Vinh Phat Tu

One of the common requirements in SAP Datasphere projects is exposing analytical models so they can be consumed by SAP Fiori applications or SAP CAP applications through OData services.

Although SAP Datasphere provides native capabilities to generate OData services for Analytical Models, the complete configuration requires several components working together:

• SAP Datasphere
• SAP BTP Destination Service
• OAuth configuration
• Trust between Datasphere and BTP
• SAP CAP (optional)

In this blog, we will walk through the complete end-to-end configuration. By the end of this guide, you’ll be able to expose your SAP Datasphere Analytical Model securely for SAP Fiori or any OData consumer.

Solution Architecture

The overall authentication flow is shown below:

SAP Datasphere
│
│ Generate OData Service
│
▼
OAuth Client (SAML Bearer)
│
▼
SAP BTP Destination
│
▼
SAP Fiori / SAP CAP Application

The authentication relies on:

• OAuth2 SAML Bearer Assertion
• Trusted Identity Provider
• SAP BTP Destination Service

Prerequisites

Before starting, ensure you have:

• SAP Datasphere Administrator access
• SAP BTP Subaccount Administrator access
• Destination Administration permissions
• Analytical Model already deployed
• Authorization to create OAuth Clients

Part 1: Configure SAP Datasphere

Step 1: Expose the Analytical Model for Consumption

In Data-Builder –> Select the Fact view of the Analytical model –> Enable Expose for Consumption

Note: The Fact View (which is your final view for the analytical model) must be exposed — not just the Analytical Model itself. This makes the view available via OData.

Step 2: Establish Trust Between Datasphere and BTP

To enable secure token exchange between BTP and Datasphere, you need to establish a trust relationship.

1. In your BTP Subaccount (where the destination will be created), navigate to Security > Trust Configuration > Destination Trust.

2. In the Trust section, click Export to download the XML metadata file.

3. Open the XML file and note the Provider Name and Signing Certificate.

4. In SAP Datasphere, navigate to System > Administration > App Integration

• Under Trusted Identity Providers, click Add a Trusted Identity Provider.
• Enter the Provider Name and Signing Certificate from the exported XML file.

Step 3: Configure OAuth in SAP Datasphere

 Blog Co-Author by: Vinh Phat TuOne of the common requirements in SAP Datasphere projects is exposing analytical models so they can be consumed by SAP Fiori applications or SAP CAP applications through OData services.Although SAP Datasphere provides native capabilities to generate OData services for Analytical Models, the complete configuration requires several components working together:SAP DatasphereSAP BTP Destination ServiceOAuth configurationTrust between Datasphere and BTPSAP CAP (optional)In this blog, we will walk through the complete end-to-end configuration. By the end of this guide, you’ll be able to expose your SAP Datasphere Analytical Model securely for SAP Fiori or any OData consumer. Solution ArchitectureThe overall authentication flow is shown below:SAP Datasphere││ Generate OData Service│▼OAuth Client (SAML Bearer)│▼SAP BTP Destination│▼SAP Fiori / SAP CAP ApplicationThe authentication relies on:OAuth2 SAML Bearer AssertionTrusted Identity ProviderSAP BTP Destination ServicePrerequisitesBefore starting, ensure you have:SAP Datasphere Administrator accessSAP BTP Subaccount Administrator accessDestination Administration permissionsAnalytical Model already deployedAuthorization to create OAuth ClientsPart 1: Configure SAP DatasphereStep 1: Expose the Analytical Model for ConsumptionIn Data-Builder –> Select the Fact view of the Analytical model –> Enable Expose for Consumption            Note: The Fact View (which is your final view for the analytical model) must be exposed — not just the Analytical Model itself. This makes the view available via OData. Step 2: Establish Trust Between Datasphere and BTPTo enable secure token exchange between BTP and Datasphere, you need to establish a trust relationship.1. In your BTP Subaccount (where the destination will be created), navigate to Security > Trust Configuration > Destination Trust.2. In the Trust section, click Export to download the XML metadata file. 3. Open the XML file and note the Provider Name and Signing Certificate. 4. In SAP Datasphere, navigate to System > Administration > App IntegrationUnder Trusted Identity Providers, click Add a Trusted Identity Provider.Enter the Provider Name and Signing Certificate from the exported XML file. Step 3: Configure OAuth in SAP DatasphereThere are two approaches for setting up the OAuth connection: ApproachAuthentication TypeUse CaseAPI Access (Recommended)SAML 2.0 BearerSupports user propagation and delegated accessTechnical UserClient CredentialsService-to-service without user contextTo configure API Access (recommended):In Datasphere, go to System > Administration > App Integration.Click + Add an OAuth Client.Set the Purpose to API Access.Under Access, select:Data Export Service (mandatory)Catalog User API (optional)Analytics Content Network Interaction (optional)Set the Authorization Type to SAML 2.0 Bearer.Save the configuration and note the Client ID and Client Secret. Part 2: Create the BTP DestinationNavigate to your BTP Subaccount and go to Connectivity > Destinations > Create New Destination.Configure the following properties:PropertyValueAuthenticationOAuth2SAMLBearerAssertionProxy TypeInternetURLThe OData Service URL from your Analytical Model (see below)Token Service URLFound in Datasphere under System > Administration > OAuth2SAML Token URLImportant: Use the OAuth2SAML Token URL (not the standard OAuth Token URL) when using SAML 2.0 Bearer authentication.Finding the OData Service URL:Open the Analytical Model you want to expose in Datasphere.Go to Tools > Generate OData Request.Copy the generated URL — this becomes the destination URL.Note: Each Analytical Model requires its own BTP Destination, but you can reuse the same OAuth client across multiple destinations.In BTP -> go to Subaccount -> Select ‘Connectivity’ -> Destinations -> Add NewToken Service Configuration PropertyValueToken Service URL TypeDedicatedUse Basic Credentials for Token ServiceEnabledToken Service UserOAuth Client ID (from Datasphere)Token Service PasswordOAuth Client Secret (from Datasphere) SAML PropertiesPropertyValueAuthnContextClassRefurn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSessionAudienceFound in Datasphere under App Integration (where OAuth was created)Client KeyOAuth Client ID (Note: Client Key = Client ID, not the Secret)SAML Assertion ProviderDestinationServiceGeneratedName Id Formaturn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress Additional PropertiesKeyValueWebIDEEnabledTRUEWebIDEUsageodata_genHTML5.DynamicDestinationTRUEHTML5.SetXForwardedHeadersFALSE  Part 3: Consume the OData Service in an SAP CAP ApplicationOnce the destination is configured and the Analytical Model is accessible via OData, you can consume it in an SAP CAP (Cloud Application Programming Model) application. For a comprehensive deep dive, refer to the official CAPIRE documentation:Consuming Services — SAP CAP DocumentationPrerequisites for CAP IntegrationThe $metadata file of the external OData serviceA correctly configured BTP destination (completed in Part 2)Step 1: Import the $metadata File into the CAP ProjectThe CAP framework needs to know the structure of the external OData service. Import the $metadata file using the CDS import command:cds import <metadata_file> –as cdsThis command performs the following:Creates an external folder inside the srv directory (or reuses it if it already exists)Copies the metadata file into the external folderGenerates a .csn file based on the metadata (this defines the service structure for CDS)Adds an external service definition in package.json  Step 2: Review the External Service Definition in package.jsonThe CDS framework automatically adds an entry in package.json that points to the .csn file and specifies how to connect to the external OData service. For production, the connection uses the BTP destination. For local development, you can define a separate profile with a specific URL and credentials.Step 3: Expose Entities from the External OData ServiceTo expose entities from the external service in your CAP application, add an import statement referencing the external .csn file using a relative path. Once imported, the external entities can be referenced like any regular CDS entity.using { ExternalService } from ‘./external/AnalyticalModel’;service MyService {    entity AnalyticsData as projection on ExternalService.DataEntity;} Step 4: Add Custom Logic to Call the External OData ServiceIn your custom handler, use cds.connect.to to establish a connection to the external service. The parameter must match the service reference defined in package.json.const cds = require(‘@sap/cds’);module.exports = cds.service.impl(async function () {    const externalService = await cds.connect.to(‘ExternalServiceName’);    this.on(‘READ’, ‘AnalyticsData’, async (req) => {        return externalService.run(req.query);    });});To call the external OData service, custom logic needs to be added in the respective custom handler for the CAP service. First a life cycle handler for the “on” phase for the respective entity needs to be defined. Afterwards the cds.connect.to command needs to be used. It uses one parameter to generate the client for the connection. The parameter is a string value and it needs to match the reference from the package.json file.  The resulting object is then used to run the query of the current request. After the function call, the promise is returned to the enclosing function to respond to the HTTP request and return the requested information. SummaryTo recap the end-to-end flow:Datasphere — Expose the Fact View for consumption and configure an OAuth client with SAML 2.0 Bearer authorization.BTP — Establish trust between the subaccount and Datasphere, then create a destination using OAuth2SAMLBearerAssertion.CAP Application — Import the $metadata file, configure the service binding in package.json, and implement custom handlers to query the external OData service.  Read More Technology Blog Posts by SAP articles 

#SAPCHANNEL