The “Source Cube,” or “Source Plan Type,” is a feature of Oracle Planning and Budgeting Cloud Service (PBCS) that determines the flow of data between the models or plan types of an application.
The idea behind this is that the plan for a model is authored in one plan type, and the others use that as a source, automatically, without the need to move data. This is driven by the dimension tagged as type “Account.”
When building a planning application with more than one model, the account dimension is built with separate hierarchies for each model – the relevant hierarchies are enabled only for the specific plan type / model.
However, it is not unusual to have members that are common across models. In such cases, the BSO plan types that are not the ‘source’ for a member, get a member formula with an XRef to the member in the source plan type. This is implemented in the Oracle Essbase back-end, and is not obvious in the web interface.
Why it can this be a problem?
The XRef member formulae allow for dynamically retrieving data on-demand, without the need for any other process. While this is theoretically a good thing, there are a few situations where this may not be the best way to go. As the size of the dimension grows, the number of such ‘dynamic’ members grows as well. And since data pulls via XRef get data one cell at a time, performance will slow as the size of the block increases. In other words, as the dense ‘Account’ dimension grows, the negative performance impact is twofold.
Additionally, if a dense restructure of the cube is triggered, every member formula is validated. And this can increase the restructure time. Imagine a retrieve being performed on the entire Account dimension! Such a dense restructure is not difficult to encounter in a multi-model planning application, since PBCS performs a “Refresh Database” on all plan types, every time.
With the advent of ASO plan types, it can be tempting to load actuals data into the ASO cube, and use it as a source for the BSO cubes. While this can be done, this method suffers from the same drawbacks as the two previous situations because the BSO plan types will all have XRef member formulas pointing to the ASO source.
How to get out of this?
There are two ways to get out of this, and the first one is more of a best practice: avoid making the ASO plan type as the source. Since ASO cubes do not use XRef member formulae, setting a BSO cube as a source will reduce one such data flow path. The second option is to use the HSP_NOLINK UDA.
Applying the HSP_NOLINK UDA to the Accounts dimension tells PBCS’s underlying database, Oracle Essbase, to disregard the “Source Cube” feature, and to not link the cubes via the XRef member formula. The drawback to this is that data is not automatically sourced on-demand between the plan types. However, this is not something that difficult to overcome. The “Map Reporting / Data Maps” feature moves sets of data between plan types, and the “Smart Push” capability allows for such moves to be triggered off data entry web forms.
How to apply this?
While analyzing your application to make the determination of which approach to take, start by making a list of account members that are unique to each plan type (cube). These are a no-brainer, as the cube is the source for these. For the ones that are shared, if only one of them is a BSO cube, make that the source. It gets trickier when the member is shared between multiple BSO cubes. In such a case, unless the design of the application calls for data flow between the cubes via the implicit XRef pulls, use the HSP_NOLINK UDA and save yourself a world of pain.
Hopefully you have found this helpful in figuring out one (albeit important) aspect of application design when using Oracle PBCS. Check back every so often for more such tidbits that we share from lessons we learn using these tools every day of our working lives.