The idea for Essbase shadow cubes has probably been around as long as Essbase has existed in a production environment. Essbase is an OLAP tool -- two of the letters stand for "On Line" meaning it's probably pretty important. When you apply changes to an Essbase outline, that cube is no longer on line. Kind of a downer for an OLAP tool. So people invented clever ways of making copies of a cube, updating the cube and then redirecting users to the updated cube. All the while trying to minimize what could be an hours long process. Shadow Cubes minimize the effort involved.
Here's an overview of the shadow cube process.
1. Create a shadow cube.
This is currently only done using the REST API. If we could do this with, say, MaxL then this would probably be a single post. Instead I'm going to delve into the REST API as a part of this, hopefully not too long, series.
2. Make whatever changes you want to the shadow cube.
Since you're not touching the cube users are connected to you can do whatever you want here. You can go into the Jet UI (or EAS Lite) and make changes. You can load data, run calculations, update outlines. There are a few exceptions but you can pretty much do whatever you want here and use whatever tool you want, not just the REST API.
3. Promote the shadow cube.
Also currently only done using the REST API. If your changes don't go so well then another option here is to discard the shadow cube. So in one regard Oracle made this really easy to do. In another regard they made it nearly impossible for someone who knows nothing about the REST API. So consider this an opportunity to learn a new skill. It's not that hard, trust me.
Some important notes:
- Users can query data while the shadow cube is there. They cannot load data or run calculations.
- There is a brief outage during the time the shadow cube is promoted. How long is that? I would wager it depends on your infrastructure and the size of the cube. More experimentation is needed. In my tests using shadow cubes in Smart View, the user doesn't lose their connection during the promotion process. So it's possible many users will be unaware that the promotion has taken place. You might need to tell them in some ingenious way. Hopefully you put a timestamp somewhere in your cube. If you don't, you probably should.
- This is only available in Essbase 21c. It doesn't appear to be in the 19c documentation but you're probably not on that version anyway. It's definitely not available in 11.1.2.4. (You should start planning to upgrade to Essbase 21c if you haven't already.)
- Don't make infrastructure changes to the shadow cube. Don't do things like change names of applications or databases. Don't make partition changes. Don't make security changes. Here's what the official documentation says: During a promotion, all security layer associations on the destination application, such as users, groups, and security filters, are retained, while that of shadow/source are lost. The same rule applies for partition definitions.
My next post will be an introduction to the REST API for Essbase.
