Oracle Business Intelligence Applications Human Resources Analytics V. 7.9.6, 7.9.6.

1 How to Secure Employee Dimension

An Oracle Technical Note October 2009

Table of Contents INTRODUCTION ........................................................................................................3 SOLUTION OVERVIEW ...........................................................................................3 PROPOSED CHANGES: ............................................................................................4 ETL Changes: .................................................................................................................4 RPD Changes..................................................................................................................9

How to Secure Employee Dimension

INTRODUCTION HR Analytics secures user data access using security filters applied to fact tables. These security filters restrict a users access to a subset of the data based on his or her security profile by the securable dimensions e.g. organization, supervisor hierarchy or business group. As delivered, Employee dimension itself is not a dimension that is secured by users security profile. This means when a user browses Employee dimension directly without selecting a metric that is secured by one of the securable dimensions, he or she will see all people in the Employee dimension regardless of his/her security access. However, it is important to point out that a user's data security will be applied once the user includes one or more metrics along with the Employee dimension attributes. By combining metrics with the Employee dimension, it indirectly secures the Employee dimension through the logical join between Employee dimension and the secured fact tables. However, if your implementation requires securing the Employee dimension so that a user can only view people within his/her security access when he/she browse the Employee dimension directly. This document explains the implementation steps on how to secure the Employee dimension. SOLUTION OVERVIEW Employee dimension security supports the following scenarios: 1. A user needs to be granted access to employee data in the organization they belong to. The user should be able to view all employees under this organization. 2. If the user is a manager and is granted access via the manager hierarchy, the user should be able to see all employees under his reporting hierarchy. 3. The list of employees seen by a user is a superset of the above two grants.

IMPLEMENTATION STEPS: Both ETL and RPD changes are required for securing the employee dimension via organization hierarchy as well as via manager hierarchy (also known as position hierarchy in 7.9.6).

ETL Changes:
Existing columns VIS_PR_BU_ID, VIS_PR_POSTN_DH_WID in W_EMPLOYEE_D will be used to drive the employee dimension based security. VIS_PR_POSTN_DH_WID is currently populated in 7.9.6. However VIS_PR_BU_ID is not populated in the 796 code line for the EBS and PSFT adapters. ETL changes need to be made to populate the VIS_PR_BU_ID in W_EMPLOYEE_D. The following steps are to make this change for the EBS adapter: 1. Modify the mapplet mplt_BC_ORA_EmployeeDimension. Take the column Organization_id from the source qualifier all the way to a new output port ORGANIZATION_ID 2. Take this all the way to the output column W_EMPLOYEE_DS.VIS_PR_BU_ID. PSFT customers need to modify the corresponding SDE_PSFT% maps to make sure W_EMPLOYEE_DS.VIS_PR_BU_ID is populated with the HR business unit the employee belongs to. W_PSFT_EMPLOYEE_D_JOB_INFO_TMP need a new column called BUSINESS_UNIT. This column needs to be sourced from PS_JOB.BUSINESS_UNIT. The mapping that loads W_PSFT_EMPLOYEE_D_JOB_INFO_TMP is SDE_PSFT_EmployeeDimension_JobInformation. This needs to be modified to bring this column from source to target (modify source qualifier and bring column all the way to target). Then the map SDE_PSFT_EmployeeDimension needs to be modified to map the column W_PSFT_EMPLOYEE_D_JOB_INFO_TMP.BUSINESS_UNIT to the target column W_EMPLOYEE_DS.VIS_PR_BU_ID. Detailed instructions with screenshots are provided for the EBS Adapter. ETL Changes for EBS Adapter: Step 1: - Open the SDE_ORA1158_Adaptor in your OBIA 7.9.6 Informatica Repository (AA_796).

Note: - Checkout the corresponding objects for step 2, 3 and 4 to make changes. Step 2: - Drag the mapping SDE_ORA_EmployeeDimension to the mapping designer.

Step 3: - Open the mapplet mplt_BC_ORA_EmployeeDimension for modification.

Find the column ORGANIZATION_ID in the Source Qualifier

Drag (it automatically maps) the ORGANIZATION_ID column in the Source Qualifier through Exp_EmployeeDimension expression to ORGANIZATION_ID column (New output port)Output Output transformation

Step 4: - Open the mapplet mplt_SA_ORA_EmployeeDimension for modification.

Add a new Input Port INP_ORGANIZATION_ID to Input Input Transformation and create link between ORGANIZATION_ID column from mpl_BC_ORA_EmployeeDimension with INP_ORGANIZATION_ID from mplt_SA_ORA_EmployeeDimension. Add a new Input Port INP_ORGANIZATION_ID with DataType Decimal, Precision 15 and Scale 0, make sure that the output CheckBox Ois unchecked Map Input Port INP_ORGANIZATION_ID to the EXT_VIS_PR_BU_ID Output Port of Exp_SA_Employee Expression with column expression TO_CHAR (INP_ORGANIZATION_ID).

RPD Changes
RPD changes need to be done in two parts. The first part secures employee dimension using manager hierarchy (also known as position hierarchy in 7.9.6). The 2nd part secures the employee dimension using the employee organization. Note: - Check Global Consistency before saving the changes to ensure No errors are introduced. Part 1: Securing employee dimension via Manager Hierarchy Step 1: - Navigate to Dbo schema.

