Metadata in Oracle EPM is the structural configuration layer of an Essbase application — everything that defines the organisation of the data rather than the data itself. Metadata includes the dimension member hierarchies (which accounts exist, how they roll up), member properties (UDAs, data storage type, variance reporting direction), aliases (alternate member names in different alias tables, including Arabic), member formulas (the calculation expressions attached to specific members), substitution variables (runtime variables referenced in calculations and forms), and the application-level settings (currency, time period type, fiscal year start). Changing metadata changes the shape of the application; changing data changes the values within that shape. The distinction matters because metadata changes propagate immediately to all forms, rules, and reports that reference the affected members — a metadata change is not isolated to the specific area being modified.
How Metadata Is Managed
In Oracle EPM Cloud, metadata is managed through the application’s dimension editor in the Planning UI, through EPM Automate command-line operations, through the REST API, or through Data Management dimension import jobs. Oracle EDMCS (Enterprise Data Management Cloud Service) is Oracle’s dedicated metadata governance tool — it maintains the authoritative source of dimension member hierarchies and propagates approved changes to consuming EPM applications through a governed workflow. Without EDMCS or an equivalent governance process, metadata changes in production EPM applications are typically made directly in the Planning dimension editor by IT team members — a practice that produces inconsistent metadata states and difficult-to-audit change histories.
Metadata changes that add or remove members do not require database restructuring in ASO cubes — they take effect immediately after the dimension is refreshed. BSO cube metadata changes that affect the dense dimension structure require a database restructure, which writes all existing data to a new block structure — an operation that can take hours for large BSO databases and should be scheduled during off-hours maintenance windows, not performed during business hours.
Configuration and Design Considerations
Alias tables are a frequently underutilised metadata feature with specific relevance for GCC deployments. Each dimension member can have multiple aliases — one per alias table — allowing the same member to display in English in one report context and in Arabic in another, without maintaining separate dimension structures. Arabic aliases require UTF-8 encoding in the metadata import file and must use right-to-left character sequences; errors in encoding produce garbled Arabic display in Smart View and Planning forms rather than an error message, making them harder to detect.
What Goes Wrong in Practice
The most common metadata management failure in enterprise EPM environments is performing dimension member additions directly in the production application without a corresponding update to the shared services metadata import file that serves as the change record. After several years of this practice, the production application’s metadata diverges materially from any documented baseline — making impact assessment of proposed changes unreliable, migration to a new environment error-prone, and troubleshooting calculation issues dependent on individual team member knowledge rather than documented configuration. Every metadata change, however small, should be applied through a version-controlled import file, not through the UI editor, so that the import file remains the authoritative source of truth for the application’s structure.
How Loop Wise Solutions Handles This
We establish a metadata governance process at the start of every EPM engagement — defining the authoritative source for each dimension (typically an EDMCS viewpoint or a version-controlled flat file), the change control process for metadata modifications, and the import mechanism used to apply changes to the application. For clients without EDMCS, we maintain the governance through version-controlled import files stored in a shared repository, with a documented change log. We treat the import file as the production metadata record, not the application’s current state.
