Introduction
Welcome back to the final edition of this 4-part blog series examining the most compelling features from the recent EDM 22.09 release. In part 1, we looked at end-to-end integration between EDM and Cloud GL. In part 2, we explored the Model After Node feature. In part 3, we perused the Inclusion Filter on subscriptions.
For this final entry, I want to look at a feature that may surprise you. It is not the most obvious or exciting enhancement, but one I think adds tremendous value behind the scenes: Sort Locations Using Hierarchy Order.
For a complete listing of all the features included in Oracle EDM 22.09, please refer to this link: EDM Sep 2022 Update
Sort Locations Using Hierarchy Order
First, an important clarification. This feature does not impact how nodes are sorted within a dimension (although exciting enhancements in node sort order are on the product roadmap). This feature allows you to leverage the positioning of shared nodes within a dimension to automatically derive key property values where sequencing is important, such as Data Storage.
The secret sauce happens in the derived expression itself, where you can now set a Sort parameter within the Locations and BoundLocations functions. In the example below, we use BoundLocations with a Sort parameter of “True” to determine if the current node is the same as the first location of that node (using the somewhat perplexing yet highly entertaining logic of “get the location at index(0)” and “check if location.parent.name = node.parent.name”).
The result of this logic? If the node is a bottom node, and the node is the first location (occurrence) of that node, set the Data Storage to “Store”. Otherwise set to “Shared”.
What is also nice about this feature is it will handle implicitly shared nodes (nodes that are descendants of a shared node). You can see this in action in the next example.
Here, the entity “Afghanistan” appears four times – once as a primary node, twice as a shared node, and once as an implicitly shared node because its parent was shared into an alternate rollup.
EDM can correctly derive the data storage value automatically, based on the hierarchy order of the node, even though the implicitly shared node appears after the shared nodes.
This hidden, behind-the-scenes trick will be especially useful for those clients with complex dimensions containing dozens of alternate hierarchies that include both explicitly and implicitly shared nodes with rollups nested within other rollups. EDM can automatically calculate the right property values without manual intervention, freeing up the EDM administrator to focus on more value-add tasks.
Conclusion
That is a wrap for this blog series. Stay tuned for more blogs around Oracle EDM and reach out if you have questions. Until next time!
