Data Export API: Let’s do some “App Integration”

This is part of a series on exploring the SAP Analytics Cloud (SAC) data export API. When the series is complete, it will also be available as a single tutorial mission.

Before you can use SAC’s data export API, there is a little bit of housekeeping that needs to be done. Specifically, app integration for the consuming service needs to be configured. We need to do this, because SAC needs to know about the app and what kind of authentication it will use, so that it can provide the authorization keys that the app will need to authenticate.

To do this, first navigate to the administration tools. (you will need a user with the proper analytic privileges to do this)

Once you are there, you will initially land on the system configuration tab. From there, find the App Integration tab.

Once you are in the App Integration tab, let’s take a moment to familiarize ourselves with the layout:

- At the very top, there is a list of URLs. These URLs will demarcate the authorization related API endpoints. Specifically, your app will be calling the Token URL, to get the requisite session authorization token and it will be handing this token over with every API call in the session. When exploting the API with an API tester, you’ll copy and past this URL into the appropriate place of your test tool. When we build a “hello world” Python wrapper, we’ll build this URL dynamically.
- Below this, you’ll see the apps already configured for this tenant. The client ID is displayed, but if you click on them, you can also get the app secret. Depending on the tooling that you use to connect, client ID might be called “app ID” and app secret might also be called “app secret”.
- Lastly, there is the “Add a New OAuth Client” button.

When you add a new OAuth client, you are presented with a dialog. Give it a name.

You can choose between “Interactive Usage” and “Interactive Usage and API Access”. Interactive Usage refers to 3-legged OAuth authentication and API Access refers to 2 legged OAuth workflows. 2-legged OAuth authentication is the “technical user” workflow. The app authenticates by providing a client ID and client secret when it calls the Token URL and the token is returned in the response. 3-legged OAuth authentication is used when you want to authenticate interactively, as an individual user. 3 legged does not return the token directly, but rather takes a roundabout approach. Roughly speaking, this prompts the end user for authentication into SAC and then calls the Redirect URI to pass the token and return the user to their application. Because 3 legged is considerably more complex and requires our client to host its own API for the redirect URI, we’ll stick with 2-legged for our exploration. For the security conscious among you, keep in mind that 2-legged “technical users” are going to ignore data access controls and if you want user-based security on your productive custom tools, you’ll want to use 3-legged.

In the Access drop down, you will want to enable Data Export Service (and probably ONLY Data Export service, unless you plan on using the same token for API based administrative tasks).