Integrating with EPM Warehouse Security
The EPM Warehouse security defines:
Users.
Roles.
A user may be a member of one or more roles. A role typically has more than one user.
Dimension access rules.
These access rules define who may access a dimension and members of a dimension. The rules may be defined for a role or for a user. A role or a user may be allowed to access only certain members of a dimension.
Access rights for a user are the combined access provided to them by their membership in roles.
To set up secured access for a dimension in the warehouse, the security administrator defines the access rules and then executes a batch program that processes the rules into flattened security join tables (SJTs). These tables are then queried by EPM applications to determine what data is accessible by a certain user.
Planning and Budgeting has its own set of security tables that contain information about users and their access rights. To leverage the warehouse security in Planning and Budgeting, we deliver a batch program (Request Security Processing) that accesses the SJTs and updates the Planning and Budgeting security tables with the same information. You must execute the Planning and Budgeting batch program after the warehouse security program has modified the SJTs.
To that end, you:
Define a jobstream containing both the warehouse and the Planning and Budgeting security batch processes, using the Jobstream page
Image: Jobstream page
This example illustrates the fields and controls on the Jobstream page.
Run the jobstream from the Request Security processing page
Image: Request Security Processing page
This example illustrates the fields and controls on the Request Security Processing page.
The EPM batch process performs the following steps:
Processes all warehouse dimensions or the dimension given as a parameter on the security run control page.
For each warehouse dimension (OWE only), it attempts to find a matching dimension in the Planning and Budgeting application by querying the PS_BP_EW_DIM_MAP table.
If it finds a dimension, it queries the PS_BP_ACTIVITY table to determine if the dimension is secured in the Planning and Budgeting application. Warehouse dimensions can only be used to secure secondary dimensions on an activity. The warehouse dimension security cannot be used for planning center dimensions.
It then accesses the SJT for the corresponding warehouse dimension.
It creates a secondary security group in Planning and Budgeting for this dimension. It tags the secondary security group as a warehouse security group. The name of the secondary security group is specified in the mapping table PS_BP_EW_DIM_MAP.
The secondary security groups are keyed by setID. The setID is determined by the business unit or the setID of the dimension values in the SJT.
It creates the secondary security group with an effective date of 01-01-1900. This effective date is updated every time you run the batch process. Note that if you create a new effective date for the warehouse security groups, the batch program still applies the 01-01-1900 definition.
For each role found in the SJT, the program determines all the users belonging to that role, and then inserts a detail row in the secondary security group for each user. It gives the user read-write access by default.
The update to the secondary security groups is destructive in nature, that is, all the rows from the secondary security group are deleted and inserted again. The only exception to this rule is if the secondary security group has been modified in Planning and Budgeting to change the access rights from read-write to read-only. In that case, the modified access rights are retained so you don't have to reapply your changes.
If an access privilege exists in the Planning and Budgeting secondary security group, but it has been deleted from the warehouse, then the batch process also deletes the privilege from Planning and Budgeting. This happens even if the Planning and Budgeting privilege has been modified to read-only.
Note: Any security access granted to a user ID applies to all planning centers for that user. Additionally, there is no need to run the security processing program by business unit because security is run at the setID level.