Attribute dimensions are a boon when it comes to tabbed reporting or running member specific calculations or filtering data based on attributes but their management is bigger pain. In case these attributes require a regular update or association to newly created member on the fly, the only option is to go into dimensions and update them. Sometimes these could be challenge when users are new to Planning and taking baby steps in administering the whole application. All they could expect is a webform where all members and their associated attributes are listed to review and update, if required.
Today’s post is going to talk about how metadata management could be made easy for new to Planning (PBCS) administrators by leveraging groovy. In this example, we have a project dimension with hierarchies for existing and new projects. Each project is grouped into domestic or international project tracked by an attribute dimension – Project Category and to determine whether project should be considered for calculations or not, projects are tagged as either active or inactive maintained as another attribute dimension – Project Status. Since users have ability to create new projects, they would go to admin for approval and at the same time admin could assign these attributes to new projects.
Our project dimension have two attribute dimensions with attribute values as below.
Let’s create two smartlists which will be used on form to assign attributes to projects. The reason we have used the names similar to attributes to use them directly.
The smartlists are tagged to two measures used on the form to allow assigning attributes to projects. The members are Proj_status (Alias: Project Status) and Proj_Category (Alias: Project Category) and the form would allow user to assign values as below.
Lets look at the groovy script and understand how groovy makes it easy to manage stuff from front end.
- Create an object dimProject of type Dimension which holds the project dimension
- On operation (i.e. when the rule runs on save), navigate through the grid and capture only those cells which have been edited and perform action on each edited cell
- From the edited cell, extract the member name of the project dimension and store it as object mbr_project of type Member
- Since the edited cell will hold the ID of the newly selected smartlist member, we pass this to smartlist object to return the name associated to that ID. Since we used the same names as the attributes while defining these smartlists, we can use the names as is
- Use the saveMember function to append values of the Project_Status or Project_Category to the existing property map of the member
Dimension dimProject = operation.application.getDimension("Project", operation.application.getCube("PROJPLAN"))
operation.grid.dataCellIterator({DataCell cell-> cell.edited}).each{
Member mbr_project = operation.application.getDimension("Project").getMember(it.getMemberName("Project").toString())
if(it.getMemberName("Measure") == "Proj_Status"){
def strProjStatus = operation.application.getSmartList("SL_Project_Status").getEntry(it.data.intValue()).getName()
//println strProjStatus
mbr_project = dimProject.saveMember(mbr_project.toMap() << (["Project_Status":strProjStatus.toString()] as Map
))
}
if(it.getMemberName("Measure") == "Proj_Category"){
def strProjCategory = operation.application.getSmartList("SL_Project_Category").getEntry(it.data.intValue()).getName()
//println strProjCategory
mbr_project = dimProject.saveMember(mbr_project.toMap() << (["Project_Category":strProjCategory.toString()] as Map ))
}
}
From the form when we edit any cell to assign or change attribute of any project, this rule would pick the edited cell and update attribute values. Re-iterating the fact that saveMember being a privileged method, as discussed in my last post, would require user to have admin rights to execute the rule. Still, imagine a PBCS admin, quite new to app, no longer need to search through documentations to update attributes manually.
Cheers!!!
