Skip to Content
Product Information
Author's profile photo Gerd Schoeffl

Control Data Export Service Access to SAC Models

With the Data Export Service (DES) we provide an open API to retrieve data from SAC models. But obviously not all models and not all data in a model should be retrievable without a detailed access control. Let us have a look at the options we can use to restrict the access to SAC models. We have to distinguish the two different oAuth scenarios that are available with DES: 2-legged or 3-legged approach.

Let us have a brief look at what the difference between the two options are and what they are used for. For more details please have a look at our documentation:


2-legged scenario

This approach is used for system-to-system data transfer without the involvement of a user. The client connects directly to the server without a specific user being involved. Thus is the server (in our case the SAC system) no named user is used but a technical connection user that cannot be modified and also cannot be assigned to any roles. User based access restrictions thus cannot be applied.


3-legged scenario

Here we have a named system user involved in the data export. That means when data is ready the SAC system is accessed with a named (SAC-) user. Thus, any user-based data access restriction in SAC can be enforced.


Model Setting ‘Restricted Export’

This setting controls whether a given model can be exported at all. If this toggle is enabled for a given model then no data export via DES is possible – not matter whether you are using a 2-legged or a 3-legged scenario.


Toggle for restricted export

If the toggle is NOT enabled (default setting) then a 2-legged export of ALL data in the model is possible. For the 3-legged scenario the behavior depends on the user and the data privacy settings for the model.


Model Settings for Data Access


Settings for data access


We have two options to control the access to the data in a model. It can be done by the toggle ‘Model Data Privacy’ – any user who wants to access the data has to have the corresponding roles assigned.

When using ‘Data Access in Dimension’ you can specify for each dimension member whether a given user should be able to write or read data booked against this dimension member.

Both options require a system user. As we have already explained above in the 3-legged case such a user exists and can be checked. Thus the user can only export such data through DES he/she is entitled to use. In the 2-legged case we do not have a named system user. Thus, the security settings cannot be evaluated and are not taken into consideration.


Logging of data exports via DES

When the export is done using a named user (3-legged case) the system tracks the exports in the activity log.

From the description you can obtain the information whether fact data or master data for certain dimensions have been exported.


Activity log


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Igor Stankevich
      Igor Stankevich


      How to establish oAuth 3-legged approach? In oAuth settings there is no any user credentials


      Author's profile photo Gerd Schoeffl
      Gerd Schoeffl
      Blog Post Author

      Hi Igor,

      For the details regarding the setup of the 3-legged approach please have a look at the documentation:

      Best regards


      Author's profile photo Srilakshmi Suriyanarayanan
      Srilakshmi Suriyanarayanan


      1)In a 3 legged approach , where can we provide a system user id in the export job ? As of now , the job is using the credentials or the user who created it - no matter who runs it.

      2) Can we make it to work like it uses the credentials of the user who runs it too?

      Please advise.

      Best Regards,


      Author's profile photo Gerd Schoeffl
      Gerd Schoeffl
      Blog Post Author

      Hello Sri,

      We are talking about two different ways of getting data out of an SAC system. The current blog describes a scenario where the new Data Export Service is used. It is an oData based API that can be used to PULL data from an SAC system.

      The scenario you are talking about is the data export that is created in the data modeling in SAC and that PUSHES data from SAC into another system (like S/4, BW,..). For this scenario the above blog does not apply. Here the case is as you have described - unfortunately it is not possible to make the system use the credentials of the user who triggers the export.


      Best regards


      Author's profile photo Srilakshmi Suriyanarayanan
      Srilakshmi Suriyanarayanan

      Many thanks for the clarification, Gerd!