A cube in Oracle EPM is an Essbase multidimensional database — the physical storage and calculation engine that holds an application’s data and dimension structure. In Oracle PBCS and EPBCS, each planning application contains at least one reporting cube (typically ASO type) and one or more input cubes (typically BSO type). The reporting cube aggregates and serves the data that users query; the input cubes hold the plannable data that business rules calculate against. In legacy Hyperion Planning, a single BSO cube per application was the standard architecture; Oracle EPM Cloud introduced the multi-cube architecture that separates input and reporting concerns.
Cube Architecture in EPM Cloud
Oracle EPM Cloud applications are built on one of two cube types — BSO (Block Storage Option) or ASO (Aggregate Storage Option) — and the choice has fundamental implications for calculation behaviour, data density requirements, and query performance. A BSO cube stores data in blocks defined by the dense dimensions’ member combinations; it supports write-back, complex interdimensional formulas, and incremental calculation. An ASO cube stores data in a compressed sparse structure and aggregates dynamically at query time; it handles very large member counts and query-time aggregation better than BSO but does not support member formula write-back or dynamic allocation during calculation.
In EPBCS, the standard deployment creates a BSO input cube (where planning forms submit data and business rules calculate) and an ASO reporting cube (where all approved data is pushed for high-performance management reporting). The push from BSO to ASO is not automatic — it is triggered by an explicit data push rule or an EPM Automate job. Understanding this push architecture is essential: data that has been entered in the BSO cube but not pushed to ASO will produce stale data in ASO-based management dashboards.
Configuration and Design Considerations
The decision to use a single BSO cube versus a BSO/ASO hybrid, or multiple BSO cubes, is the central architectural choice at application design time. A single BSO cube is simpler to maintain but may not scale for reporting workloads with large member counts. A BSO/ASO hybrid adds the data push overhead but enables the ASO cube to serve large-scale management reporting efficiently. Multiple BSO cubes — one for revenue planning, one for OPEX planning, one for headcount — share data through data maps and reduce the dimensional complexity in each individual cube at the cost of more complex data flows and higher maintenance overhead.
What Goes Wrong in Practice
The most consequential cube architecture error in EPM Cloud deployments is treating the reporting cube as a live operational data store and scheduling the BSO-to-ASO push infrequently — once per day rather than after each significant business rule execution or data load. Finance users query the ASO reporting cube and see data that does not match the BSO input cube, raising data integrity concerns that require IT investigation. The resolution is always the same: the push timing was incorrect. The ASO push schedule must be aligned to the data currency requirements of the reporting consumers, not to the administrative convenience of the IT team.
How Loop Wise Solutions Handles This
We design cube architecture before application provisioning — producing a cube architecture document that specifies the cube type, dimension assignment, storage designation, and data push schedule for each cube in the application. For new EPBCS deployments, we validate that the BSO/ASO push timing is aligned to the close cycle schedule and management reporting cadence, not set to a default overnight schedule that may not serve the specific operational pattern of the client’s finance function.
