Administration

8.1 Overview

The Administration section covers the tools and features available to CUBE_ADMIN users for managing security, compliance, audit logging, EPM migration, and AI-powered assistance.

8.2 Access Control (Row-Level Security)

Row-level security restricts which dimension members a user can see in query results. When enabled for a hierarchy, only members explicitly granted to the user are visible.

How Row-Level Security Works

1. An administrator creates security rules that map users to specific members within a dimension.
2. When a cube query is executed, the application checks the current user against the security rules.
3. Results are filtered to include only members the user is authorized to see.
4. Users without any security rules for a given dimension have unrestricted access to all members in that dimension.

Managing Security Rules

Navigate to Admin → Access Control to manage security rules.

Adding a Rule

1. Select the cube from the dropdown
2. Expand Add Security Rule
3. Select the Hierarchy (dimension)
4. Search for and select a Member, or type the member name directly
5. Enter the User Name (the Snowflake username)
6. Check Active to enable the rule immediately
7. Click Add Rule

Editing Rules

The security rules table supports inline editing:

• Edit any field directly in the table
• Add new rows using the table’s add row feature
• Delete rows by selecting and removing them
• Click Save Changes to commit all edits

Security Rule Properties

Property	Description
Cube Name	Which cube the rule applies to.
Hierarchy	Which dimension the rule restricts.
Member Name	The specific member the user is granted access to. Access includes the member and all its descendants.
User Name	The Snowflake username the rule applies to.
Active	Whether the rule is currently enforced. Deactivate to temporarily disable without deleting.

Important Notes

• A user must have at least one active rule for a secured dimension to see any data in that dimension.
• Multiple rules can be created for the same user/dimension combination to grant access to multiple members.
• Security is enforced at query time using the CURRENT_USER() function, which requires the READ SESSION privilege.
• Security rules are per-cube. A user may have different access across different cubes.

8.3 Audit Log

The Audit Log provides a complete record of all operations performed in Casabase Cube. It is accessible from the Audit Log page in the sidebar.

Who Can See What

Role	Access
CUBE_ADMIN	Full audit log: all events from all users.
CUBE_PUBLIC	Own activity only: filtered to the current user’s events.

Audit Log Dashboard

The Audit Log page displays:

• Summary metrics: Total events, events in the last 24 hours, unique users, error count
• Filterable event list: Filter by cube, event type, user, status, date range, and free-text search
• Event details: Click any row to view full details including the POV, parameters, and execution context
• Export: Download filtered results as CSV

Filters

Filter	Options
Cube	Filter to a specific cube or view all.
Event Type	DATA_QUERY, HIERARCHY_CREATE, HIERARCHY_REBUILD, CUBE_CLONE, APP_INSTALL, APP_UPGRADE, CLASSIFICATION_CHANGE, LOG_PURGE, TABLE_DROP, and more.
User	Filter to a specific user (admin only).
Status	All, SUCCESS, ERROR, or PARTIAL.
Date Range	Last 24 hours, 7 days, 30 days, or 90 days.
Search	Free-text search across user name, event type, action, object name, and error messages.

Exporting Audit Records

For compliance and external review, export audit records via the Admin → Compliance → Audit Export tab:

1. Set the Start Date and End Date
2. Optionally filter by Event Type
3. Set the Max Records limit
4. Click Export Audit Log
5. Review the results and click Download CSV

Via SQL:

CALL CASABASE_CUBE.CUBE.EXPORT_AUDIT_LOG(
    '2025-01-01'::TIMESTAMP_LTZ,     -- Start date
    '2025-03-31'::TIMESTAMP_LTZ,     -- End date
    'DATA_QUERY',                     -- Event type filter (NULL for all)
    'MY_CUBE',                        -- Cube filter (NULL for all)
    10000                             -- Max records
);

Retention & Purging

Audit log records can be purged based on a retention period. This is managed from the Audit Log page or the Admin → Compliance tab.

Preview what will be purged (dry run):

CALL CASABASE_CUBE.CUBE.PURGE_AUDIT_LOG(90, FALSE);

Execute the purge:

CALL CASABASE_CUBE.CUBE.PURGE_AUDIT_LOG(90, TRUE);

The default retention period is 90 days. The minimum is 7 days and the maximum is 365 days.

8.4 Compliance

The Compliance section (under Admin → Compliance) provides tools for governance and regulatory review.

Privacy Report

Generate a privacy report that summarizes:

• Total cubes and their data classification levels
• Which cubes have row-level security enabled
• Data handling practices
• Recommendations for improving security posture

Click Generate Privacy Report to produce the report on demand.

Data Inventory

