Technology Blog Posts by Members
cancel
Showing results for 
Search instead for 
Did you mean: 

The Strategic Need for an API Bridge

In a modern enterprise, SAP Datasphere acts as the "Single Source of Truth." However, the data stored there often needs to be consumed by diverse downstream consumers:  from custom Python-based AI models and React web applications to third-party reporting engines.

The challenge isn't just "getting the data out"—it’s doing so securely and efficiently. Relying on manual exports or basic authentication creates security risks and operational bottlenecks. By architecting an API Bridge using Postman, I created a standardized, automated, and OAuth 2.0-secured gateway. This allows us to move away from "one-off" data pulls and toward a professional Data-as-a-Service (DaaS) model where any authorized application can consume real-time SAP data on demand.

The blog is divided into 5 parts:

  • Part 1: The Data Foundation (Datasphere - Data Builder)
  • Part 2: Security & Identity—The OAuth 2.0 Client

  •  Part 3: The Connection (Postman Strategy)

    • Option 1: The Manual Approach (Standard)

    • Option 2: The Automated Approach (Professional)

  • Part 4: Real-Time Data Validation (The Visualizer)

  • Part 5: The End Goal—Exporting for Downstream Apps

Part 1: The Data Foundation (Datasphere - Data Builder)

Before an API can "see" your data, it must be properly modeled and exposed. For this setup, I used a dataset of Amazon Bestselling Books.

Why use a Graphical View instead of a Table?

While you can expose a raw table, a Graphical View is the professional choice. It acts as a "Virtual Layer" where you can:

  • Filter Data: Exclude old records so the API doesn't get overloaded.
  • Rename Fields: Change technical headers (like PUB_YR) to business-friendly names (like Publication_Year).
  • Calculations: Add new columns (like Profit_Margin) directly in the view.

Step-by-Step:

  1. Import: Upload your CSV/Table into the Data Builder.
  2. Create View: Drag the table into a new Graphical View.
  3. Semantic Usage: Set this to Relational Dataset (this is mandatory for OData access).
  4. Expose for Consumption: Toggle this ON. This is the most critical step; it tells Datasphere to generate a URL for external tools.
  5. Deploy: Click the "Save and Deploy" icon.

SAP Datasphere Data Builder view properties showing Expose for Consumption toggled on.

 

In the SAP Datasphere Data Builder, ensure your Graphical View is set to 'Relational Dataset' and that 'Expose for Consumption' is toggled ON. A successful deployment (indicated by the green checkmark) is required for the OData service to become reachable.

Click on “Generate OData Request” and copy the OData Request URL, which will be needed later during Postman request setup.

anubhav91_0-1774891953389.png

 

Part 2: Security & Identity—The OAuth 2.0 Client

To allow Postman to talk to SAP Datasphere, avoid using personal login credentials. Instead, create an OAuth 2.0 Client. This acts as a "Technical User" that is secure, scoped, and easy to manage.

Step 1: Navigate to App Integration

Go to System > Administration > App Integration tab.

SAP Datasphere Data Builder screen showing Model Properties for Bestsellers Books View with Relational Dataset usage and Expose for Consumption toggled ON.

 

Step 2: Create the Technical User

Click on "Add an OAuth Client". In the configuration window:

  1. Provide a Name (e.g., POC_Technical_User).
  2. Set the Authorization Grant to Client Credentials.
  3. Important: Copy your Secret immediately and save it safely; you won't be able to see it again!

Configuration window for an SAP Datasphere OAuth Client showing Name, Client ID field, and the Client Credentials authorization grant type.

 

Step 3: The "403" Safeguard (Role Assignment)

This is the most critical technical step. The API will return a 403 Forbidden error unless permissions are set. Click Select Roles and assign Scoped Data Warehouse Cloud Viewer and Scoped Data Warehouse Cloud Modeler as optional.

Role assignment screen in SAP Datasphere, selecting Scoped Data Warehouse Cloud Modeler and Scoped Data Warehouse Cloud Viewer roles for an OAuth client.

 

