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.
Following are the parts of solution for making reporting security dynamic:
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.
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.
This DSO will store data from two datasources mentioned above. This DSO will be referred by BW queries on run time to manage security.
For making this dynamic security work, 2 Variables are added on OrgUnit:
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.
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.
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.
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.
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.
Attached ds code.
DSO in BW is mapped from both the datasources discussed in sections 3 & 4.
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.
SPRO >> SAP NETWEAVER >> Business Warehouse >> Enhancements >> BAdI: Restricting the Value Help in the Variables Screen
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).
Attached file.
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.
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:
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.
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.
F4 Help Restriction
http://wiki.scn.sap.com/wiki/display/BI/F4+BADI+RESTRICTION+NODE
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
6 | |
5 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 |