The SAP Data Warehouse Cloud (DWC) offers the option of restricting access to the data in the reporting by means of DAC (Data Access Controls), in the same way as for the analysis authorizations in the classical BW/4HANA. SAP makes available a tool for the reuse of analysis authorizations so that these can be taken over from BW/4HANA into the DWC. This blog takes a first look at these options.
The releases of the DWC only had a binary implementation regarding authorizations for the reporting, which hold an authorization in a space, and could see all data in the relevant space. A finer form of control such as in BW/4HANA regarding authorization objects and analysis authorizations was not possible. The introduction of Data Access Controls in the DWC now makes it possible for a user to define one or more filter criteria (authorization characteristics and values) through which access to the data can be controlled in a line-based way. However, the details of the data access controls and possible concepts could not be looked at in any more detail. Instead, the option of how analysis authorizations can be made accessible from BW/4HANA in the DWC and its data access controls is to be described. This option was created and extended by SAP in the more recent releases of the SWC. The procedure for the actual transfer of the analysis authorizations into the DWC can be found in the help for the DWC and in an SAP blog (transfer of remote authorizations from SAP BW/4HANA into the SAP DWC). This blog here will cover some interesting details that were found in the course of an implementation. In details, they are as follows:
- Preconditions in BW/4HANA for transfer of the authorization model
- The extraction report RSDWC_DAC_RSEC_EXTRACT to transfer the authorization
- Examples for the conversion of the analysis authorizations into the DWC format
- Implementation in the DWC
It should be noted that in addition to the option to import the authorization model from a BW system it is also possible to import these options from an S/4 system. This method is likewise described in an SAP blog (integrate your analysis authorizations in the same way as your data). This functions in a similar way to the transfer of the BW analysis authorizations, even if the options in S4/HANA are not altogether as detailed regarding authorization.
Preconditions in BW/4HANA for transfer of the authorization model
The preconditions for a transfer have existed in the DWC since Q4/2021. A DWC from 2022/03 or later is required for the transfer of the complete model in the model transfer, On the BW/4HANA systems side it is necessary to have BW/4HANA 2.0 with Support Package 10 or higher. If the Support Package version is lower, the corresponding OSS notes must be installed. These are, among others, OSS notes 3049056, 3084315, 3062380 and 3062381. Here OSS note 3062380 must be installed by means of a transport-based correction instruction (TCI), and the corresponding authorizations may be required for. OSS note 3062381 is only a description of the procedure. If the access to the data access controls is to be done remotely via a model transfer, it is also necessary to install OSS note 3123817. The meantime there is also the option to transfer the authorizations from SAP BW 7.5.
On the BW/4HANA system side the relevant data model must be present, i.e., an InfoProvider (CompositeProvider) on which the reporting in the BW/4 system is based. The corresponding analysis authorizations must have been defined in this CompositeProvider. The users in the DWC that are envisaged for the import must have been assigned these analysis authorizations for the InfoProvider. The analysis authorizations are defined by means of transaction RSECADMIN in the BW system and assigned to a user. In the example of ZCA638_DE_DE that is used here for an analysis authorization, the user is given for the CompositeProvider the two authorization objects ZCA_LAND and ZCA_ORG that are used there, together with the corresponding authorizations.
Figure 1: Analysis authorizations in the BW/4HANA (InfoProvider, authorization characteristics and users) for the export model into the DWC
The extraction report RSDWC_DAC_RSEC_EXTRACT
The above-mentioned authorizations form the basis for the transfer and implementation of the authorizations in the data access controls in the DWC. The conversion from BW/4HANA into the data access controls of the DWC is done with the help of report RSDWC_DAC_RSEC_EXTRACT. In BW/4 this fills in authorization table RSDWC_RSEC_DAC, in which the converted authorization data is stored, before this data is made available to the DWC. In report RSDWC_DAC_RSEC_EXTRACT there is also the option to translate the user from the user name in BW/4 to the UserID in the DWC. The SAP standard for the report assumes by default that the user’s name in the DWC is the same as the mail address that was stored in the user maintenance of the BW/4 system of the respective user (the mail address field in transaction SU01 / SU01D). If that is not the case (as in the example case for the blog, in which no DWC user names are used in the mail address format, then the report provides an option to convert these user names. The conversion is done via an extension implementation in BAdI RSDWC_DAC_RSEC_USER_UPDATE. Here the corresponding value in the BWUSER column for the user BW/4 can be converted with the desired value for the UserID in the DWC in the USERIDENTIFIER column. ADSO ZCA638A3 is used for this in the present example so that multiple users can be converted. The UserID in BW/4 is stored in the USERNAME column of the ADSO and in the ZCADWCUID column of the UserIDs in the DWC. The extension implementation of the BAdI is read by the ADSO and this makes available the values from it.
Figure 2: Example ID for an extension implementation for the BAdI RSDWC_DAC_RSEC_USER_UPDATE to convert the UserID BW/4 into the UserID of the DWC
The report RSDWC_DAC_RSEC_EXTRACT can also be executed via transaction RSDWC_DAC_RSEC_GEN. In the selection screen it is possible to restrict to the relevant users and InfoProviders.
Figure 3: Selection screen of extraction report RSDWC_DAC_RSEC_EXTRACT
The results can be checked in table RSDWC_RSEC_DAC. The analysis authorization is show at the top in Figure 4. The general part is on the left, and on the right, there are the details of the object (here authorization for DE). The screen section at the bottom shows the conversion in the detail view in authorization table RSDWC_RSEC_DAC. You can see that the authorization values have been implemented for the individual characteristics in the corresponding SQL statements. Thus, the value for authorization characteristic ZCA_LAND = ´DE´ has been converted into SQL statement zca_land IN (´DE´).
Figure 4: Implementation of the analysis authorizations into the values for the data access controls of the DWC in table RSDWC_RSEC_DAC
Authorization characteristic ZCA_ORG is based in the analysis authorizations on a hierarchy authorization for a node (ZCA_ORG Number 01). This illustrates a node in the hierarchy ZCA_ORG Number Hierarchy, which has pages AT01, CH01, DE01, DK01, PL01, SE01 and UK01 underneath it. See the upper part of Figure 5 regarding this definition of the hierarchy and the definition of the analysis authorization at the bottom right. Here too the BW/4 analysis authorization has been converted into an SQL statement with an IN construct: zca_org IN (´AT01´, ´CH01´, ´DE01´, …), since currently it is not possible in the DWC to defines the DACs at hierarchy nodes.
Figure 5: Implementation of a hierarchy authorization in an SQL statement for the DWC data access controls
Examples for the conversion of the analysis authorizations into the DWC format
After the first implementations have been introduced, this poses the question as to whether all the fine points can be implemented in all the options in the analysis authorizations. The analysis authorizations have many options to define authorizations. In addition to the well-known ´*´ there are also models, individual values and intervals. And not forgetting the innumerable options in the hierarchies (restriction to versions, time reference, aggregated values, etc.). Listing all the options that are available is beyond the scope of this blog. However, a few important implementations needed to be stated.
Implementation of authorizations ´*´ and 0BI_ALL at an authorization characteristic: It is also possible to work with models for characteristics in the analysis authorizations. The best-known model is the model for all values, the ´*´. Here the implementation report in the table then sets the data access control for the characteristic to “not relevant.” In this way all the values are shown in the DWC. They are handled in the same way in analysis authorization 0BI_ALL. BW/4HANA users are likewise given the entry “not relevant” with this authorization in the data access controls for the corresponding authorization characteristic in the DWC.
Implementation of authorizations with intervals: The authorizations can also be stored with intervals for a characteristic. Data with the values DE01, DE02, DE03, AT01, AT02, CH01, DK01, PL01, SE01 and UK01 is included for the characteristic ZCA_ORG from the example model. If an interval AT01 – DE03 is now authorized here, then this is likewise implemented in SQL with the BETWEEN statement.
Figure 6: Implementation of an authorization interval in a BETWEEN SQL statement
Implementation of authorizations with models: In the case of models there is in addition the option to restrict to dedicated models for characteristics Hence, for example, for characteristic ZCA_ORG only organization units with ´DE*´, thus ´DE01´, ´DE02´, ´DE03´. This works with the SQL expression ´DE%´ for the DWC data access controls.
Figure 7: Implementation of an example for an authorization object in the DWC data access controls
Implementation of the consolidation authorization: If you use for an authorization characteristic a consolidation authorization (hence with the model EQ = ´:´), then this leads to it no longer being possible to implement any authorization characteristics any longer in table RSDWC_RSEC_DAC, which is filled via report RSDWC_DAC_RSEC_EXTRACT. Only the user name and the InfoProvider are filled in. The fields in the DAC filters remain blank. No data is displayed in the protected view of the DAC. Thus, the implementation does not function for this type of authorization.
As we can see, the logic that creates the corresponding DWC data access controls from the analysis authorizations of BW/4HANA could almost be described as magical. The conversion does not present any problems for most application cases for the analysis authorizations. There will only be problems in the conversion in special cases of analysis authorizations, such as consolidation authorizations in characteristics. Furthermore, hierarchies represent a special case in the DWC, since these first need to be knocked flat and / or rebuilt using special constructs. Currently the implementation tool still seems to come up against certain limits here.
Implementation in the DWC
The transfer of the model of the InfoProvider and the implementation table is subsequently done via the Data Builder or via a wizard in the DWC. A connection must be set up in the Space with the BW/4HANA system to do this. The wizard not only transfers the data as described in the extraction report (hence with the conversion of the UserID, if applicable), but also creates at the same time the corresponding model for the data access controls in the DWC. This can be done as a remote view in the BW/4HANA system or also dedicated to the corresponding tables in the DWC. However, these then need regularly refreshed in the DWC so that any modifications that are made in the BW/4HANA system are also brought into the DWC. A job can be set up in the DWC for this.
Ever since the upgrades in February 2022, the DWC has also offered the option to transfer the entire model from the BW/4HANA System (of the InfoProviders with the associated analysis authorizations of the users) into the DWC using a wizard, and there creating it as a complete model. This does away with the manual work of combining the view with the data access controls with the view of the transactional data. The wizard creates a ready-made “Protected view” of the data model in which the data for the users has already been restricted in accordance with the data access controls of the DWC. This view can then be consumed for the reporting.
We look at the data in the DWC as follows to make the test case clearer. Let us first of all take a look at the transactional sample data.
Figure 8: Transactional data in the DWC
The authorizations listed below (Figure 9), which display the authorization data currently held in the DWC, are to serve as a basis, together with the transactional data from above, for the protected view. As we can see, only access to ZCA_LAND = DE and ZCA_ORG = DE02 is authorized. That would only include three data sets from the transactional data shown above.
Figure 9: Replicated data access control data for the test user in the DWC
What does the generated view look like in the DWC then? This view can be clearly seen in the designation and in the technical name in the view mode of the Data Builder.
Figure 10: The generated restricted view in the Data Builder of the DWC
If we now look at this view in detail, we can see, in addition to the generated SQL script, that data access controls had been generated (Data Access Controls in the right-hand pop-up). The data preview shows that the logged-in user can only see data for ZCA_LAND = DE and ZCA_ORG = DE02.
Figure 11: The data preview in the restricted view in the DWC
It is thus possible to use the data preview to test the effects of the authorizations in the DWC. In addition to replication of the data after a change in the BW/4HANA system, only the user needs to be specified in the extraction report, which is then used in the DWC as well.
If the DWC is not used as a standalone system but instead in connection with existing SAP BW/4HANA (or S/4HANA) systems, then the question of comprehensive reporting crops up sooner or later. Using the option described here, which SAP offers by default, this makes available another option for reporting in the DWC. If you have successfully avoided the problems listed above, such as the installing of the OSS notes or the conversion of the UserIDs, then you have a very useful tool available. This then provides an option on the basis of an SQL script that makes it possible to use the vast majority of analysis authorizations of the established BW/4HANA system in the DWC as well. There are (currently still?) only any restrictions regarding the implementation in just a few special cases. Thus, a further module is available for an overall authorizations concept – but the precise conceptualization and observations will be the topic of a future blog.