Step 4: Note your Endpoints

Once saved, your new client will appear in the Configured Clients list. Make sure to note down the Authorization URL and Token URL shown at the top of the screen. You will need these for your Postman Environment.

SAP Datasphere App Integration screen displaying the configured OAuth Clients list, Authorization URL, and Token URL.

 

 Part 3: The Connection (Postman Strategy)

Now that our SAP Datasphere "Bridge" is built and secured, we need to cross it using Postman. There are two ways to handle the OAuth 2.0 handshake.

Option 1: The Manual Approach (Standard)

While automation is our ultimate goal, establishing a manual connection first is a critical diagnostic step. This ensures that your SAP Datasphere credentials and roles are configured correctly before we add the complexity of scripting. This is the "out-of-the-box" method. It is great for a quick one-time test, but it has a significant drawback: Tokens expire.

Detailed Steps:

Step 1: Configure the Request

In Postman, create a new GET request using your Datasphere OData URL. Navigate to the Authorization tab and select OAuth 2.0. Fill in the "Configure New Token" section using the Client ID and Secret we generated in Part 2.

Use the URL from Part 1. from Datasphere View in the https section.

Once you complete Step 2 and Step 3 below, the Token name (Yellow Highlighted) will pop up based on the token name you provided during the "Configure New Token" step.

Postman Authorization tab setup for OAuth 2.0 showing Client ID and Client Secret fields highlighted.

 Step 2: Authenticate with SAP

Scroll down and click "Get New Access Token". If your credentials are correct, you will see a green checkmark indicating that the authentication handshake was successful.

Postman popup window showing a green checkmark and 'Authentication complete' message.

 

Step 3: Commit the Token

Once authenticated, Postman stores the token in its local manager. You must click "Use Token" to link this specific string to your current request headers.

Postman Manage Access Tokens window highlighting the 'Use Token' button.

 

Headers: Go to the Headers tab. You must add the key x-sap-sac-custom-auth with the value true. This tells the SAP gateway to process your request as a technical user.

anubhav91_8-1774499566289.png

 

Step 4: Execute the Call

With the token active, you are ready to hit Send. Postman will now pass the bearer token to SAP Datasphere to request your data.

Postman interface highlighting the blue 'Send' button for the OData request.

Step 5: Validate the Result

A successful connection will return a 200 OK status. You can now see your Bestsellers Books data in raw JSON format. While this confirms the "Bridge" is working, notice how hard it is to read—this is why we will implement the Visualizer in Part 4.

Postman response body showing 200 OK status and raw JSON data for the Amazon Bestseller Books dataset.

The Comparison (Transitioning to Option 2)

The manual method works perfectly, but as you can see, it requires several clicks. If you close Postman or wait an hour, that token will expire, and you will have to repeat these steps.

Next, let's explore how to automate this entire flow using a Pre-request Script, so you never have to click "Get New Token" again.

Option 2: The Automated Approach (Professional)

While the manual approach confirms our connection works, it is not scalable. For a truly professional API Bridge, we need a "Set-and-Forget" solution. By using a Pre-request Script, we turn Postman into an intelligent agent that manages its own OAuth 2.0 lifecycle. This is the "Set-and-Forget" method. We use a Pre-request Script to turn Postman into an intelligent agent that manages its own security.

Step 1: Establishing the Environment Layer

Before we write the script, we must centralize our configuration. Instead of hardcoding URLs and Secrets—which is a security risk and an administrative nightmare—we use Postman Environments.

As shown in the image below, create a new environment and name it (e.g., SAP Datasphere). Enter details for ds_url, client_id, client_secret, and token_url as variables.

access_token and token_expiry will be automatically generated after finishing Step 3 below.

Postman Environment tab showing variables for ds_url, client_id, client_secret, token_url, and automated fields for access_token and token_expiry.

Why this matters:

  • Security: Your client_secret is masked.
  • Automation: Notice the access_token and token_expiry variables. Our script will automatically update these values every time a new handshake occurs, keeping the connection "alive" indefinitely.