View a complete inventory of all data objects referenced by Casabase Cube, including source tables, dimension tables, and their accessibility status.

Click Load Data Inventory to generate the inventory.

Access Review

Review all active security grants and user activity:

• Row-Level Security Grants: A downloadable table of all security rules across all cubes.
• User Activity (30 days): Summary of each user’s total actions, query count, error count, and last activity timestamp.

8.5 Cube Variables

Cube variables are substitution values that can be referenced in POV strings using [CUBE_VAR=name] syntax. They allow queries and saved queries to be dynamic. For example, you can reference “current year” without hardcoding a specific year.

Managing Variables

Variables are managed from the Cube Config page under the cube’s settings.

Property	Description
Variable Name	The name used in POV references (e.g., current_year).
Value	The member name the variable resolves to (e.g., FY25).

Usage in Queries

CALL CASABASE_CUBE.CUBE.QUERY_CUBE(
    'FIN_PLAN',
    'FINANCE_DB.PLANNING.FACT_PLAN',
    'AMT',
    '{
        "ACCOUNT": [{"children": "Total P&L"}],
        "PERIOD": ["[CUBE_VAR=current_period]"],
        "ENTITY": ["Corporate"],
        "SCENARIO": ["[CUBE_VAR=current_scenario]"],
        "VERSION": ["Final"]
    }',
    NULL
);

When the query executes, [CUBE_VAR=current_period] is replaced with the variable’s current value. To change the target period, update the variable. All queries referencing it automatically use the new value.

8.6 Data Classification

Each cube can be assigned a data classification level to indicate the sensitivity of the data it accesses:

Classification	Description
PUBLIC	Data that is generally available and not sensitive.
INTERNAL	Data intended for internal use only.
CONFIDENTIAL	Sensitive data requiring restricted access.
RESTRICTED	Highly sensitive data with strict access controls.

Classification is set on the Cube Config page under Cube Settings. It is used in the Privacy Report and as a governance label. It does not automatically enforce access restrictions beyond what row-level security and application roles already provide.

8.7 Importing from Oracle Essbase & Cloud EPM

Casabase Cube can import cube metadata and data from Oracle Essbase and Oracle Cloud EPM, enabling migration from legacy EPM platforms to Snowflake. The import tools are available under Admin → Import from Oracle.

Oracle Cloud EPM Migration – Overview

This section provides a complete, step-by-step guide for building a Casabase Cube application from Oracle Cloud EPM metadata and data exports. The process involves five phases:

1. Exporting level-0 data from Cloud EPM
2. Exporting application metadata (dimension hierarchies) from Cloud EPM
3. Loading the exports into a Snowflake stage
4. Creating the Casabase Cube using the imported metadata
5. Importing the data into the cube

The following sections describe the end-to-end process for migrating an Oracle Cloud EPM application to Casabase Cube. This process uses the Oracle epmautomate command-line utility to extract metadata and data, then uses Casabase Cube stored procedures to build the cube in Snowflake.

Step 1: Export Level-0 Data from Cloud EPM

Level-0 (bottom-level) data represents the leaf-level values in your EPM application – these are the input values that roll up through the hierarchy. Use the epmautomate commands below to perform a native level-0 extract:

epmautomate login <username> <password> <EPM_URL>
epmautomate exportEssbaseData <PlanType> <ExportFileName>.zip
epmautomate downloadFile outbox/<ExportFileName>.zip
epmautomate logout

