A load rule in Hyperion Essbase and legacy Oracle EPM on-premise environments is a configuration file that defines how a data source — a delimited flat file, a SQL query, or a fixed-width file — maps to the dimensions and data members of an Essbase cube for data loading. The load rule specifies which columns in the source file correspond to which Essbase dimensions, any header rows to skip, field delimiter and encoding settings, and transformation operations to apply during the load. In Oracle Essbase on-premise and Hyperion Planning on-premise deployments, load rules are the primary mechanism for bulk data loading from ERP extracts and financial system outputs into the Essbase database.
Load Rule Architecture: Legacy vs Cloud
In Oracle EPM Cloud, the load rule concept is superseded by Data Integration’s import format and data load rule configuration, which provides a graphical mapping interface and more comprehensive transformation capability than the traditional text-based Essbase load rule. Organisations migrating from on-premise Hyperion to EPM Cloud frequently need to translate their existing load rules into DI configurations — a non-trivial task because the two tools handle certain mapping scenarios differently, particularly for header-row-based column identification, multi-pass data loading, and conditional dimension member assignment.
On-premise Essbase load rules support both data loading (populating data values into existing cube members) and dimension build (creating or updating dimension members from a source file). These two functions are distinct in EPM Cloud — data loading and dimension builds use different mechanisms and different interfaces. When migrating a load rule that combined both functions, the two functions must be separated into distinct DI configurations.
Design Considerations
Load rule performance in on-premise Essbase environments is affected by the data load method — stream loading (data is processed as it is read, record by record) versus batch loading (data is read fully into memory and then processed). Stream loading is more memory-efficient for large files; batch loading is faster for small-to-medium files where the full dataset can be held in memory. The appropriate method depends on the file size and the available memory on the Essbase server.
What Goes Wrong in Practice
The specific load rule failure most common in on-premise Hyperion environments is a load rule that does not specify the field delimiter explicitly, relying on the default delimiter setting. When a source file is produced with a different delimiter than the Essbase default — because the ERP extract tool changed its output format, or the file was processed through a different system — the load rule silently misinterprets the column structure and loads data into incorrect dimension columns. The load completes without error because the misinterpreted values are valid member names or amounts; the data corruption is discovered during reconciliation. Explicit delimiter specification in every load rule is a basic hygiene requirement that prevents this class of silent corruption.
How Loop Wise Solutions Handles This
In on-premise Hyperion engagements, we document every load rule’s source file format specification — delimiter, encoding, header rows, column mapping — and include a post-load reconciliation step in the automation script that compares the loaded record count and total amount against the source file’s expected values. For EPM Cloud migrations, we map every on-premise load rule to its DI equivalent configuration before the migration begins, testing each mapping against actual source data before production cutover.