Step 2: The Pre-request Script (The Brain)

Instead of adding a script to every individual request, we add it to the Collection Folder. This ensures the logic applies to every OData call you ever add to this project.

  1. Click the three dots next to your collection name, for e.g. "Datasphere Connection" collection, and select Edit.
  2. Navigate to the Scripts > Pre-request tab.
  3. The Logic: The script checks if a token exists or if the current time has passed the token_expiry. If needed, it fetches a fresh token silently in the background.

Paste this script into the Collection Pre-request tab:

// Check if the token is expired (or doesn't exist)

if (!pm.environment.get("access_token") || Date.now() > pm.environment.get("token_expiry")) {
    console.log("Token expired or missing. Fetching a new one...");
    pm.sendRequest({
        url: pm.environment.get("token_url"),
        method: 'POST',
        header: {
            'Content-Type': 'application/x-www-form-urlencoded',
            'Authorization': 'Basic ' + btoa(pm.environment.get("client_id") + ":" + pm.environment.get("client_secret"))
        },
        body: {
            mode: 'urlencoded',
            urlencoded: [
                { key: 'grant_type', value: 'client_credentials' }
            ]
        }
    }, function (err, res) {
        if (err) {
            console.log("Error fetching token: " + err);
        } else {
            var response = res.json();
            pm.environment.set("access_token", response.access_token);
 
// Set expiry time (current time + expires_in seconds)

            pm.environment.set("token_expiry", Date.now() + (response.expires_in * 1000));
            console.log("New token fetched successfully!");
        }
    });
}

 

Postman Pre-request script showing advanced OAuth 2.0 logic with automated expiration checking and environment variable management.

Click the Save button at the top right of the Collection tab (or press Ctrl+S). If you don't save here, the collection won't "know" to run this logic before your requests.

Step 3: Inherit Authentication

After the Pre-request script fetches a fresh token and saves it to the environment, we need to tell our specific API request to use that value.

  • Authorization: On your GET request, set the Auth Type to Bearer Token.
  • Variable: In the Token field, type {{access_token}}.

           Postman interface showing the 'Bearer Token' authorization type and the reference to the access_token variable.

  • Environment: Ensure the "SAP Datasphere" environment is active in the top-right dropdown.Selecting the correct Environment in the top-right dropdown.
  • Headers Tab: Add the mandatory key 'x-sap-sac-custom-auth' and set it to 'true'. This is essential for both approaches to bypass the SAP login screen.

           Postman Headers tab showing the manually added key set to true, necessary for bypassing interactive SAP login screens during API calls.

  • Send: Click the blue Send button.

What happens when you click Send?

This is the "Grand Opening." When you hit Send, Postman follows this sequence:

  1. The Script Runs: It checks the environment variables. If the token is missing/expired, it calls the SAP Token URL.
  2. Variables Update: You’ll actually see the access_token and token_expiry values change in your Environment tab in real-time.
  3. The GET Request Fires: Postman injects the fresh token into the header and sends the request to Datasphere.
  4. The Result: You receive your 200 OK and the JSON data.

Postman response footer showing a successful 200 OK status code and response time, confirming a secure connection between Postman and SAP Datasphere.

Why this is the "Professional" Way:

This setup creates a seamless link. When you hit Send, Postman follows this sequence:

  1. The Script Runs: It checks the environment variables. If the token is missing/expired, it calls the SAP Token URL.
  2. Variables Update: You’ll actually see the access_token and token_expiry values change in your Environment tab in real-time.
  3. The GET Request Fires: Postman injects the fresh token into the header and sends the request to Datasphere.
  4. The Result: You receive a 200 OK response and the corresponding JSON data.

Benefits:

  • The Automated Advantage: You can walk away for a week, come back, hit "Send," and it will just work. The script handles the handshake before you even realize a token was needed.
  • Self-Healing: If the token expires, the script detects it and fixes it in milliseconds.
  • Security: Your secrets are stored in the Environment layer, not the request itself.
  • Scalability: You can add 100 different OData requests to this collection, and they will all share this automated login logic.

