Dimension build in Oracle EPM is the process of automatically creating, updating, or restructuring Essbase dimension hierarchies by importing dimension member data from an external source — a delimited flat file, a database query through a JDBC connection, or a Data Management load rule — rather than manually adding, editing, or restructuring members through the Planning administration interface. Dimension build is the standard mechanism for maintaining dimension metadata in environments where the authoritative source for account hierarchies, entity structures, or cost centre codes is an ERP chart of accounts, Oracle EDMCS, or another master data management system. Manual maintenance of dimension hierarchies through the UI is practical only for small, stable dimensions; production-scale EPM environments with hundreds or thousands of members that change regularly require dimension build automation.
Dimension Build Mechanics
A dimension build process specifies the source of the dimension member data, a header record that maps source columns to Essbase dimension member properties (member name, parent member, consolidation operator, data storage type, UDA assignments, formula), and the build method. Three build methods are available: Parent-Child build (the source specifies each member’s parent, enabling Oracle to construct any hierarchy structure), Generation References (the source specifies the generation — level from the top — at which each member sits), and Level References (the source specifies the level — position from the leaf). Parent-Child is the most flexible and most commonly used; it does not require the source to know the hierarchy depth and handles arbitrary hierarchy structures.
In Oracle EPM Cloud, dimension build is typically executed through Data Integration’s dimension import feature or through EPM Automate’s importDimensionMetadata command. Both accept the dimension member file, apply the configured mapping, and push the result to the Planning application’s dimension editor.
Design Considerations
The dimension build process must handle member deletions carefully — Essbase does not allow deletion of a dimension member that contains data in any scenario, period, or version combination. The correct approach for deprecated members is to move them to an “Unallocated” or “Inactive” parent in the hierarchy rather than deleting them, until the data they contain has been cleared from the database or archived.
What Goes Wrong in Practice
The specific dimension build failure that most frequently produces unexpected application behaviour is a build that restructures the parent-child relationships of members referenced in business rules or member formulas. When a member is moved to a different parent — because the source ERP has reclassified a cost centre to a different division — any business rule that references the old parent will produce incorrect results on its next execution: it will calculate against the old parent’s members, excluding the moved cost centre. Business rules are not automatically updated when dimension structures change through dimension build; they must be reviewed and updated separately. Production dimension builds must be followed by a business rule impact analysis before the updated dimension is used in the next calculation cycle.
How Loop Wise Solutions Handles This
We maintain a cross-reference between dimension members and the business rules and member formulas that reference them. Every dimension build in a production environment is preceded by a check of this cross-reference — identifying any business rules or formulas that reference the members being restructured and scheduling their review and update before the dimension build is applied to the production application.
