Downloaded 12 times
![ 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](https://image.slidesharecdn.com/unleashinghyperionplanningsecurityusingodi-160601140922/85/Unleashing-Hyperion-Planning-Security-Using-ODI-29-320.jpg)
More Related Content
Similar to Unleashing Hyperion Planning Security Using ODI
![[DSC Europe 25] Elena Menshikova - AI-Powered Operational Excellence: Revolut...](https://cdn.slidesharecdn.com/ss_thumbnails/es6nholbqy3zaao2c2yd-2-elena-menshikova-data-ai-in-decision-making-260115093812-4fba8b38-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DSC Europe 25] Slobodan Dolinic - Smart and Intelligent Green Region.pptx](https://cdn.slidesharecdn.com/ss_thumbnails/0bribinjsp6ghwtvsvor-2-sigre-slobodan-dolinic-260115093812-c9c10e90-thumbnail.jpg?width=640&height=640&fit=bounds)
Unleashing Hyperion Planning Security Using ODI
- 1. Unleashing Hyperion Planning SecurityUsing ODI Ricardo Giampaoli – TeraCorp Rodrigo Radtke de Souza - Dell
- 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 isa 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
- 5. Agenda Business Needs Hyperion Planning Security Hyperion Planning Repository Building Solutions Dell’s Environment QA Agenda
- 6. Business Needs The StudyCase 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 Regiondimension 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 thePlanning 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 securitymust 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 informationexists 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 isdefine 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 NameDescription 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 Theuser 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 isdefine 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 NameDescription 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 ColumnName 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 objectsis 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_IDObject 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 GeographyHierarchy Extract the Support Geography Attribute Dimension Hierarchy from Planning Repository ● Use connect by prior to rebuild the hierarchy
- 22. Building Solution Join 1:Entity + Support Geography Join both queries by ATTR_MEM_ID
- 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 thequeries by LIKE of REGION_NAME Building Solution Join 2: Adding Security Groups
- 25. Building Solution Generation 1and 2 Members Identify the Generation 1 and 2 parents for all Entity members under it.
- 26. Join Parent_IDfrom 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 waysto 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 utilityloads 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 orgroup 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 accesspermissions 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 Loadonly 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 Loadall 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 LoadALL security to SecFile.txt ● Using two datasets to generate an Union between the new and the existing security Generating Full SecFile.txt
- 35. Use aODI Procedure to run a CMD command on Planning Server and import security Import Security Solution 1
- 36. Solution 2 Insert/DeleteSecurity on HSP_ACCESS_CONTROL Hyperion Planning Repository
- 37. Restart Planning ●SC PLANNING_SERVER STOP HYS9Planning ● Wait ● SC PLANNING_SERVER START HYS9Planning ● Wait Solution 2 Restart Hyperion Planning Service
- 38. ODI Package SimpleODI Solution Building Solution
- 39. DRM (Metadata Source) Oracle Inbound tables schema Hyperion Planning Source System External System External System External System Source System Source System IKMSQL to Hyperion Planning (Metadata) Essbase IKM SQL to Hyperion Essbase (DATA) LKM Hyperion Essbase DATA to SQL Security and admin tasks Oracle Outbound tables schema Traditional ETL Production Planning Architecture Dell Environment
- 40.
- 41. Ricardo Giampaoli –TeraCorp Rodrigo Radtke de Souza - Dell Thank you! Thank You
Editor's Notes
- #3 Ricardo: Present himself Rodrigo: Present himself
- #4 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.
- #5 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
- #6 Or agenda will cover Business Needs Hyperion Planning Security Planning Repository Building Solutions Dell’s Environment QA
- #7 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.
- #8 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.
- #9 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.
- #10 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.
- #11 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)
- #12 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
- #13 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.
- #14 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
- #15 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.
- #16 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
- #17 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.
- #18 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.
- #19 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.
- #20 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
- #21 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.
- #22 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.
- #23 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.
- #24 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).
- #25 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.
- #26 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.
- #27 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.
- #28 -----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.
- #29 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)
- #30 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).
- #31 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).
- #32 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.
- #33 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
- #34 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.
- #35 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.
- #36 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.
- #37 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.
- #38 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.
- #39 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.
- #40 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).
- #42 ----15 min