Part 4: Real-Time Data Validation (The Visualizer)

Raw JSON data is hard to read. An alternative option is to use the Postman Visualizer to transform our live SAP Datasphere OData feed into a professional, searchable dashboard.

The "Visualize" Tab:

Step 1: The "Post-Response" Script

In your automated GET request, navigate to the Scripts > Post-response tab. Unlike the Pre-request script, which handles security before the call, this script executes after the data arrives.

Paste the following code to map your OData fields to an HTML table (You can modify the template below as per your need):

// Define the HTML/CSS Template

var template = `
    <style>
        body { font-family: Arial, sans-serif; margin: 20px; }
        #search { margin-bottom: 15px; padding: 10px; width: 100%; border: 1px solid #ccc; border-radius: 4px; }
        table { border-collapse: collapse; width: 100%; }
        th { background-color: #0070f3; color: white; padding: 10px; text-align: left; position: sticky; top: 0; }
        td { border: 1px solid #ddd; padding: 8px; }
        tr:nth-child(even) { background-color: #f2f2f2; }
        tr:hover { background-color: #e9f5ff; }
    </style>
    <input type="text" id="search" onkeyup="searchTable()" placeholder="Search for book names or authors...">
    <table id="bookTable">
        <thead>
            <tr>
                <th>Name</th>
                <th>Author</th>
                <th>Price</th>
                <th>Year</th>
            </tr>
        </thead>
        <tbody>
            {{#each response.value}}
            <tr>
                <td>{{Name}}</td>
                <td>{{Author}}</td>
                <td>{{Price}}</td>
                <td>{{Year}}</td>
            </tr>
            {{/each}}
        </tbody>
    </table>
    <script>
        function searchTable() {
            var input = document.getElementById("search");
            var filter = input.value.toUpperCase();
            var table = document.getElementById("bookTable");
            var tr = table.getElementsByTagName("tr");
            for (var i = 1; i < tr.length; i++) {
                var txtValue = tr[i].textContent || tr[i].innerText;
                if (txtValue.toUpperCase().indexOf(filter) > -1) {
                    tr[i].style.display = "";
                } else {
                    tr[i].style.display = "none";
                }
            }
        }
    </script>
`;

pm.visualizer.set(template, {
    response: pm.response.json()
});

Step 2: The "Grand Opening" (Click Send)

Once your script is saved, click the blue Send button.

  1. Status Check: You will see the 200 OK status return in the bottom right.
  2. Visualize: In the response body section, click the Visualize tab.
  3. Result: Your raw data is now a clean, interactive blue table. You can search for specific authors or titles in real-time.

Postman interface showing the final visualized OData table with a search bar, 200 OK status, and professional blue header formatting.

Part 5: The End Goal—Exporting for Downstream Apps

The ultimate goal of this "Bridge" is to feed other systems without manual intervention.

  • For Business Users: Use Postman’s "Send and Download" feature (click the arrow next to the Send button). This exports the live OData response into a .json or .csv file that can be ingested by Excel or Power BI.

  • For App Developers: Since the OAuth flow is now automated, this Postman Collection can be exported as a JSON file. Developers can use the Postman Collection Runner or Newman to integrate this data feed directly into a CI/CD pipeline or a custom React/Python application.

Conclusion: From Data Silo to API Bridge

In this guide, we didn't just connect Postman to SAP Datasphere—we built a production-ready OData bridge.

  • Exposed: Turned a static View into a live OData service.
  • Secured: Implemented robust OAuth 2.0 scoping.
  • Automated: Used Pre-request scripts to ensure the connection never expires.
  • Validated: Used the Visualizer to prove the data is accurate at a glance.

By following this workflow, you can empower your external applications, third-party vendors, or internal analytics tools with real-time data from your SAP ecosystem—securely and automatically.

#SAPDatasphere #SAPBDC #Postman #OAuth2 #OData #Integration #DataAsAService

4 Comments
Labels in this area