Step 2: - Create a new physical alias Dim_Vis_W_POSITION_DH_Employee_Security on W_POSITION_DH

Step 3: - Create a physical join between Dim_W_EMPLOYEE_D Dim_Vis_W_POSITION_DH_Employee_Security by joining

and

Dim_Vis_W_POSITION_DH_Employee_Security.ROW_WID = Dim_W_EMPLOYEE_D.VIS_PR_POSTN_DH_WID

Select Dim_W_EMPLOYEE_D and Dim_Vis_W_POSITION_DH_Employee_Security table and right click to open

10

window for Physical Diagram for selected Objects only.

Click the Complex Join Icon on Toolbar. Create a link from Dim_W_EMPLOYEE_D to Dim_Vis_W_POSITION_DH_Employee_Security table. Select the given columns form each table for complex join in Physical Join window.

We should see a link pointing from Dim_W_EMPLOYEE_D to Dim_Vis_W_POSITION_DH_Employee_Security table after clicking ok.

Step 4: - Edit the logical dimension Dim Employee. Edit the LTS and add the join to Dim_Vis_W_POSITION_DH_Employee_Security to the LTS.

11

In BMM Layer, open Business Model, Core, and Navigate to logical dimension Dim Employee to additional, New Logical Table Source.

Logical Table Source window pops up, Click Add, to browse the new LTS to be added in a new Browse window. Name the LTS as Dim_Vis_W_POSITION_DH in the Logical Table Source window to save.

Step 4: - Drag and drop Current_Base_Login to Current_Top Login including all 16 levels columns from Dim_Vis_W_POSITION_DH_Employee_Security table in Physical Layer to Dim_Employee table in BMM Layer.

12

Step 6: - Rename all the columns dragged, CURRENT_BASE\TOP_LOGIN to Base\Top Current Login and all level columns to Level X Current Login, where X is the nth level being renamed. Step 5: - Create new logical column Hierarchy_Based_Login using the following expression: INDEXCOL( VALUEOF(NQ_SESSION."HIER_LEVEL"), "Core"."Dim Employee"."Base Level Current Login", "Core"."Dim - Employee"."Level 1 Current Login", "Core"."Dim - Employee"."Level 2 Current Login", "Core"."Dim Employee"."Level 3 Current Login", "Core"."Dim - Employee"."Level 4 Current Login", "Core"."Dim - Employee"."Level 5 Current Login", "Core"."Dim Employee"."Level 6 Current Login", "Core"."Dim - Employee"."Level 7 Current Login", "Core"."Dim - Employee"."Level 8 Current Login","Core"."Dim Employee"."Level 9 Current Login", "Core"."Dim - Employee"."Level 10 Current Login", "Core"."Dim - Employee"."Level 11 Current Login", "Core"."Dim Employee"."Level 12 Current Login", "Core"."Dim - Employee"."Level 13 Current Login", "Core"."Dim - Employee"."Level 14 Current Login", "Core"."Dim Employee"."Level 15 Current Login", "Core"."Dim - Employee"."Level 16 Current Login", "Core"."Dim - Employee"."Top Level Current Login") Include all 18 levels.

13

Step 6: - Confirm if the initialization block called Employee Hierarchy Level exists (The following SQL should be defined for some initialization block, may be by different name.):
SELECT round(FIXED_HIER_LEVEL) FROM VALUEOF(OLAPTBO).W_POSITION_DH WHERE BASE_LOGIN= ':USER' AND CURRENT_FLG='Y' .

14

Ensure if the SQL is correct or not? And if the initialization Block is not disabled? If disabled, enable it. In the given screen shot, User Hierarchy Level initialization block is defined with same SQL.

Step 7: - Confirm if the session variable HIER_LEVEL to source from the init block in step 6

Step 8: - Create a new security group called HR Employee-based Security. This security group will contain the data access permission filters.

15

Step 9: - Create the data filter on the security group created in step 8 as follows: "Core"."Dim - Employee"."Hierarchy Based Login" = VALUEOF (NQ_SESSION."USER")

Step 10: - During implementation, customers need to decide which users or groups should be associated to this security group.

16

Part 2: Securing employee dimension via Employee Organization Step 1: - Add column Employee Org to logical dimension Dim Employee coming from physical column Vis_PR_BU_ID.

Step 2: - For PeopleSoft, Confirm if session variable HR_ORG exists and the init block associated with it is enabled. Session variable HR_ORG returns the current HR organization to which the corresponding login user belongs, based on his/her primary job. (Refer to 1st and 2nd screen shot in this step). For EBS, the Initialization Block HR Organizations (If disabled, enable it) is defined Row Wise Initialization and does not require session variable.

17

Step 3: - Editsecurity group called HR Employee based Security(Created in RPD changes Part 1). This security group will contain the data access permission filters.

Step 4: - Edit the data filter on the security group in Step 3 (HR Employee based Security) as follows:

18

OR "Core"."Dim - Employee"."Employee Org" = VALUEOF(NQ_SESSION."HR_ORG")

Step 5: - During implementation, customers need to decide which users or groups should be associated to this security group.

19