Metadata and Groovy - Reassign New Members to a Parent

Allow users to dynamically reassign new members in the dimension hierarchy

Continuing the Metadata and Groovy series, we will see how we can apply to practical scenarios. I developed this functionality for users who wanted to be able to reassign metadata to new parents without involving Admin/IT.

Reassign New Members to a Parent

Let me explain why we needed this functionality. In this scenario when data files are being loaded, there is a process to scan the files and create new metadata members to avoid data rows being rejected during the data load. These new metadata members are created under a specific parent so that the team can review this hierarchy after every load and move these members to the correct parent.

This process was managed by Admin/IT, but the inputs came from the business users. In this article I will explain how you can empower your business users to make metadata changes by assigning members to new parents without involving the Admin/IT team.

Example Setup

For this example I have taken the Product dimension.

The product dimension has a simple 2-level hierarchy under All Products for the Product Family and the Product.

I have added a sibling to All Product as New Products which is where the newly created members will be added. They roll-up to Total Product so that the aggregated reports will show the correct data, but these are yet to be assigned to the correct Product Family.

Bonus points if you know the project codenames.

I have created a simple form where the users see the list of New Products, and they can choose a SmartList which lists all values of the Product Family (SmartPhones, Tablets, Notebooks, Computer Accessories and Computer Services).

Groovy Code to Reassign New Members to a Parent

/*RTPS:*/

if (!operation.hasGrid()) {
	throwVetoException("This rule can only be run from a Web Form")
}

def updateParent = { Member mbr, String parentName ->
	Map mbrProperties = mbr.toMap()
    mbrProperties["Parent"] = parentName
    return mbr.getDimension().saveMember(mbrProperties, DynamicChildStrategy.NEVER_DYNAMIC)
}

Map membersToReassign = [:]

operation.grid.dataCellIterator({DataCell cell -> cell.isEdited()}).each { DataCell cell ->
	Member productName = operation.application
    					 .getDimension("Product", operation.cube)
    					 .getMember(cell.getMemberName("Product"), operation.cube)
	String parentName = cell.getDataAsSmartListMemberName()
    membersToReassign[productName] = parentName
}

membersToReassign.each { key, val ->
	updateParent(key as Member, val as String)
}        

The code isn't very complex as you can see.

I basically iterate through the grid and pick out the members from Product dimension and the SmartList values where the cells have been modified and accumulate them all in a Map.

I am not doing any validation or error-checking in this example, where you might want to enforce certain business rules.

Then we simply retrieve the properties of each members, update the "Parent" property to the new name and save it back to the dimension.

When saved, the member disappears from this form (since it is no longer under the New Products parent) and the users cannot change / reassign it to a different parent any more.

Reassign New Members to a Parent in Action

Conclusion

In this part of the Groovy and Metadata series, I have covered how you can empower users to take charge of the application metadata (to a reasonable extent!) and remove dependencies creates delays.