Exporting & Importing Configuration

Casabase Cube can export a cube’s configuration as JSON and import a previously exported configuration.

Configuration export and import are administrative lifecycle capabilities that can be used for:

• Promoting cube configuration between environments
• Maintaining configuration in version control
• Creating reusable cube configurations
• Capturing configuration before significant changes
• Preserving a recoverable copy of cube configuration
• Recreating configuration in another compatible Casabase Cube environment

Configuration export is separate from cube data export.

The exported JSON contains the multidimensional configuration and metadata required to describe the cube, but it does not contain the cube’s underlying business data.

Conceptually:

Casabase Cube
     │
     ▼
EXPORT_CUBE_CONFIG
     │
     ▼
Configuration JSON
     │
     ├── Dimensions
     ├── Formulas
     ├── Saved Queries
     ├── Cube Variables
     └── Configuration Metadata

Fact Data
     │
     └── Not Included

Exporting Configuration

Configuration can be exported through the Casabase Cube interface or programmatically through SQL.

Using the UI

From Cube Config:

1. Select the cube.
2. Select Export.
3. Save the generated JSON configuration file.

The resulting file contains the exported cube configuration.

Using SQL

Use:

CUBE.EXPORT_CUBE_CONFIG

to export configuration programmatically.

For example:

CALL CASABASE_CUBE.CUBE.EXPORT_CUBE_CONFIG(
    'MY_CUBE'
);

The procedure accepts:

Parameter	Type	Description
P_CUBE_NAME	VARCHAR	Name of the cube to export.

EXPORT_CUBE_CONFIG requires the CUBE_ADMIN application role.

Exported Configuration

The exported JSON can contain:

Configuration	Description
Cube name	Name of the exported cube.
Dimensions	Dimension definitions, source mappings, hierarchy configuration, and supported dimension settings.
Formulas	Member formulas associated with the cube.
Saved queries	Saved query definitions associated with the cube.
Cube variables	Cube variable definitions and values.
Export information	Information about when and by whom the configuration was exported.

Conceptually:

Cube Configuration
       │
       ├── Cube
       ├── Dimensions
       ├── Hierarchy Metadata
       ├── Formulas
       ├── Saved Queries
       ├── Cube Variables
       └── Settings
       │
       ▼
EXPORT_CUBE_CONFIG
       │
       ▼
Portable JSON

The JSON currently represents dimension definitions in the:

hierarchies

collection.

This is the serialized configuration name. Conceptually, those records define dimensions and their associated hierarchy structures.

Exported Dimension Configuration

An exported dimension definition can contain configuration such as:

• Dimension definition table
• Parent and child column mappings
• Alias mappings
• Aggregation-operator mapping
• Cube data-column mapping
• Shared-member configuration
• Formula mapping
• Time Balance configuration
• Sort order
• UDA mapping
• Time-dimension designation
• Security setting
• Auto Rebuild setting
• Other supported dimension configuration

Optional properties are included where applicable to the dimension.

The export preserves the configuration describing the dimension.

It does not embed the contents of the dimension definition table itself.

What Is Not Exported

EXPORT_CUBE_CONFIG exports configuration rather than the complete contents of the cube.

The export does not include:

• Cube business data
• Contents of dimension definition tables
• Row-level security grants
• Source data files
• Data-load history

This distinction is important.

Conceptually:

EXPORT_CUBE_CONFIG

Included
────────
Cube Configuration
Dimension Definitions
Formulas
Saved Queries
Cube Variables


Not Included
────────────
Fact Data
Dimension Table Contents
Security Grants
Source Files
Load History

A configuration export should therefore not be treated as a complete backup of the cube’s business data.

Referenced Snowflake Objects

Referenced Snowflake objects are represented by their configured names rather than having their contents embedded in the JSON.

For example, an exported dimension might reference:

CASABASE_CUBE.SHARED_DATA.FINANCE_ACCOUNT

or a customer-owned definition table such as:

FINANCE_DB.PLANNING.DIM_ACCOUNT

The exported configuration preserves the reference.

It does not copy the referenced Snowflake object’s contents into the JSON.

Conceptually:

Configuration JSON
       │
       └── INPUT_TABLE_NAME
             │
             ▼
FINANCE_DB.PLANNING.DIM_ACCOUNT


DIM_ACCOUNT Contents
       │
       └── Not Embedded in JSON

When importing into another environment, the corresponding referenced objects must therefore be available to Casabase Cube if they are required by the imported configuration.

Note

Configuration files can contain information about the structure of your multidimensional model and references to Snowflake objects. Handle exported configuration according to your organization’s configuration-management and security policies.

Importing Configuration

A configuration previously generated by:

EXPORT_CUBE_CONFIG

can be imported through the Casabase Cube interface or programmatically through SQL.

Using the UI

From Cube Config:

1. Select Import.
2. Select a previously exported Casabase Cube JSON configuration.
3. Configure the available import options.
4. Select Import.

Using SQL

Use:

CUBE.IMPORT_CUBE_CONFIG

to import configuration programmatically.

For example:

CALL CASABASE_CUBE.CUBE.IMPORT_CUBE_CONFIG(
    '{ ... }',
    FALSE
);

