2. About the Speakers
Giampaoli, Ricardo
● Master in Business
Administration and IT
management
● Founder of TeraCorp
Consulting
● 18 year working with IT and
the last 8 years as an EPM
solution architect
● EPM training instructor
● Essbase/OBIEE/ODI
Certified Specialist
● Blogger @ devepm.com
Radtke, Rodrigo
● Graduated in Computer
Engineering
● Software Developer Advisor at
Dell
● Ten years working with IT and
the last five as ETL architect
● ODI, Oracle and Java Certified
● Blogger @ devepm.com
About
3. TeraCorp is a company specialized in products
and services focused on EPM
TeraCorp mission is to create innovate
solutions that helps people, businesses and
partners to exceed their goals reaching their full
potential.
Learn more @ www.teracorp.com.br/en
About TeraCorp
About
4. Knowledge on:
● ODI
● Hyperion Planning
● SQL
Pre-Requisites
Pre-Requisites
6. Business Needs
The Study Case
One Cube with an Entity dimension containing all
22000+ cost center in the world
Security must be granted in such way that an user
from a region can only see data from their cost
centers
The parents aggregation should display only the
sum of data that the user has access
Cost center from different regions under the same
parent
Cost center region defined by an attribute
dimension
7. Hyperion Planning Security
Is Security Robust and Flexible?
● Cannot use attribute dimension to define security
Access control at Leaf level?
● How to provide and maintain security at leaf level in
dimensions with 22000 + cost centers?
● How to handle cost centers that change its region?
Use Microsoft Excel to generate all necessary
security combinations?
● What’s the cost to maintain such a file in a fast
changing business structure?
Planning Security
8. A Region dimension to split the
data by the world regions and
provide the right aggregation in
parent levels.
Cost Center Region defined by an
attribute dimension.
● The EMEA users needs to have
access only to Cost Centers with
support geography that belongs to
SUPP_EMEA and only to the EMEA
Region.
Aggregation Solution
Solution Choice
9. Read the Planning application repository to
dynamically build the Entity dimension security
based in the geography attributes and the
groups associated in the Entity Upper level
members
Security must be granted “bottom-up”
Security Solution
Solution Choice
10. The security must be granted for all users or groups in the
high level members (e.g. Entity gen1 or/and gen2 members).
The relation must be set as “Member”).
The Entity members attributes and the Support Geography
hierarchy
The users or groups names should have a relationship
between it and the attribute member.
Pre Requisites
Planning Security
Groups
11. All information exists in the Planning repository.
Seven tables were used to build this solution.
● Three security tables
● Three Attribute tables
● One object table
Planning Repository Overview
Planning Repository
12. Security is define using three tables:
● HSP_USERS
● Only used if an user is assigned directly to an object in
planning
● HSP_GROUP
● Only used if a group is assigned directly to an object in
planning
● HSP_ACCESS_CONTROL
● Is used to associate an user or group to an object and also
inform what access it will have to it and if this access will be
spread to its children or only on it
Security Tables
Planning Repository
13. Security Tables
Column Name Description
GROUP_ID
The group id that is created after an user that belongs to a
group login or a group is assigned to any object in Hyperion
planning.
SID The native or external directory ID
Column Name Description
USER_ID
The user id that is created after an user login or is assigned to
any object in Hyperion planning.
SID The native or external directory ID
HSP_USERS
HSP_GROUP
Planning Repository
14. Column Name Description
USER_ID
The user or the group id that is created after a group or an user is
assigned to any object in Hyperion planning.
OBJECT_ID The ID of the object that has been granted the security
ACCESS_MODE
The type of access that an user or a group can have on an object:
1 = Read 3 = ReadWrite -1 = Deny
FLAGS
Essbase access flag, determines if an user or a group has access
only to that object or to the hierarchy below it:
0
Member
5
@Children
6
@IChildren
8
@Descendants
9
@IDescendants
Security Tables
HSP_ACCESS_CONTROL
Planning Repository
15. Attributes is define using three tables:
● HSP_ATTRIBUTE_DIM
● Stores all attribute dimensions
● HSP_ATTRIBUTE_MEMBER
● Holds all attribute members stored in planning
● HSP_MEMBER_TO_ATTRIBUTE
● Joins the attributes with the members of a Dimension
Attribute Tables
Planning Repository
16. Attribute Tables
Column Name Description
ATTR_ID ID of the Attribute dimension.
DIM_ID The ID of the dimension that the attribute is associated
HSP_ATTRIBUTE_DIM
Planning Repository
Column Name Description
ATTR_MEM_ID ID of the Attribute member.
ATTR_ID ID of the Attribute dimension.
HSP_ATTRIBUTE_MEMBER
17. Attribute Tables
Planning Repository
Column Name Description
MEMBER_ID ID of the member that has been assigned an attribute.
ATTR_ID ID of the Attribute dimension.
ATTR_MEM_ID ID of the Attribute member.
HSP_MEMBER_TO_ATTRIBUTE
18. Planning objects is define using one table:
● HSP_OBJECT
● Contains the Metadata from all Planning objects as well the
parent member relationship used to create all metadata
structure.
Object Table
Planning Repository
19. Column Name Description
OBJECT_ID Object ID for all objects in planning.
OBJECT_NAME Stores all metadata description in Planning (e.g. Alias, Members)
OBJECT_TYPE Type of the Object (e.g. Entity, Account, Attribute…)
PARENT_ID
Parent ID of the object. Used for build the parent/child relationship
with OBJECT_ID
GENERATION Inform which generation that object belongs.
HAS_CHILDREN Inform if the object has or not a child
Object Tables
HSP_OBJECT
Planning Repository
20. Entity Hierarchy
Building Solution
Extract the Entity Dimension
members and their attributes
from Planning Repository
● Use connect by nocycle prior to
rebuild the hierarchy from bottom
up
21. Building Solution
Support Geography Hierarchy
Extract the Support Geography Attribute
Dimension Hierarchy from Planning Repository
● Use connect by prior to rebuild the hierarchy
23. Building Solution
Users/Groups Security
Extract the generation 1 and 2 members and their
security groups from Planning Repository
● Generation 1 is Channel and contains all groups that has
access to everything
● Generation 2 are the Business segments and contains all
groups that has access only to that segment
24. Join the queries by LIKE of REGION_NAME
Building Solution
Join 2: Adding Security Groups
26. Join Parent_ID from Generation 1 or 2 and Entity_ID
Join 3: Putting Everything Together
Building Solution
27. Why ODI?
Building Solution
Full flexible development platform
● Tweak KMs and procedures to create
dynamic processes
● Virtually accepts any existing technology
Complete execution platform
● Built in security (Only key users can use it)
● Easy to be used by Users
● Automatize, schedule and control jobs
● Complete log information
28. Two ways to do it:
● Solution 1: Generate a Secfile and run a command
line in the end of the ODI process to load it into
Planning (using ImportSecurity utility)
● Solution 2: Insert the security directly into
HSP_ACCESS_CONTROL table
Solution Design Choices
Building Solution
ImportSecurity Insert into Repository
No clear control (clear all or nothing) Clear any type of security based in
any rule (delete clause + repository)
No service restart Service restart
No repository manipulation Repository manipulation
29. ImportSecurity utility loads access permissions for
users or groups from a text file into Planning
ImportSecurity
Parameter Description
[-f:passwordFile] Optional: If an encrypted password file is set up, use as the first parameter in the
command line to read the password from the full file path and name specified in
passwordFile.
appname Name of the Planning application to which you are importing access permissions.
username Planning administrator user name.
delimiter Optional: SL_TAB, SL_COMMA, SL_PIPE, SL_SPACE, SL_COLON, SL_SEMI-COLON. If
no delimiter is specified, comma is the default.
RUN_SILENT Optional: Execute the utility silently (the default) or with progress messages. Specify 0 for
messages, or 1 for no messages.
[SL_CLEARALL] Optional: Clear existing access permissions when importing new access permissions. Must
be in uppercase.
ImportSecurity.cmd [-f:passwordFile] “appname,username,[delimiter],[RUN_SILENT],[SL_CLEARALL]”
Solution 1
30. Item Description
username or group name The name of a user or group defined in Shared Services Console.
artifact name The named artifact for the imported access permissions (for example the member,
data form, task list, folder, or Calculation Manager business rule).
access permissions Read, ReadWrite, or None. If there are duplicate lines for a user/member
combination, the line with ReadWrite access takes precedence.
Essbase access flags @CHILDREN, @ICHILDREN, @DESCENDANTS, @IDESCENDANTS and
MEMBER.
artifact type For artifacts other than members, distinguish which artifact you are importing
security for with artifact type identifier.
The SecFile.txt contain the access permissions
for users or groups and should have the
following format:
SecFile.txt
Solution 1
31. Importing access permissions overwrites
existing access assignments and the
SL_CLEARALL parameter clears all existing
access permissions giving us two options:
● (1.1) Load only the new security and manually delete
the old undesired access (Sent by email through the
interface)
● (1.2) Clear all Security with SL_CLEARALL and then
load all access from all dimensions back to Planning
(Entity + All other existing security)
Design Decision
Solution 1
32. Solution 1.1
Load only new security to SecFile.txt
● Using two datasets to generate a Minus between the
new and the existing security
Generating SecFile.txt
33. Solution 1.1
Load all old security to OldSecurity.txt
● Using two datasets to generate a Minus between the
existing security and the new generated access
Generating Old Security File
34. Solution 1.2
Load ALL security to SecFile.txt
● Using two datasets to generate an Union between
the new and the existing security
Generating Full SecFile.txt
35. Use a ODI Procedure to run a CMD command
on Planning Server and import security
Import Security
Solution 1
41. Ricardo Giampaoli – TeraCorp
Rodrigo Radtke de Souza - Dell
Thank you!
Thank You
Editor's Notes
Ricardo:
Present himself
Rodrigo:
Present himself
Ricardo:
TeraCorp is a company specialized in products and services focused on EPM
we are working to create epm products to help the developing process, maintenance efforts and performance improvement.
We want to create a smarter epm environment.
TeraCorp mission is to create innovate solutions that helps people, businesses and partners to exceed their goals reaching their full potential.
For a better understanding of this session is good to have a
1) Advanced Knowledge of ODI
2) Good Knowledge of Hyperion Planning
3) Good Knowledge of SQL
Or agenda will cover
Business Needs
Hyperion Planning Security
Planning Repository
Building Solutions
Dell’s Environment
QA
Before this project we had at dell 5 big planning applications. Three of then was splitted by region (amer, apj and emea) one wwops and one RUM application (Revenue Under Management). Each of this application had their own set of cost centers. Even the RUM app was splitted the cost centers by cubes (one cube per region).
In this project the requirement of the business was to create a new RUM app that will contain all cost centers from all regions (22000+) in the same cube.
Security should be granted in a way that the user can only see the cost center of their region.
Also the aggregation in the parent level should respect the user access, that’s mean, if under a parent we have 3 children each one from a different region and the user have access only to amer, he have to see only the amer amount in the parent level.
The trick part is that we could have cost centers from different regions under the same parent and the only way to identify the cost center region is using the support geography attribute dimension.
There is no doubt that Hyperion Planning security is robust and extremely flexible.
Well this statement is true, but not 100% accurate because planning don’t allow us to use attribute dimensions as a filter in the security. But is true because we can create the security by ourselves using some external tools as importutility tool or even with repository manipulation. The problem is how to create a process to handle a fast change environment and easy enough to be maintained?
I Already saw in other projects companies generating the security file using excel but with more than 22000+ cost centers and more than 70 security groups it’s get a little harder to maintain such a file.
For the aggregation part a region dimension will solve the problem (when the users input data in a amer cost center he’ll need to select the amer region as well).
The security is pretty simple in this dimension, all groups that has access to amer are granted the amer region access, the same for the other regions and for users with global access we grant access to total region and descendants. Also we used the planning conditional format to black out the form if a invalid combination of cost center and region is chosen.
We can see that the gen 1 of support geography has the region name on it, making easy to identify and create any role based on it.
The problem is how to create the security in the entity dimension using an attribute dimension as filter and knowing that under a parent we could have cost centers from different regions.
The solution is right under Planning! In its repository.
Querying the planning application repository we can build the entire security from bottom up and create the sec file or even populate the security tables with the new security using any type of rule imaginable.
And the best part is: it’s 100% dynamic, meaning almost 0 maintenance work.
How it will work. Basically we need to know 3 things:
The entities members and their support geography attribute:
The Support geography hierarchy to find out what region that attribute belongs
And The security groups that we need to grant access.
For the security groups we need 2 things:
First is to have in their name the region what it’s belongs (it’ll be used in the query to join the groups with the cost center attributes).
Second we need to grant security at gen 1 and gen 2 of entity hierarchy.
Gen1 will be the all channel access groups but restricted by region
Gen2 will be the groups that has access only to a Business segments plus a specific region.
Also the access flag should be set as member (because we’ll gran access member by member and we don’t want any Idescendants in any parent)
And the access mode granted for this groups will be used when we spread the security through the hierarchy.
This will give to our query the main lines to build the security (what channel or business segment that user will have access and what region it’ll have access)
Ok now we need to know how to get it:
We have all the information regarding a planning application in its repository.
For build the security we’ll need to query 7 tables:
3 tables to get the groups/users and the actual security
3 tables for the attribute hierarchy
1 table to get the metadata information
Planning stores all its security in three table:
Hsp_Users where it’s store all users that has access to planning
Hsp_group where it’s store all groups that has access to planning
And Hsp_access_control where planning stores all information regarding the objects and their grants.
The HSP_USERS and HSP_GROUP tables have the same structure, both have a ID that changes depending of the table but in both case they are created after a user login or after they are granted access in any object in planning
Also both have the SID that’s the native or external directory ID
The HSP_ACCES_CONTROL is the table that stores all security for all objects in planning.
It contains the USER_ID (this columns stores the IDS for both HSP_USERS or HSP_GROUP)
The OBJECT_ID, that’s the ID of the objects that received the grant
The ACCESS_MODE, if the user will have read, readwrite or deny access to a object
And FLAGS that tell planning if that user will have access only to that object or for their children.
For the Attributes planning stores then in 3 tables:
HSP_ATTRIBUTE_DIM Stores all attribute dimensions (the dimension it self! If your planning application have 3 attribute dimension this table will have 3 rows)
HSP_ATTRIBUTE_MEMBER Holds all attribute members stored in planning
HSP_MEMBER_TO_ATTRIBUTE Joins the attributes with the members of a Dimension
For HSP_ATTRIBUTE_DIM we have ATTR_ID that’s the ID of the attribute dimension
And DIM_ID that’s The ID of the dimension that the attribute is associated
For HSP_ATTRIBUTE_MEMBER we have ATTR_MEM_ID that is the ID of the Attribute member and ATTR_ID that is the ID of the Attribute dimension. (here we can figure out what attribute member belongs to what attribute dimension.
And for HSP_MEMBER_TO_ATTRIBUTE we have MEMBER_ID that is the ID of the member that has been assigned an attribute.
ATTR_ID that is the ID of the Attribute dimension
And ATTR_MEM_ID ID of the Attribute member
This table tell us what member have what attribute from what attribute dimension.
And finally we have HSP_OBJECT table that Contains the metadata from all Planning objects as well the parent member relationship used to create all hierarchy structure.
This table has some other columns but these are the important one for us.
The OBJECT_ID stores the ID for all objects in planning
OBJECT_NAME Stores all metadata description in Planning (e.g. Alias, Members, folders, forms)
OBJECT_TYPE store the Type of the Object (e.g. Entity, Account, Attribute, folder, forms…)
PARENT_ID stores the Parent ID of the object. This is used for build the parent/child relationship together with OBJECT_ID
GENERATION Informs which generation that object belongs.
HAS_CHILDREN Inform if the object has or not a child
Ok now let’s start to build our query.
First we need to get all members from the entity dimension with their attribute.
This will be used as the foundation to our query. Its important to spread the leaf attribute to their parents, this way we will be able to join this sub query even in the parent level with the support geography sub query to get the region of the attribute associated with the entity leaf member to the entire hierarchy.
To do so we need to rebuild the parent/child relationship in the HSP_OBJECT table and how we need the leaf attribute spread for all its parents we will need the rebuild the hierarchy bottom up. We need to do that because we’ll use the CONNECT_BY_ROOT operator, that’s used to bring the ROOT information from the hierarchy (the beginning point), and inverting it, it going to bring the leaf member.
To do so we’ll query the HSP_OBJECT Table using a CONNECT BY NO CYCLE with OBJECT_ID prior PARENT ID to rebuild the entity hierarchy from bottom up. We need to use the NOCYCLE operator because we inverted the CONNECT BY PRIOR relationship and if we not use the NOCICLE it’ll loop the query for ever.
Also, Because we inverted the CONNECT BY function, the starting point for this query will be all leafs members from Entity dimension instead of the top level member and for that we going to create a sub query in the START WITH operator (This function is what defines the starting point of the CONNECT BY function) filtering the OBJECT_TYPE 33, that’s Entity type ID and HAS_Children = 0 to get only the leaf members.
We can see in this example that the entity 223281 has the support geography attribute “SUPP_Netherlands” and this attribute was spread to the leaf parents until the top of the hierarchy as well the leaf_name for all hierarchy levels.
Ok now we need to get the Region information from the support geography attribute dimension
Since the region information is the top level of the support geography we need to rebuild the entire hierarchy to figure out all region of all attributes.
This sub query is different from the Entity sub query (that was a bottom-up query) because here we need to figure out the Parent information from the hierarchy.
We going to use the same strategy as before, a Connect by prior in HSP_OBJECT table but we’ll using PARENT_ID prior OBJECT_ID (the opposite order then the previous sub query) in order to retrieve the Region name from the Parent to its children (a Top-Down query) using the same CONNECT_BY_ROOT operator but this time getting the top level instead of the leaf level (Remember, It’s always get the ROOT information or the starting point).
As we can see in the example now we know that for “SUPP_Netherlands” the REGION_NAME is EMEA as well for all its parents.
Now we need to join both queries by ATTR_MEM_ID that’s the ID of the leaf attribute member.
With this we find out the region name for all entity hierarchy.
Now we need to figure out what Group will be spread to what members. To do so we need to query the HSP_ACCESS_CONTROL to get all security in the Generation 1 and 2 of entity (remember that this is our guide for the security spread) and also query the HSP_OBJECT to get the name of the groups (we need the name in case we’ll use the import utility approach).
It’s import to remember filter only the flags = 0. this way we only get the security that is set as member only (not Idescendants or any others)
With this query we’ll get all the security for generation 1 and 2 plus all the information regarding it as access mode (if is read or write or deny) and the flags (in our case will be always 0).
Now we need to join the previous two sub queries with this one to get the security information for each member we have in the entity dimension.
Our join is a like between the group name and the region name.
This is why we need to have the region name in the group name and in the support geography attribute dimension (or any attribute dimension we wants to use to create security)
We can see that a join like this will create a Cartesian result for all the regions and groups name. This will be fixed when we Join this sub query with the next and last sub query part, where we going to identify what parent that group belongs.
OK now we need to get ride of the Cartesian product that our last sub query creates.
For this we’ll need a sub query that is going to bring all members under generation 1 and 2 and all member under it in a way that it going to create a relationship between the generation 1 and 2 and their children.
For this we’ll use our old friend CONNECT BY PRIOR in a normal way (top-down) from Channel to the leafs and we’ll use the CONNECT_BY_ROOT to get the parent name and one new thing:
CONNECT_BY_SYS_PATH. This operator basically create a string with the entire path that returns from the query and will split each member by any character that we select! In our case we choose |.
This will create our relationship, because we’ll have in the same row the entire hierarchy.
We need only to split it by column, and for this we’ll use a Oracle regular expression. REGEXP_SUBSTR(PATH, '[^|]+', 1, 1).
This function enable us to get a string, define a character (that will be our search value) and define the starting position and the occurrences.
This is good because to move to the next one all we need is to increase the second parameter (the occurrences) to 2 that’s means it’ll get the next occurrence of the search value.
And Finally we will Join the last sub query part with the others, getting ride of the Cartesian product by creating a Relationship between the parent member that the security group have and the member that will receive the security and finishing our security query.
For this we’ll join the Generation 1 and 2 member (that we called PARENT_G1 and G2 with the PARENT_ID from the Parents sub query plus the ENTITY_ID from the Members sub query with the ENTITY_ID from the PARENTS sub query.
With this done we have our final query with all information to create dynamically any Planning security based in any attribute dimension. (remember that we create it based in Generation 1 and 2 because it’s enough for us. If you need to inform security with more details we just need to increase the generations in our query to 3 or more as needed, the rest will be the same)
Ok, from now one we’ll talk about the solution choices that we used at dell and explain the reasons for that but with this query you could create your own solution as a trigger that use this query to monitor any new groups added in the HSP_ACCESS_CONTROL table and populate it automatically or use pl/sql to do so, or any other possible solution that we could create with this information.
-----15 min
ODI is by far the best integration tool in the market today.
ODI 11g can be used to integrate several EPM tools and especially Hyperion Planning applications.
ODI knowledge models can be used to maintain Hyperion Planning metadata and also to load and extract data from its Essbase cubes.
But the main reason to use ODI is to take advance of its flexibility to customize its code.
You may tweak knowledge models and procedures in such way to allow you to create dynamic process with it.
With the right architecture in place ODI can be used as a full flexible development and execution platforms.
Dells uses ODI for the complete process that automatizes the entire maintenance cycle, admin tasks (like security, backups, optimizations), inbound and extract jobs, even with the possibility for you to schedule those jobs
For now we need to stick with odi11 because odi 12 doesn’t support Hyperion Planning/Essbase yet.
Rodrigo: Now that we have how our security should be, we need to decide how we are going to apply it to Hyperion Planning.
We have two ways to do it (read slide)
Let’s talk about the first solution.
This solution uses the existing ImportSecurity utility that comes with Hyperion Planning in order to read the SecFile and load the security into the application.
Here in this slide is how we use this utility. It is a very simple command line with some basic parameters (read slide).
Rodrigo: SecFile is just a text delimited file with all the security that needs to be added to Hyperion Planning.
It needs to have the following format (read the slide).
As I said in the previous slides, one of the cons of having the security loaded through ImportSecurity utility is that it does not have a good clear control, so basically we may clear everything and load the new security from SecFile, or we don’t clear anything and just add the new security settings over the existing one, which may lead to some garbage, some undesired old security, as an example, when a cost center changed its parent.
Based on this restriction, we may work in two ways: we may load the SecFile without SL_CLEARALL and discover the old undesired access using a SQL and then send those by email to an Admin to have them removed manually
Or we may get a SQL query to retrieve the existing security that is not related to Entity, that is the main dimension that we are showing here, clear all security using SL_CLEARALL option and load all new Entity related security and all other existing security retrieved by this query back to Planning.
But why we do not always use the CLEARALL option? That’s because depending on how big/complex is you security settings, it may take a long time to refresh the Essbase security filters. So this decision needs to take into consideration your current architecture to see if it worthy to use it or not.
So, if we choose to not use SL_CLEARALL and we want to manually delete the old undesired security settings, we will need to create two ODI interfaces.
First one will only load the new security to SecFile.txt. This is easily done by creating two datasets inside the ODI interface as shown in this slide:
The first dataset contains the entire desired Entity security (from our temporary security table) minus the security that already exists in Planning and here you may notice the OBJECT_TYPE 33 filter for Entity. This filter was added because we are dealing with only the Entity dimension here.
In our target datastore we have added four columns that represents the necessary layout for the SecFile. We have omitted the ARTIFACT_TYPE column from it because the MEMBER type is the default when you leave it blank. Also we have done some basic mappings there, decoding from the Planning codes to the codes accepted by the SecFile, so in ACCESS_PERMISSION 1 becomes Read, 3 Write and so on. Same thing for ESSBASE_ACCESS_FLAG column.
Now that only the new security is in the SecFile, it is just a matter to use it to import to Hyperion Planning without the SL_CLEARALL parameter
Our second interface invert the datasets orders:
The first dataset will read from what currently exists in Hyperion Planning, filtering OBJECT_TYPE 33, that stands for Entity,and FLAGS equal to 0 that represents the MEMBERS security type
The second dataset gets the data from our temporary security table. When we MINUS the first dataset and the second dataset, the query will give us all the old undesired security that should not exist anymore in the application.
Our target datastore can be in any format here and here in this example we decided to let it like the SecFile for convenience. Now you may create and ODI procedure that send emails, attach this file to the email and send it to an Admin to have him deleting the security manually for those cases.
But now, if we decide to go with the SL_CLEARALL option, we must remember that we will clear everything first and then we will need to reload both the new Entity security plus everything that already existed in the Planning application that was not related to Entity or to the MEMBER security time, because those are the ones that we actually are manipulating here. So we will need to create just one interface, but this one will be slightly different from the other ones that I have shown. This interface will UNION both datasets instead of MINUS them.
The first dataset is the desired security settings from our temporary security table, that contains the security for Entity and only for the MEMBER security type.
The second dataset will be everything that exists in planning that is not related to Entity (see the filter OBJECT_TYPE <> 33 there in the slide) OR everything that has the FLAGS column different from 0, meaning that it is not a MEMBER security type. This filter needs to be done this way because we want all security related to other Dimensions and also all those security settings from Entity Dimension that we may eventually have that is not related to MEMBER like Idecendants, Ichildren and so on.
And again, our target table will be the same SecFile datastore that was shown before with the same mappings to convert from Planning codes to SeqFile codes.
Here is the final procedure for our Solution 1, independently if you are going to use CLEARALL or not
This procedure calls ImportSecurity utility command passing the necessary parameters to it.
Here we can see that the connection information (application name and user name) from the “Command on Source” tab that is set to our Hyperion Planning application. This Command on Source and Target tables is a great technique used in ODI because it allows you to use information that we set in the source tab into a command in the Target table, giving you a lot of coding flexibility. The source tab can also be used similarly to a PL/SQL cursor, where you may have a SQL command on source that will return N number of rows and for each one of those rows, ODI will execute whatever is in the source. It is a pretty cool feature and we use it a lot in our ODI projects.
You can also notice here that we use two ODI variables: PLANNING_BIN_PATH that indicates where the ImportSecurity utility is located under Planning install folder; and PASSWORD_FILE that is the full path where the password file is stored. Remember, this password file is necessary in our case here because it is an automatic process and we will not type our password in the prompt line.
Also we have added an ODI option to select if we want to use SL_CLEARALL or not, so we may use this procedure in both approaches that we have shown. This is all we need to load the SecFile to the Hyperion Planning application. Very small coding.
Ok, now lets switch to our second Solution, that is the manipulation of HSP_ACCESS_CONTROL table directly using SQL. Before I move on and before you ask which approach you should use, I must say that our intention here is not to tell you which approach is better, even because me and Ricardo have different opinions about it: I prefer the ImportUtility approach because we use what we officially have, even thought it is incomplete and painful to use some times. Ricardo will always prefer repository manipulation because it is easier and much more flexible and powerful. Anyway, we will show you both solutions and you decide which one is the best for you. We may just guarantee to you that both were tested and work as expected. Also Oracle likes the first approach, since they don’t like us touching their metadata tables.
Ok, so lets see what we have here.
Instead of using ODI interfaces, we decided to use and ODI procedures with two steps inside of it, due to the simplicity and flexibility of it. The logic in the queries is very similar to what was used in Solution 1.
The first step deletes from HSP_ACCESS_CONTROL everything related to Entity dimension members with FLAGS = 0 (members) that does not exists in our temporary security table. This will remove all old undesired access that should not be in the application.
The second step just inserts into HSP_ACCESS_CONTROL everything from our temporary security table that does not exists in HSP_ACCESS_CONTROL yet.
Performing those two steps will guarantee that your Hyperion Planning application is in sync with the necessary security. But in order to have it applied to Planning, we first need to restart the Planning Services.
This slide shows us a very dummy way to restart Planning This example was done in Windows and just calls a Service Controller command to stop and start the HYS9Planning service. Between each command we have added a “Wait” ODI object with an arbitrary number of seconds for it to wait for the services to go down and to go up again. There are other much better ways to do it and they are all dependent on which Operational System your planning application is running, and since it is not the scope of this presentation to show all possible ways to do it, we decided to show the simpler one.
And here is the final ODI package that you will get. A very small, but powerful package that will allows you to automatically maintain your Planning Security settings with all the benefits of ODI scheduling, proper user access and so on. Here we can see that depending on the solution that we followed, we may have different objects there, but in the end all of them will result in the same objective.
Here is a final (bonus) slide on how ODI can be powerful and useful in a Hyperion Planning structure. Here is what we have at Dell today. (Read the slide).
