Dynamic Security Using OrgUnit Hierarchy

[arun_purohit]

1       Objective

Maintaining security roles for large group of end users is always a challenging task. Hence it is required to develop solution with dynamic reporting security. In this case security requirements are based on OrgUnit hierarchy hence solution is for BW reports based on OrgUnit hierarchy.

Main idea is if A OrgUnit is assigned to user U1, then he should be able to access data of this OrgUnit & all child OrgUnits.

2       Brief Overview of Solution

Following are the parts of solution for making reporting security dynamic:

Z Table in ECC

This is required for maintaining ad-hoc OrgUnit assignments for accessing data for additional OrgUnits temporarily. This Z table will be loaded in a DSO in BW via table based datasource.

Extractor for OrgUnit Assignments

This extractor will bring OrgUnit assignments from HRP1001 & PA0001 for two type of users. HRP1001 will give OrgUnit assignments of users who are chief or manager of specific OrgUnits & PA0001 (Only specific designations will be considered based on requirements) will provide OrgUnit assignments of specific employees.

DSO in BW

This DSO will store data from two datasources mentioned above. This DSO will be referred by BW queries on run time to manage security.

BEx Variables

For making this dynamic security work, 2 Variables are added on OrgUnit:

       Input Ready

This variable V1 is used in “Default Values” section in filter pane. For this variable we have implemented a standard BADI for restricting F4 help values based on security.

       Customer Exit (No Input Ready)

This variable V2 is used in “Characteristic Restrictions” section of filter pane. It is customer exit variable, non-ready to input and to be processes in i_Step = 2. This variable will read values from other OrgUnit input ready variable and following is its logic flow:

If V1 variable is kept blank, this customer exit will be populated with authorized values of OrgUnit for the current user. Else if something is selected in V1, it will be validated in V2 and processed accordingly. More details in following sections of the document.

3 Z Table in ECC

This Z table is required to maintain ad-hoc OrgUnit assignments for reporting data at higher levels. For e.g. an end user may need to report data to (C level or Partner level) sometimes, for that he may need access to reports on OrgUnits which are not assigned to him in actual OrgUnit hierarchy in ECC, in these cases that user will be assigned required OrgUnits for specific period of time.

Maintenance generator is created for the table and table will be maintained via tcode and tcode will be assigned in security roles of specific people of application support team only.

Following is the structure of the table:

 

Here, start & end date will restrict the access to specific ad-hoc OrgUnit assignment to specific period of time.

3.1 Tcode for table maintenance

Maintenance Generator Created for table for maintenance followed by creation of tcode for its maintenance in SE93:

 

There is a table based generic datasource on this table.

4       Extractor for OrgUnit Assignments

This is a function module based generic datasource, based on client specific OrgUnit configuration it queries on HRP1001 table with filters on otype, sclas, rsign & relat to bring one set of users & corresponding OrgUnit assignments. Second set of reporting users is derived based on PA0001 based on senior executives or partners.

4.1 Extract structure for this datasource

4.2 Code Snippets

Attached ds code.

5 DSO in BW

DSO in BW is mapped from both the datasources discussed in sections 3 & 4.

5.1 DSO Structure

 

6 BEx Variables

6.1 Input Ready Variable

We have implemented BADI for restricting F4 help values of this variables based on current user executing the report via look up on security DSO. This variable is used in “Default Values” section of filter pane.

6.1.1 Location of BADI

SPRO >> SAP NETWEAVER >> Business Warehouse >> Enhancements >> BAdI: Restricting the Value Help in the Variables Screen

6.1.2 Process of Implementing BADI for F4 Help Restriction

Clicking on highlighted part of above screen shot will take you to following screen:

Hit create button in above screen & then enter first two parameter (Name of new object) following pop-up-

Enhancement Implementation will be created:

Click on highlighted area in screenshot above “Implementing Class”-

 

Since we need to apply F4 help restriction on HierarchyNode variable, we need to select second method in screenshot above (*_NODE).

1. Code

Attached file.

6.1.3 Expected output of F4 Restriction based on Sample Values

 

Blue colored OrgUnits are assigned to user in BW DSO. Hierarchy shown on left side is main OrgUnit hierarchy and the one on right side is after applying code.

Using F4 help restriction, user cant make selection on those strands of hierarchy which doesn't have any of assigned OrgUnits, but he can still select OrgUnit which is parent of OrgUnit(s) assigned to him. To take care of this scenario, we created customer exit variable (i_step = 2), more details in next section.

6.2 Customer Exit (No Input Ready)

This is non-input ready customer exit variable to be processed in i_step = 2. This variable is used in “Characteristic Restrictions” section of Filter pane.

As discussed in last part of previous section, even after applying F4 help restriction, user can still select OrgUnit which is parent of OrgUnit he is assigned to. These kind of scenarios are handled in this customer exit code. Basically following are two reasons of having this additional variable on OrgUnit:

1. a)     If user selects nothing in “input ready variable”, then this customer exit will pass all OrgUnits from security DSO in BW in second Variable V2. Which means, user will see data only for the OrgUnits assigned to him.
2. b)    Validate selection made by user in variable V1. If user has selected something he is not authorized for then pass error.

6.2.1       Code of the Customer Exit (Class --> Method)

Code is not written directly in CMOD, but instead using interface class in CMOD, code is written in class specific to the variable V2.

Attached file.

7 Conclusion

7.1 Dynamic Security for BW Reporting

1. Simple roles are required for users restricting them to specific Infoarea, Infoproviders & BEx queries (using Wild Characters).
2. In security roles need not maintain OrgUnit values, which may change based on employee’s position changes.
3. If a User is moved in OrgUnit hierarchy in ECC based on HR actions (Promotion or Transfer), this change will come to BW DSO automatically and end users reporting authorizations are automatically taken care of.
4. If any user needs ad-hoc OrgUnit assignments, just need to maintain Z table with validity dates for ad-hoc assignment and rest all taken care post loading the table in BW.

7.2 Brief of Functioning

If user doesn't enter anything in input ready variable, second customer exit variable will filter report based on OrgUnits assigned to the user.

If user selects something in first input ready variable (where F4 help restriction is applied), second variable will validate security based on OrgUnit assignments.

8 References

F4 Help Restriction

http://wiki.scn.sap.com/wiki/display/BI/F4+BADI+RESTRICTION+NODE

http://wiki.scn.sap.com/wiki/display/BI/F4+BADI

http://scn.sap.com/community/data-warehousing/bw/blog/2010/09/30/howto-restrict-f4-help-values-for-h...