The procedure accepts:

Parameter	Type	Default	Description
P_CONFIG_JSON	VARCHAR		JSON configuration generated by EXPORT_CUBE_CONFIG.
P_OVERWRITE	BOOLEAN	FALSE	Controls whether an existing cube configuration can be overwritten.

IMPORT_CUBE_CONFIG requires the CUBE_ADMIN application role.

Overwrite Behavior

By default:

P_OVERWRITE = FALSE

An import will not overwrite an existing cube with the same name.

Conceptually:

Import Configuration
        │
        ▼
Cube Already Exists?
        │
    ┌───┴───┐
    │       │
   Yes      No
    │       │
    ▼       ▼
Do Not    Import
Overwrite Configuration

Set:

P_OVERWRITE = TRUE

only when you intentionally want the imported configuration to update an existing cube.

Because overwrite changes an existing cube’s configuration, review the target and exported configuration carefully before using this option.

For important production changes, creating a current configuration export before performing an overwrite provides a recoverable configuration point.

Import Does Not Load Business Data

Importing a configuration does not import the original cube’s business data.

Conceptually:

Configuration JSON
       │
       ▼
IMPORT_CUBE_CONFIG
       │
       ▼
Imported Cube Configuration


Original Fact Data
       │
       X
       │
       ▼
Not Imported

Fact data must be loaded or otherwise populated separately as appropriate for the target cube.

This makes export/import suitable for configuration portability without automatically moving business data between environments.

Moving Configuration Between Environments

Configuration export and import can be used to move a cube configuration between Casabase Cube environments.

A typical workflow is:

Source Environment
       │
       ▼
EXPORT_CUBE_CONFIG
       │
       ▼
Configuration JSON
       │
       ▼
Review Environment-
Specific References
       │
       ▼
Target Environment
       │
       ▼
IMPORT_CUBE_CONFIG
       │
       ▼
Rebuild Dimensions
       │
       ▼
Load Target Data
       │
       ▼
HEALTH_CHECK
       │
       ▼
Verification Queries

This allows the multidimensional configuration to be promoted independently from the business data.

Environment-Specific References

Before importing into another environment, verify that the dimension definition tables and other referenced Snowflake objects required by the configuration are available to Casabase Cube in the target environment.

For example, development might use:

DEV_DB.PLANNING.DIM_ACCOUNT

while production uses:

PROD_DB.PLANNING.DIM_ACCOUNT

An exported configuration preserves its configured object references.

It does not automatically translate development object names into production object names.

Review environment-specific references before importing or rebuilding the target model.

Also verify that the Native App has the required access to any customer-owned Snowflake objects referenced by the imported configuration.

See Roles and Privileges for source-object access.

Rebuilding Imported Dimensions

After importing configuration, dimensions can be rebuilt from their configured dimension definition tables using:

CUBE.REBUILD_DIMENSIONS

For example:

CALL CASABASE_CUBE.CUBE.REBUILD_DIMENSIONS(
    'MY_CUBE',
    TRUE,
    FALSE,
    TRUE
);

Conceptually:

Imported Configuration
        │
        ▼
Dimension Definitions
        │
        ▼
REBUILD_DIMENSIONS
        │
        ▼
Active Dimension
Structures

Before rebuilding important production definitions, you can independently validate their source tables with:

VALIDATE_DIMENSION

See:

• Dimension Validation
• Rebuilding Dimensions

Loading Target Data

Because fact data is not included in the configuration export, a cube recreated through export/import requires its target data to be loaded separately.

Conceptually:

Configuration JSON
       │
       ▼
Import Configuration
       │
       ▼
Rebuild Dimensions
       │
       ▼
Load Target Fact Data
       │
       ▼
Complete Target Cube

The target data does not have to be the same data that existed in the source cube.

This makes configuration export/import useful for scenarios such as:

Development Configuration
           │
           ▼
Production Environment
           │
           +
Production Data

or:

Reusable Model Configuration
           │
           ▼
New Cube
           │
           +
Different Data

Configuration Backup

Configuration export can be used to capture a point-in-time copy of a cube’s configuration.

For example, before a significant configuration change:

Current Cube
     │
     ▼
EXPORT_CUBE_CONFIG
     │
     ▼
Configuration Backup
     │
     ▼
Make Configuration Change

If necessary, the exported configuration can later be used as part of a configuration recovery process.

However:

Configuration Backup
        ≠
Complete Data Backup

The JSON does not contain the cube’s fact data or the contents of referenced dimension definition tables.

A complete recovery strategy must therefore account separately for the underlying data and any required source objects.

Configuration Management

Because the export is JSON, organizations can use exported configurations as part of their normal configuration-management practices.

For example:

Cube Configuration
       │
       ▼
EXPORT_CUBE_CONFIG
       │
       ▼
JSON File
       │
       ▼
Version Control /
Change Management

This can provide a record of configuration changes over time.

Exported configurations may also be useful for:

• Change review
• Environment promotion
• Release preparation
• Configuration comparison
• Recovery planning
• Reusable model templates

