On-Premise Essbase to Oracle Analytics Cloud

Oracle Analytics Cloud is built around Oracle's Cloud version of Essbase . If you're starting from scratch, you can take advantage of OAC's many tools to import and build Essbase cubes, but how do you take existing cubes from an on-premise environment and migrate them to the cloud?

As it turns out, this process is straightforward and surprisingly clean, at least in my experience. Here's what you need to know to get started:

Pre-requisites

OAC provides tools to extract the app from your on-premise server to import to the OAC server, but there are a few prerequisites you need to be aware of, as well as a few considerations that must be made when designing your migration project.

OAC and the Essbase process is an area where I have been very impressed with the quality of Oracle's documentation. It's clear, it's well rounded, and feels complete. In the past, I've too often become flummoxed when looking for answers in Admin guides when I don't know the exact keywords I need to search for a particular subject, or if some subjects are generally glossed over. For OAC, however, I feel like Oracle's team has taken care of creating good, vetted, well-organized documentation for reference.

Thus, I'll simply link to their document on Preparing to Migrate On-Premises Application to the Cloud Service , but emphasize a couple of points I found to be significantly important in our migrations.

Unicode Mode

OAC requires the apps it imports to be saved in Unicode mode. Our client's cubes were not stored in Unicode, so we had to follow Oracle's steps provided here to convert them prior to any other activity. This is a step that must be identified and planned for early, as it is a show stopper if not completed and may take your support teams significant amounts of time to understand, plan for, and execute, depending on the number of apps, the familiarity of your resources, and prioritization considerations.

Unsupported Application and Database Settings

• Enable/disable Commands (enabled by default)
• Enable/disable Connects (enabled by default)
• Enable/disable Updates (enabled by default)
• Data and index cache size controls (defaults are fixed, but can be changed per application using INDEXCACHESIZE and DATACACHESIZE configuration settings)
• Minimum permission levels (create security filters prior to LCM export instead)
• Set lock timeout
• Currency conversion
• Disk volumes

You will need to evaluate the impact, if any, of these settings on your specific applications and determine alternate designs to accommodate any requirements they may affect.

Tools Used

The migration process utilizes a few new, OAC specific command line utilities that can be downloaded straight from the OAC environment.

LCM Utility

Since OAC does not have a direct counterpart to Shared Services, the LCM utility functions are built into the OAC web UI and can be controlled more specifically using the LCM command line utility. This is the recommended tool to use to extract an app from your on-premise environment.

You can save this utility to your local machine (on the same network as your on-premise Essbase environment) and use its command syntax to point to your on-premise server.

You can find detailed explanations of this tool and it's syntax here.

Command Line Interface

The second command line tool is the generically named Command Line Interface (CLI) tool. CLI allows you to connect to the OAC environment and issue commands to upload files, kick off scripts, and perform a variety of other functions on the server. If you have on-premise scripting built to manage your Essbase cubes' data management processes, you can call this utility as a means of issuing commands to Essbase directly.

You can read more about CLI and its catalog of commands here .

Process

The actual process to migrate is surprisingly simple.

• 1. Address any considerations made due to the listed prerequisites to migrating
• 2. Use the OAC LCM Utility to extract the application from the on-premise environment
• 3. Use the CLI utility to upload the zip file that was created during the export process to OAC
• 4. Use the OAC LCM Utility (or CLI) to import the application to OAC
  • a. Note: this step can be performed with either LCM, CLI, or even via the modern web UI of OAC Essbase (more on this interface in a future post). I have used all three to success, although the web UI is the simplest since there's no syntax to remember or potentially mistype/copy.
• 5. Verify everything migrated successfully

Notes from Practical Experience

Here's a couple of things I encountered while performing this process for our clients:

1. Clean up your on-premise app prior to exporting it.

The LCM utility provides the option of exporting data (or not) from the cube. Given that the cube in question had several gigabytes of data stored within it, I wanted to just extract the application itself, which would be drastically smaller. When I ran the process, however, it kept generating multiple 2 GB sized text files. After poking around, I realized this was because the level 0 exports from an old migration had been left in the folder structure of the app. That is, the data was not being extracted from the cube itself, it was simply being copied from the folder that held the application's file and support structure.

Additionally, if I had tried to load the data in these files, assuming they were fresh exports from the cube, I would have been importing data from whatever past migration they had originated in, which would have only caused more confusion downstream.

2. Removing these files saved a ton of processing time and disk space on the export file.

Additionally, it's also a good time to evaluate removing unneeded/retired scripts, formulas, and other objects within the application. This will clearly help create a 'clean' and easier to manage app once it is available in OAC.

3. Export/Upload/Load Data Separate from the Application

Due to the reasons already mentioned, it's clearly ideal to import just the application to be able to vet the structures and various objects prior to introducing data to the equation. This also saves a ton of processing time.

When performing these tasks, my preferred method was to export the app from the source environment via the LCM Utility, then use CLI to upload the file, then import the app via the UI. I like the UI and tried to do as much there as possible. As of Summer/Fall 2018, the UI was having some issues with uploading large files but worked fine for smaller sizes (less than 100MB or so). Your mileage may vary, especially since Essbase now versus then likely have an even better and more stable UI experience.

Summary

The migration process from on-premise to the cloud version of Essbase was smooth, with relatively few hiccups. Often with these new tools, it can feel like fitting a round peg into a square hole, but not here. The process was clean and simple, and it worked!

Contact us to learn more about OAC and Essbase, including data integration via ETL, MDM, and other tools or find us on LinkedIn, Facebook, Twitter, or YouTube. We would love to assist your organization in advancing to the next stage of your Business Intelligence and EPM evolution.