A Practical Example of Remote Authorizations in SAP Datasphere

Introduction

If you have a BW system and are interested in reusing your SAP BW Analysis Authorizations in SAP Datasphere, this blog is for you.

The SAP documentation on this topic is extensive, so this blog aims to provide a practical implementation example along with our recommendations.

The Analysis Authorizations from BW will be exported to Datasphere, translated into “Data Access Controls” (DACs) and will be automatically applied to your data model in SAP Datasphere.

Prerequisites

This feature is supported only for SAP BW v7.5 SP16 and higher and SAP BW∕4HANA v2.0 and higher systems.

The SAP Note 3062381 describes the prerequisites and details on the Authorization Replication from BW.

After you implement the required notes (depending on your system landscape), you will find new objects in your system:

Table RSDWC_RSEC_DAC for the authorization replication.

Transaction RSDWC_DAC_RSEC_GEN with underlying Report RSDWC_DAC_RSEC_EXTRACT.

BAdi RSDWC_DAC_RSEC_USER_UPDATE

Our Setup on the BW Side

On BW side, we have an ADSO “ZEPI010” with the following data (excerpt):

“Product Category” is characteristic “ZEPPRCAT”, which is set to “Authorization-Relevant”.

Also in BW, we created the user ‚DEMO‘ via SU01 and maintained its email address in the user record. This step is essential for mapping in SAP Datasphere! More information on the mapping can be found in below chapter “Extra: Overriding usernames if needed”.

We assigned an analysis authorization “ZDSP_DEMO” to the user “DEMO”, where ZEPPRCAT is restricted to “Graphic Cards”:

BW Tables & Transactions

First, go to the table RSDWC_RSEC_DAC. You will have it in the system if you follow the instructions from the note mentioned in “prerequisites”.

The table contains the data to be transferred to Datasphere. In our case, since no actions have been taken yet, it should currently be empty.

Second go to transaction RSDWC_DAC_RSEC_GEN (same as SE38 Report RSDWC_DAC_RSEC_EXTRACT).

Enter the User & Infoprovider for which the replication should be done, in our case user DEMO and provider ZEPI010.

Make sure to set the last checkbox “Display replication results”.

You may not leave input fields empty, but you can work with the asterisk (*) to select all users or providers.

Next, choose the process mode:

Simulation will not do anything and just show you what would happen.
Replicate Authorizations will update table RSDWC_RSEC_DAC with the selection above.
Remove all Authorizations will delete all entries from table RSDWC_RSEC_DAC, irrespective of the selection made above!

Now go ahead and select “Replicate Authorizations”. Afterwards check the contents of table RSDWC_RSEC_DAC. There should be one entry that looks like this:

Note the field “FILTERIOBJNM” which holds the value (“ZEPPRCAT” IN (‘Graphic Cards’)). This is the restriction from the analysis authorization which will be used in the Data Access Control (DAC) of SAP Datasphere.

Now the necessary information is prepared and ready to be extracted to SAP Datasphere.

Actions in Datasphere

Importing the Metadata of the BW Provider

First, we bring the ADSO ZEPI010 into Datasphere via a remote table. Therefore, we go to our Space (AREA_51) and in the data builder, select “Import Remote Tables”, chose a connection (to the respective connected BW source system – SAP_B4H_ZW2), select ZEPI010 from the list and finally, confirm the import and deployment.

After importing the metadata, we can preview the data from the remote table:

Importing the Remote authorizations

Now, in the Data Builder, we go to “import” dropdown menu and choose “import permissions”.

In the next step, we select a connection to the BW system, and then provide a name for the table. Let’s just keep the original name: “RSDWC_RSEC_DAC” and hit “Import and Deploy”.

In the next step, we need to specify for which providers you want to import the permissions:

In the last step, a summary is shown. It has two tabs, two objects are on the Data Builder tab, one on the “Data Access Controls”

In total, three objects will be created:

The permissions script (_P)
The protected View (_V)
The Data Access Control (_D)

One last time, hit on “Import and Deploy” and those objects will be generated.

After successful creation, the status will change to “Created” and you can leave the wizard by clicking on “Finish”.

As a last step, let’s open the remote table RSDWC_RSEC_DAC and check the content. No surprises here, the same values we saw earlier in BW are now available in Datasphere (It’s a remote table after all).

Sanity Check

So, what just happened?

The remote table RSDWC_RSEC_DAC contains the values of the corresponding BW table (the permissions of the users).

A view (ZEPI010_V) was created on remote table ZEPI010. Also, a data access control (ZEPI010_D) was created.

Upon inspecting the view (ZEPI010_V), we observe that the DAC is already applied to the view, requiring no additional configuration.

The result is a view protected by the DAC.

When opening the DAC, we can see that the permissions entity of the DAC is the automatically created Permissions Script (_P).

When looking at the Permissions Script, we see that it creates all the records the user is allowed to see. It serves as the input for the DAC, which serves as a filter for the data the user may see.

Checking the Result

The VIEW ZEPI010_V without the Data Access Control shows 135,870 entries (including “Notebooks” and “Flat Screen Monitors”):

For User DEMO, with the DAC ZEPI010_D in place, the result is restricted to “Graphic Cards”:

8,387 Entries (and indeed only “Graphic Cards”) are shown!

Extra: Overriding usernames if needed

If user records in BW lack an email address or need to be updated (e.g., to match Datasphere User-IDs), you can overwrite them using custom logic.

The referenced note SAP Note 3062381 outlines the necessary setup.

We implemented the BADI and corresponding class as “Z_RSDWC_DAC_RSEC”.

In the method “MAP_USER_IDENTIFIER” you can implement your own logic.

Let’s have a look at our Demo user, which has an Email address maintained in SU01:

Next, we set a breakpoint in the method “MAP_USER_IDENTIFIER” to see what’s happening.

Then we start transaction RSDWC_DAC_RSEC_GEN with the known selection (DEMO/ZEPI010).

The debugger should open up and we can inspect the coding. In our example, we overwrite the Email address of the user DEMO with uppercase letters before the “@” symbol.

By looking at the variables, we can see that the following is coming in, which corresponds nicely to the user record in SU01:

Once our case-condition in the coding is hit, the Email is overwritten with the uppercase value.

This of course has no relevancy for SAP Datasphere as the users in Datasphere are not case-sensitive and therefore, the content of the string is still the same.

It just shows how the overriding could look like and you can easily implement any kind of custom logic (e.g. using an ADSO for Lookup or other, more complex logic).

Summary

If your BW system already has analysis authorizations, the quickest way to bring them to SAP Datasphere is by leveraging remote authorizations as demonstrated here.

In case you need to create authorizations in SAP Datasphere directly from scratch, see our other blog:

A practical example of the three different types of data access controls (DACs) in datasphere

Related Blogs

A practical example of the three different types of Data Access Controls (DACs) in Datasphere