The appropriate process depends on the organization’s broader change-management and governance practices.

Export / Import vs. Clone Cube

Configuration export/import and cube cloning support different administrative lifecycle workflows.

	Export / Import	Clone Cube
Primary purpose	Preserve or move configuration	Create another cube directly from an existing cube
Format	Portable JSON	Direct cube operation
Cross-environment use	Designed for configuration portability	Primarily within the current Casabase Cube installation
Configuration included	Yes	Yes
Fact data included	No	When P_REBUILD = TRUE
Dimensions rebuilt automatically	No	When P_REBUILD = TRUE
Typical use	Environment promotion, configuration backup, configuration management	Development, testing, sandbox, replica creation

The important distinction is:

Export / Import
      │
      └── Configuration Portability


Clone Cube
      │
      └── Direct Cube Replication

With cloning:

P_REBUILD = TRUE

creates a populated replica by rebuilding the dimensions and copying the source fact table.

With:

P_REBUILD = FALSE

the clone contains configuration only, its dimensions remain inactive until rebuilt, and the source fact table is not copied.

See Cloning a Cube.

Export / Import vs. Source Migration

Configuration export/import should also not be confused with migrating an Oracle Essbase or Oracle Cloud EPM model into Casabase Cube.

These workflows have different purposes.

Casabase Cube Configuration Portability

Existing Casabase Cube
        │
        ▼
EXPORT_CUBE_CONFIG
        │
        ▼
Configuration JSON
        │
        ▼
IMPORT_CUBE_CONFIG
        │
        ▼
Another Casabase Cube Environment

Oracle Migration

Oracle Essbase / Cloud EPM
        │
        ▼
Native .otl
        │
        ▼
Casabase Cube Model
        │
        ▼
Native Level-0 Export
        │
        ▼
Cube Data

Use the dedicated migration workflow when the source model is Oracle Essbase or Oracle Cloud EPM.

See:

• Migrating from Oracle Essbase
• Migrating from Oracle Cloud EPM

Validating an Imported Configuration

After importing and rebuilding a cube, validate the resulting environment before making it available to users.

A recommended sequence is:

IMPORT_CUBE_CONFIG
        │
        ▼
Review References
        │
        ▼
VALIDATE_DIMENSION
        │
        ▼
REBUILD_DIMENSIONS
        │
        ▼
Load Target Data
        │
        ▼
HEALTH_CHECK
        │
        ▼
Verification Queries

Not every imported model requires every step, but important production promotions should verify both structural and business correctness.

Use:

CALL CUBE.HEALTH_CHECK('MY_CUBE');

for broader cube validation.

See Health and Diagnostics.

Security Considerations

Configuration exports can contain information about:

• Cube structure
• Dimension definitions
• Snowflake object references
• Formulas
• Saved queries
• Cube variables
• Security-related dimension configuration

The export does not include row-level security grants.

When importing into another environment:

• Review the target application’s role grants.
• Review source-object access.
• Review security-enabled dimensions.
• Configure or verify appropriate row-level security rules.
• Do not assume the target environment has the same users or access requirements as the source.

See:

• Roles and Privileges
• Access Control
• Security Model

Recommended Practices

When exporting and importing configuration:

• Export configuration before significant production configuration changes.
• Store exported configuration according to your organization’s configuration-management policies.
• Treat the JSON as potentially sensitive structural metadata.
• Remember that the export does not contain business data.
• Remember that the export does not contain the contents of dimension definition tables.
• Review Snowflake object references before importing into another environment.
• Verify Native App access to referenced customer-owned objects.
• Use P_OVERWRITE = TRUE only when intentionally updating an existing cube.
• Rebuild imported dimensions as required.
• Load target fact data separately.
• Review security after importing into a different environment.
• Run HEALTH_CHECK after significant imports.
• Run representative queries before relying on an imported production configuration.
• Use Clone Cube instead when direct cube replication is the objective.

Key Takeaways

• EXPORT_CUBE_CONFIG exports portable Casabase Cube configuration as JSON.
• The export can include dimension definitions, formulas, saved queries, cube variables, and configuration metadata.
• Cube business data is not exported.
• Dimension definition table contents are not exported.
• Row-level security grants are not exported.
• Referenced Snowflake objects are represented by configuration references rather than embedded contents.
• IMPORT_CUBE_CONFIG imports configuration previously generated by Casabase Cube.
• P_OVERWRITE controls whether an existing cube configuration can be overwritten.
• Export/import is suitable for environment promotion, configuration backup, recovery planning, and configuration management.
• Target dimensions can be rebuilt from their configured definition tables after import.
• Target fact data must be loaded separately.
• Environment-specific Snowflake object references should be reviewed before import.
• Export/import and Clone Cube solve different lifecycle requirements.
• Clone Cube can include fact data when P_REBUILD = TRUE; configuration export/import never includes fact data.
• Both export and import procedures require the CUBE_ADMIN application role.

Related Topics

• Cloning a Cube
• Dropping a Cube
• Operational Tasks
• Health and Diagnostics
• Roles and Privileges
• Access Control
• Dimension Validation
• Rebuilding Dimensions
• Cube Settings