Parameter	Description
<username>	Your Oracle Cloud EPM login username.
<password>	Your Oracle Cloud EPM login password (or path to an encrypted password file).
<EPM_URL>	The URL of your Oracle Cloud EPM environment (e.g., https://mycompany-epm.oraclecloud.com).
<PlanType>	The plan type to export (e.g., Plan1, Plan2, OEP_WFP). This corresponds to the BSO or ASO database within the application.
<ExportFileName>	The name for the output ZIP file (without the .zip extension in the export command; include it in the download command).

The exported ZIP file will contain the level-0 data files. Both native ASO and BSO export formats are supported by the Casabase Cube data import process.

Step 2: Export Application Metadata from Cloud EPM

Metadata exports contain the dimension hierarchies (parent-child relationships, aliases, consolidation operators, formulas, account types, etc.) that define the structure of your EPM application.

Create a Dimension Export Job

Before running the export commands, you must first create a metadata export job in the Oracle Cloud EPM web interface:

1. Navigate to your EPM application
2. Go to Overview → Dimensions
3. Click Export
4. Configure the export to use CSV format
5. Select the dimensions you want to export (or all dimensions)
6. Save the export job with a descriptive name

Run the Metadata Export

Use the epmautomate commands below to execute the export job and download the results:

epmautomate login <username> <password> <EPM_URL>
epmautomate exportMetadata <DimensionExportJob> <ExportMetadataFileName>.zip
epmautomate downloadFile <ExportMetadataFileName>.zip
epmautomate logout

Parameter	Description
<username>	Your Oracle Cloud EPM login username.
<password>	Your Oracle Cloud EPM login password (or path to an encrypted password file).
<EPM_URL>	The URL of your Oracle Cloud EPM environment.
<DimensionExportJob>	The name of the dimension export job you created in the EPM application (e.g., ExportAllDimensions).
<ExportMetadataFileName>	The name for the output ZIP file containing the metadata CSV files.

The downloaded ZIP file will contain one CSV file per dimension (e.g., ExportedMetadata_Account.csv, ExportedMetadata_Entity.csv, ExportedMetadata_Period.csv, etc.).

Step 3: Load EPM Exports to a Snowflake Stage

Upload the exported files to a Snowflake stage so that the Casabase Cube import procedures can access them.

Create a Stage (if needed)

CREATE DATABASE IF NOT EXISTS MY_EPM_DB;
CREATE SCHEMA IF NOT EXISTS MY_EPM_DB.EPM_STAGE_SCHEMA;
CREATE STAGE IF NOT EXISTS MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE;

Upload Metadata Files

Unzip the metadata export file locally and upload the individual dimension CSV files to the Snowflake stage. Each dimension CSV must be uploaded as a separate file:

-- Using SnowSQL or Snowsight Upload
PUT file:///path/to/ExportedMetadata_Account.csv @MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE;
PUT file:///path/to/ExportedMetadata_Entity.csv @MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE;
PUT file:///path/to/ExportedMetadata_Period.csv @MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE;
-- Repeat for each dimension CSV file

Upload Data Export Files

Casabase Cube can process the zipped data files exported from EPM as-is. Upload the ZIP file directly to the Snowflake stage:

PUT file:///path/to/data_export.zip @MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE;

Grant Stage Access to Casabase Cube

GRANT USAGE ON DATABASE MY_EPM_DB TO APPLICATION CASABASE_CUBE;
GRANT USAGE ON SCHEMA MY_EPM_DB.EPM_STAGE_SCHEMA TO APPLICATION CASABASE_CUBE;
GRANT READ ON STAGE MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE TO APPLICATION CASABASE_CUBE;

Step 4: Create the Casabase Cube from EPM Exports

With the files staged in Snowflake, you will use two Casabase Cube stored procedures to build each dimension, and then finalize the cube. The overall process is:

1. For each dimension: run IMPORT_PBCS_METADATA to parse the CSV and create an input table
2. For each dimension: run CREATE_HIERARCHY to register the hierarchy from the input table
3. Run REBUILD_AUTO_HIERARCHIES to finalize the cube and automatically translate and import any Essbase/EPM dynamic member formulas

After the cube structure is finalized, import the data as described in Step 5: Import Data below.

4a. Import Metadata: IMPORT_PBCS_METADATA

This procedure reads a Cloud EPM dimension export CSV from a Snowflake stage, parses it, and creates a Snowflake table containing the dimension hierarchy in a format ready for Casabase Cube. The table is created in the CASABASE_CUBE.SHARED_DATA schema with the naming convention <CUBE_NAME>_<DIMENSION_NAME>_INPUT.

CALL CUBE.IMPORT_PBCS_METADATA(
    '<CubeName>',
    '@<database>.<schema>.<stage>/<filename>.csv',
    '<DimensionName>',
    '<PlanType>'
);

Parameter	Type	Description
CUBE_NAME	VARCHAR	The name for your Casabase Cube (e.g., 'EPBCS', 'FIN_PLAN'). Use the same name for all dimensions that belong to the same cube.
STAGE_PATH	VARCHAR	The full path to the CSV file on the Snowflake stage, including the @ prefix (e.g., '@MY_EPM_DB.EPM_STAGE_SCHEMA.EPM_STAGE/ExportedMetadata_Account.csv').
DIMENSION_NAME	VARCHAR	The name of the dimension being imported (e.g., 'Account', 'Entity', 'Period'). If left blank, the procedure attempts auto-detection from the CSV content.
PLAN_TYPE	VARCHAR	The plan type suffix used in Cloud EPM column headers (e.g., 'Plan1', 'Plan2'). This is used to locate plan-type-specific columns like Data Storage (Plan1) and Aggregation (Plan1) in the CSV.

Example

CALL CUBE.IMPORT_PBCS_METADATA(
    'EPBCS',
    '@"CASABASE_CUBE_DEMO"."SAMPLE_DATA"."EPM_STAGE"/ExportedMetadata_Account.csv',
    'Account',
    'Plan1'
);

This call creates the table CASABASE_CUBE.SHARED_DATA.EPBCS_ACCOUNT_INPUT with the following structure:

Column	Type	Default	Description
PARENT	VARCHAR		The parent member name. Empty for the root member of the dimension.
CHILD	VARCHAR		The member name. Every member in the hierarchy has a row.
ALIAS	VARCHAR		The default alias (display name) for the member. Mapped from the Cloud EPM Alias: Default column.
OPERATOR	VARCHAR	+	The consolidation operator. Casabase Cube supports + (addition), - (subtraction), and ~ (ignore/no consolidation). Mapped from the Cloud EPM Consolidation or Aggregation column.
MEMBER_IS_SHARED	VARCHAR	false	'true' if the member is a shared (reference) member. Derived from the Cloud EPM Data Storage column when the value is Shared.
FORMULA	VARCHAR		The Essbase formula associated with the member, if any. Stored in raw Essbase syntax; automatically translated to Casabase Cube syntax during the REBUILD_AUTO_HIERARCHIES step.
TB_TYPE	VARCHAR		Time balance type: SUM, AVG, FIRST, LAST, or BALANCE. Derived from the Cloud EPM Time Balance and/or Account Type columns.
TB_TYPE_SKIP_VALUE	VARCHAR	NONE	Time balance skip value: NONE, MISSING, ZEROS, or MISSING_AND_ZEROS. Derived from the Cloud EPM Skip Value column.
UDA	VARCHAR		User-Defined Attributes (UDAs) associated with the member. Imported from the Cloud EPM UDA column.
SORTORDER	NUMBER		The sort position of the member within the hierarchy, preserving the original Cloud EPM outline order.

The IMPORT_PBCS_METADATA procedure automatically handles the following Cloud EPM-specific mappings:

• Consolidation / Aggregation: Maps Cloud EPM values (Addition, Subtraction, Multiplication, Division, Percent, Ignore, Never) to Casabase operators. Casabase Cube supports the + (addition), - (subtraction), and ~ (ignore/no consolidation) operators. Other EPM operators (*, /, %) are mapped but may need to be reviewed in the input table before creating the hierarchy.
• Data Storage: Identifies shared members (Shared) and dynamic calc members (Dynamic Calc).
• Account Type: Maps Revenue, Expense, Asset, Liability, Equity, Saved Assumption, and Non-Expense to the appropriate time balance type.
• Time Balance: Maps Flow, First, Last, Average, Balance values.
• Skip Value: Maps None, Missing, Zeros, Missing and Zeros.
• Plan-type-specific columns: When a plan type is specified (e.g., Plan1), the procedure looks for columns with the plan type suffix, such as Data Storage (Plan1), Aggregation (Plan1), and Formula (Plan1).

After the table is created, you can review and modify it as needed before proceeding to the CREATE_HIERARCHY step. This is your opportunity to fine-tune the metadata – for example, adjusting aliases, changing operators, or removing unwanted members.

4b. Create Hierarchy: CREATE_HIERARCHY

Once the input table is ready, use CREATE_HIERARCHY to register the dimension as a Casabase Cube hierarchy. This procedure reads the input table, builds the parent-child hierarchy, and configures it within the cube. When a FORMULA_COL is specified, CREATE_HIERARCHY records which column contains the raw Essbase/EPM member formulas. These are the dynamic calculation formulas assigned to members in Oracle Essbase and Cloud EPM (commonly referred to as “dynamic calc” or “member formulas”). The formulas are preserved in their original Essbase syntax at this stage – translation to Casabase Cube syntax happens automatically during the REBUILD_AUTO_HIERARCHIES step.

CALL CUBE.CREATE_HIERARCHY(
    '<CubeName>',          -- CUBE_NAME
    '<DimensionName>',     -- HIER_NAME
    '<InputTable>',        -- INPUT_TABLE_NAME
    'PARENT',               -- PARENT_COL
    'CHILD',                -- CHILD_COL
    'ALIAS',                -- ALIAS_COL
    'OPERATOR',             -- OPERATOR_COL
    '<DataTableColumn>',   -- DATA_TABLE_COL_NAME
    FALSE,                  -- USE_SECURITY
    'MEMBER_IS_SHARED',     -- IS_SHARED_COL
    'true',                 -- SHARED_VALUE
    'FORMULA',              -- FORMULA_COL
    'TB_TYPE',              -- TB_TYPE_COL
    'TB_TYPE_SKIP_VALUE',   -- TB_TYPE_SKIP_COL
    'SORTORDER',            -- SORTORDER_COL
    FALSE,                  -- IS_TIME_HIER
    'UDA'                   -- UDA_COL
);

Parameter	Type	Default	Description
CUBE_NAME	VARCHAR		The cube name. Must match the name used in IMPORT_PBCS_METADATA.
HIER_NAME	VARCHAR		The hierarchy (dimension) name as it will appear in the cube (e.g., 'Account', 'Entity').
INPUT_TABLE_NAME	VARCHAR		The fully qualified name of the input table created by IMPORT_PBCS_METADATA (e.g., 'SHARED_DATA.EPBCS_ACCOUNT_INPUT').
PARENT_COL	VARCHAR		The column name containing the parent member. For tables created by IMPORT_PBCS_METADATA, this is always 'PARENT'.
CHILD_COL	VARCHAR		The column name containing the child (member) name. Always 'CHILD' for imported tables.
ALIAS_COL	VARCHAR		The column name for the member alias. Use 'ALIAS' for the default alias, or pass a JSON object for multi-language aliases (e.g., '{"Default":"ALIAS","French":"FRENCH"}').
OPERATOR_COL	VARCHAR		The column name containing the consolidation operator. Always 'OPERATOR' for imported tables.
DATA_TABLE_COL_NAME	VARCHAR		The column name that this dimension will use in the fact (data) table. Typically the uppercase dimension name (e.g., 'ACCOUNT', 'ENTITY'). This maps the hierarchy to the data.
USE_SECURITY	BOOLEAN		Set to TRUE to enable row-level security for this dimension. When enabled, users must have explicit security grants to view members.
IS_SHARED_COL	VARCHAR	NULL	The column name identifying shared (reference) members. Use 'MEMBER_IS_SHARED' for imported tables.
SHARED_VALUE	VARCHAR	'true'	The value in the IS_SHARED_COL column that indicates a member is shared.
FORMULA_COL	VARCHAR	NULL	The column containing member formulas (dynamic calc formulas from Essbase/EPM). Use 'FORMULA' for imported tables. When specified, CREATE_HIERARCHY registers this column so that REBUILD_AUTO_HIERARCHIES can automatically translate and import the formulas.
TB_TYPE_COL	VARCHAR	NULL	The column containing time balance type. Use 'TB_TYPE' for imported tables. Relevant for Account-type dimensions.
TB_TYPE_SKIP_COL	VARCHAR	NULL	The column containing the time balance skip value. Use 'TB_TYPE_SKIP_VALUE' for imported tables.
SORTORDER_COL	VARCHAR	NULL	The column containing the sort order. Use 'SORTORDER' to preserve the original Cloud EPM outline order.
IS_TIME_HIER	BOOLEAN	FALSE	Set to TRUE if this is a time/period dimension. This enables time-series features such as time balance aggregation.
UDA_COL	VARCHAR	NULL	The column containing User-Defined Attributes. Use 'UDA' for imported tables.

Example: Account Dimension

CALL CUBE.CREATE_HIERARCHY(
    'EPBCS', 'Account', 'SHARED_DATA.EPBCS_ACCOUNT_INPUT',
    'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'ACCOUNT', FALSE,
    'MEMBER_IS_SHARED', 'true', 'FORMULA',
    'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA'
);

Example: Period Dimension (Time Hierarchy)

CALL CUBE.CREATE_HIERARCHY(
    'EPBCS', 'Period', 'SHARED_DATA.EPBCS_PERIOD_INPUT',
    'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'PERIOD', FALSE,
    'MEMBER_IS_SHARED', 'true', 'FORMULA',
    'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', TRUE, 'UDA'
);

Note that IS_TIME_HIER is set to TRUE for the Period dimension to enable time balance calculations.

4c. Finalize the Cube: REBUILD_AUTO_HIERARCHIES

After importing metadata and creating hierarchies for all dimensions, run REBUILD_AUTO_HIERARCHIES to finalize the cube. This procedure processes the hierarchies, prepares the cube for use, and automatically translates any Essbase/EPM dynamic member formulas into Casabase Cube formula syntax.

CALL CASABASE_CUBE.CUBE.REBUILD_AUTO_HIERARCHIES('<CubeName>', <RebuildAll>, <SkipSnapshots>);

Parameter	Type	Default	Description
CUBE_NAME	VARCHAR	NULL	The name of the cube to rebuild (e.g., 'EPBCS'). When NULL, rebuilds all cubes. Must match the cube name used in the previous steps.
REBUILD_ALL	BOOLEAN	FALSE	When TRUE, rebuilds all hierarchies in the cube regardless of whether they have changed. When FALSE, only rebuilds hierarchies that have been modified since the last build. Use TRUE for initial cube creation.
SKIP_SNAPSHOTS	BOOLEAN	FALSE	When TRUE, skips pre-rebuild hierarchy snapshots for faster execution (useful during development/testing). When FALSE, takes a snapshot of each hierarchy before rebuilding for rollback capability.

CALL CASABASE_CUBE.CUBE.REBUILD_AUTO_HIERARCHIES('EPBCS', TRUE);

The rebuild process: (1) takes hierarchy snapshots (unless skipped), (2) rebuilds each hierarchy via CREATE_HIERARCHY, (3) recreates TJ query functions, (4) imports formulas via IMPORT_ALL_FORMULAS which builds the member-to-dimension map once per cube rather than per hierarchy.

4d. Re-Import Formulas: IMPORT_FORMULAS (Optional)

Since REBUILD_AUTO_HIERARCHIES automatically translates and imports formulas, this step is typically not required during initial migration. However, IMPORT_FORMULAS can be called manually if you need to re-import formulas for a specific dimension – for example, after editing the raw formulas in the input table or after correcting translation issues.

CALL CUBE.IMPORT_FORMULAS('<CubeName>', '<HierarchyName>');

Parameter	Type	Description
CUBE_NAME	VARCHAR	The cube name (e.g., 'EPBCS').
HIER_NAME	VARCHAR	The hierarchy name to re-import formulas for (e.g., 'Account'). The procedure reads formulas from the hierarchy’s input table and re-translates them.

4e. Bulk Re-Import Formulas: IMPORT_ALL_FORMULAS (Optional)

For cubes with many dimensions that have formulas, IMPORT_ALL_FORMULAS is preferred over calling IMPORT_FORMULAS per hierarchy. It builds the member-to-dimension map once then processes all hierarchies, avoiding redundant map-building calls that can significantly slow down formula import for large cubes.

CALL CUBE.IMPORT_ALL_FORMULAS('<CubeName>', '<UpdatedBy>');

Parameter	Type	Default	Description
CUBE_NAME	VARCHAR		The cube name (e.g., 'EPBCS').
UPDATED_BY	VARCHAR	'SYSTEM'	Optional user identifier for audit tracking.

Step 5: Import Data into the Cube

After the cube structure is finalized in Step 4, import the level-0 data exported in Step 1. The IMPORT_ESSBASE_EXPORT procedure reads the native level-0 export format from both BSO and ASO cubes and creates a Snowflake fact table with a column for each dimension and an AMT column for the data values. The dense dimension is auto-detected from line 1 of the export file.

CALL CUBE.IMPORT_ESSBASE_EXPORT(
    '<StagePath>/<FileName>',
    '<TargetTable>',
    '<CubeName>',
    <IgnoreUnknownMembers>
);

The STAGE_PATH parameter accepts a full stage path including the filename. You can paste the path directly from the Snowsight stage browser (e.g., '@"DB"."SCHEMA"."STAGE"/exports/data.zip'). For native app references, omit the @ prefix (e.g., 'consumer_stage/file.txt').

Parameter	Type	Default	Description
STAGE_PATH	VARCHAR		Full stage path including filename. Paste directly from Snowsight stage browser (e.g., '@"DB"."SCHEMA"."STAGE"/Plan1_data.zip'). For native app references, omit the @ prefix.
TARGET_TABLE	VARCHAR		The fully qualified name of the target table to create or load into (e.g., 'MY_EPM_DB.EPM_STAGE_SCHEMA.EPBCS_DATA'). Must be specified as DATABASE.SCHEMA.TABLE. The table can also be created in the application’s own schema: 'CASABASE_CUBE.SHARED_DATA.EPBCS_DATA'.
CUBE_NAME	VARCHAR		The cube name (e.g., 'EPBCS'). Used to look up dimension mappings for member validation.
IGNORE_UNKNOWN	BOOLEAN	FALSE	When TRUE, data rows referencing members not found in the hierarchy are skipped with a warning. When FALSE, unknown members cause an error.

Complete Example: EPBCS Plan1 Migration

The following example demonstrates the full end-to-end process for migrating an Oracle Cloud EPBCS application with Account, Entity, Period, Scenario, Version, Currency, and Year dimensions:

-- ============================================================
-- Step 1: Create and configure the Snowflake stage
-- ============================================================
CREATE DATABASE IF NOT EXISTS MY_EPM_DB;
CREATE SCHEMA IF NOT EXISTS MY_EPM_DB.EPM_DATA;
CREATE STAGE IF NOT EXISTS MY_EPM_DB.EPM_DATA.EPM_STAGE;

-- Grant stage access to Casabase Cube
GRANT USAGE ON DATABASE MY_EPM_DB TO APPLICATION CASABASE_CUBE;
GRANT USAGE ON SCHEMA MY_EPM_DB.EPM_DATA TO APPLICATION CASABASE_CUBE;
GRANT READ ON STAGE MY_EPM_DB.EPM_DATA.EPM_STAGE TO APPLICATION CASABASE_CUBE;

-- Upload metadata CSVs and data files to @MY_EPM_DB.EPM_DATA.EPM_STAGE
-- (Use SnowSQL PUT command or Snowsight upload)

-- ============================================================
-- Step 2: Import metadata for each dimension
-- ============================================================
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Account.csv', 'Account', 'Plan1');
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Entity.csv', 'Entity', 'Plan1');
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Period.csv', 'Period', 'Plan1');
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Scenario.csv', 'Scenario', 'Plan1');
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Version.csv', 'Version', 'Plan1');
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Currency.csv', 'Currency', 'Plan1');
CALL CUBE.IMPORT_PBCS_METADATA('EPBCS', '@MY_EPM_DB.EPM_DATA.EPM_STAGE/ExportedMetadata_Year.csv', 'Year', 'Plan1');

-- ============================================================
-- Step 3: Review and adjust input tables (optional)
-- ============================================================
-- Inspect the generated input tables in CASABASE_CUBE.SHARED_DATA:
SELECT * FROM CASABASE_CUBE.SHARED_DATA.EPBCS_ACCOUNT_INPUT LIMIT 20;
SELECT * FROM CASABASE_CUBE.SHARED_DATA.EPBCS_ENTITY_INPUT LIMIT 20;

-- ============================================================
-- Step 4: Create hierarchies for each dimension
-- ============================================================
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Account', 'SHARED_DATA.EPBCS_ACCOUNT_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'ACCOUNT', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA');
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Entity', 'SHARED_DATA.EPBCS_ENTITY_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'ENTITY', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA');
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Period', 'SHARED_DATA.EPBCS_PERIOD_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'PERIOD', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', TRUE, 'UDA');
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Scenario', 'SHARED_DATA.EPBCS_SCENARIO_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'SCENARIO', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA');
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Version', 'SHARED_DATA.EPBCS_VERSION_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'VERSION', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA');
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Currency', 'SHARED_DATA.EPBCS_CURRENCY_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'CURRENCY', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA');
CALL CUBE.CREATE_HIERARCHY('EPBCS', 'Year', 'SHARED_DATA.EPBCS_YEAR_INPUT', 'PARENT', 'CHILD', 'ALIAS', 'OPERATOR', 'YEAR', FALSE, 'MEMBER_IS_SHARED', 'true', 'FORMULA', 'TB_TYPE', 'TB_TYPE_SKIP_VALUE', 'SORTORDER', FALSE, 'UDA');

-- ============================================================
-- Step 5: Finalize the cube (also translates and imports
-- dynamic member formulas from Essbase/EPM syntax)
-- ============================================================
CALL CASABASE_CUBE.CUBE.REBUILD_AUTO_HIERARCHIES('EPBCS', TRUE);

-- ============================================================
-- Step 6: Import data (fully qualified table name required)
-- ============================================================
-- Option A: Create the data table in an external database
CALL CUBE.IMPORT_ESSBASE_EXPORT(
    '@MY_EPM_DB.EPM_DATA.EPM_STAGE/Plan1_data.txt',
    'MY_EPM_DB.EPM_DATA.EPBCS_PLAN1_DATA',
    'EPBCS',
    TRUE
);
GRANT SELECT ON TABLE MY_EPM_DB.EPM_DATA.EPBCS_PLAN1_DATA TO APPLICATION CASABASE_CUBE;

-- Option B: Create the data table in the application's SHARED_DATA schema
-- (no additional grants required)
CALL CUBE.IMPORT_ESSBASE_EXPORT(
    '@MY_EPM_DB.EPM_DATA.EPM_STAGE/Plan1_data.txt',
    'CASABASE_CUBE.SHARED_DATA.EPBCS_PLAN1_DATA',
    'EPBCS',
    TRUE
);

-- ============================================================
-- Step 7 (optional): Re-import formulas for a specific dimension
-- (see Step 4d above)
-- Only needed if you edited raw formulas in the input table
-- after the initial REBUILD_AUTO_HIERARCHIES run
-- ============================================================
-- CALL CUBE.IMPORT_FORMULAS('EPBCS', 'Account');

Troubleshooting Cloud EPM Imports

Issue	Cause	Resolution
Import returns “No aggregation column found for plan type”	The Cloud EPM export does not contain an Aggregation (<PlanType>) column.	Verify the plan type parameter matches the column headers in the CSV. Check the CSV header row for the exact column name.
Members defaulting to + operator	Consolidation/Aggregation column not found or not mapped.	Open the input table and manually update the OPERATOR column as needed before running CREATE_HIERARCHY.
Shared members not recognized	The Data Storage column may have a plan-type suffix.	Ensure the plan type parameter is specified correctly. Verify the MEMBER_IS_SHARED column in the input table.
Formula translation errors	Complex or unsupported Essbase formula syntax.	Review the formula errors in the IMPORT_FORMULAS output. Edit formulas manually in the Casabase Cube formula editor.
Expected member not imported into Casabase Cube	The member is not enabled for the specified plan type in the Cloud EPM application.	Review the EPM metadata CSV export file and ensure the member’s value is set to TRUE in the Plan Type (<PlanType>) column (e.g., Plan Type (Plan1)). Members with a value of FALSE or blank (most common) for the plan type are excluded from the import.
Data import skips rows	Members in the data file not found in the hierarchy.	Set IGNORE_UNKNOWN to TRUE to skip unknown members, or verify all members exist in the dimension hierarchies.

Oracle Essbase Migration (XML)

For on-premises Oracle Essbase environments, Casabase Cube can import dimension hierarchies directly from an Essbase outline XML export. The process involves three phases:

1. Exporting the Essbase outline as XML
2. Loading the XML file into a Snowflake stage
3. Importing the outline into Casabase Cube

Step 1: Export the Essbase Outline

Export the outline from your Essbase application as an XML file using Essbase Administration Services (EAS) or MaxL.

Step 2: Load the XML File to a Snowflake Stage

Upload the exported XML file to a Snowflake stage and grant access to the Casabase Cube application:

CREATE STAGE IF NOT EXISTS MY_DB.MY_SCHEMA.ESSBASE_STAGE;
PUT file:///path/to/outline.xml @MY_DB.MY_SCHEMA.ESSBASE_STAGE;

GRANT USAGE ON DATABASE MY_DB TO APPLICATION CASABASE_CUBE;
GRANT USAGE ON SCHEMA MY_DB.MY_SCHEMA TO APPLICATION CASABASE_CUBE;
GRANT READ ON STAGE MY_DB.MY_SCHEMA.ESSBASE_STAGE TO APPLICATION CASABASE_CUBE;

Step 3: Import the Outline into Casabase Cube

You can import the outline either through the Casabase Cube UI or via the IMPORT_ESSBASE_OUTLINE_XML stored procedure.

Option A: Using the UI

1. On the Admin page, navigate to Import from Oracle
2. Enter the Stage Path (e.g., @MY_DB.MY_SCHEMA.ESSBASE_STAGE/outline.xml)
3. Enter the Cube Name for the new cube
4. Optionally enable Auto-register dimensions to automatically configure the imported dimensions
5. Click Import Outline

Option B: Using the Stored Procedure

CALL CUBE.IMPORT_ESSBASE_OUTLINE_XML('<CubeName>', '@<database>.<schema>.<stage>/<filename>.xml');

Parameter	Type	Description
CUBE_NAME	VARCHAR	The name for the new Casabase Cube (e.g., 'ASOSAMP').
STAGE_FILE	VARCHAR	The full path to the XML file on the Snowflake stage, including the @ prefix (e.g., '@MY_DB.MY_SCHEMA.ESSBASE_STAGE/outline.xml').

Example

CALL CUBE.IMPORT_ESSBASE_OUTLINE_XML('ASOSAMP', '@MY_DB.MY_SCHEMA.ESSBASE_STAGE/outline.xml');

The procedure parses the XML outline, extracts each dimension, and creates input tables in CASABASE_CUBE.SHARED_DATA with the naming convention <CUBE_NAME>_<DIMENSION_NAME>_INPUT. Each table contains columns for PARENT, CHILD, ALIAS, OPERATOR, FORMULA, DATA_STORAGE, and UDA.

After the import, you can review the input tables and then use CREATE_HIERARCHY and REBUILD_AUTO_HIERARCHIES as described in the Cloud EPM migration steps above to finalize the cube.

8.8 Application Upgrades

When a new version of Casabase Cube is available:

• Marketplace installs: Upgrades may be automatic (depending on your account settings) or can be approved manually from the application details page in Snowsight.
• Manual upgrade via SQL:

ALTER APPLICATION CASABASE_CUBE UPGRADE;

What Happens During an Upgrade

• Application logic (procedures, functions, Streamlit UI) is replaced with the new version.
• Configuration data (cubes, hierarchies, formulas, saved queries, security rules, audit log, variables) is preserved.
• The current and previous version numbers are recorded for reference.

Checking the Current Version

DESC APPLICATION CASABASE_CUBE;