Contact us FR

Game Changer! Key Enhancements in the EDM 22.09 Release – Part 4

Published November 11 2022
Back to insights

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”).

Oracle EDM screenshot showing expression using sort parameter boundlocations

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.

Oracle EDM Entity Maintenance screenshot showing Primary Node and Shared Node

OracleEDM Entity Maintenance screenshot showing Shared Node and Implicitly Shared Node

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!

For comments, questions, or suggestions for future topics, please reach out to us at infosolutions@alithya.com.  Visit our blog regularly for new posts about Cloud updates and other Oracle Cloud Services such as Planning and Budgeting, Financial Consolidation, Account Reconciliation, and Enterprise Data Management.  Follow Alithya on social media for the latest information about EPM, ERP, and Analytics solutions to meet your business needs.