Want to hire me? For availability and scheduling please email info@arcepm.com

29 February 2016

The Compleat Idiot’s Guide to PBCS, No. 6 – Philip Hulsebosch and Valid Intersections

This is your host

Yr. Obt. Svt. may be the host but Philip Hulsebosch has again done all the work.  It is, as usual, top drawer stuff and yet another dive into the coolness that is PBCS.  
Sit back, adjust your comfy slippers (well, I’m writing this in my comfy slippers; hopefully you are in yours as well), and give this a read.  It’s well worth your time.
A note about comfy slippers – I take my sartorial hints from Fred MacMurray for which I blame a childhood of watching My Three Sons.  Check out this episode – not only are the slippers in play but so is the cardigan sweater throughout the episode.  Think about it – I largely work from home doing something that hardly anyone understands (Just what did Steve Douglas do for a living?  I couldn’t ever figure it out.), I wear slippers just like this (slate floors are cooooold), and the modern day equivalent of that cardigan.  I’m livin’ the dream.
And with that minor digression about Cameron’s complete lack of fashion sense – unless you live as I do in 1961 – out of the way, on with Philip’s considerably more relevant work.

Valid Intersections.

The functionality of “Valid Intersections“, currently available in the “Planning Budgeting Cloud Service” (PBCS), is subject worthy of review because it gives write access to a node of two or more dimensions and read access to those areas that are not defined in the set. Finally Planning can assign access to detailed member level intersections - something we we’ve been able to do in Essbase for a long time.
With Valid Intersections, we can define sections in the database as having “cross-dimensional irrelevance” and assign read-only access to them. By doing so, we prevent data being stored accidently, where they should not be and enable the relevant slices for data input.
Let me give an example: When you have an account as “Mobile Subscribers” and you have product categories “Mobile”, “Fixed Line” and “Cable”, then it is logical to have data only in the first category. One could create a Valid Intersection of the Account “Mobile Subscribers” and Product category “Mobile”. This would make the combinations with “Fixed Line” and “Cable” read-only.
Set Theory
Valid Intersections are based, like many of the functions in a multidimensional database, on Set Theory. Last, when I was working on this subject of Valid Intersections, my son entered the office. I told him that I was working again with Set Theory and how much I benefited from learning about this subject in school in a parental attempt to motivate him for subjects at school which might not be in line with his current interests. He said, “interesting”, looked at my screen and asked why I did not have a touch screen and just mark in a graphical interface the intersections I needed. That was so much easier… well, … a good question! Today, it is all about the interface.
Back to Set Theory – see, the stuff we learn in school really is relevant later in life no matter how much the 16 year old in us rebels. In Figure 1 you see a diagram with an intersection of two circles A and B. These represent Dimensions. In a Valid Intersection, you define A in a rule and B in a rule. As a result, the red area means write access, the white area means read access.
Figure 1: A Venn diagram illustrating the intersection of two sets. Red is the intersection of A and B and would result into write access.

How do I define “Valid Intersections” ?

The functionality to define “valid intersections” is only available in the “Simplified Interface”. It is the user interface of the future for both the administrator as well as the power user. In the last days, I have worked extensively with it on a PC and I really like it. The Tablet is also possible, but I love my large computer screen and keyboard. It makes me so much more efficient.
After logging into PBCS, select the Option “Console”, then select the third tab at the left side with the name “Valid Intersections” and it will open a window. Here you see existing “Valid Intersections” and at the top left a menu for adding or modifying them.
Figure 2: Overview of the Valid Intersections.
In this post, I want to show how to create “Valid Intersections” in the “Vision” application. In this example, the yellow marked areas should be write-enabled for scenario “Forecast” and “Plan”. The dark yellow areas should only have write access for “forecast”. All other areas should have read access. In the rows is the dimension “Entity” and in the columns is the dimension “Products”.
Figure 3: Example to apply Valid Intersections in the Vision application.
By pressing the button “Create” a new Intersection can be created. First, you need to think about which Dimension should be the “Anchor Dimension”. This is the….
I will take the “Entity” dimension and along this dimension, I will create various rules.
Figure 4: Selection of the Anchor Dimension.
I will give it the name “Entity-Product”, so I can see in the name which Dimensions are used in the Intersection.
Figure 5: Option “Unselected members are valid” is activated.
I have enabled the option “Unselected members are valid”. This means, all not selected members in this dimension are not part of the set and thus read only.
The next step is to select the “Product” dimension, by clicking the “Add Dimension” button.
Figure 6:  Selection of an additional dimension.
I tag this dimension to be required. So a selection is needed for all rules within this Valid Intersection.
Figure 7: Enabled the required option for this dimension.
Now, I can create the different rules. To do this, I click at the button “Add Rule” and the selection window with the two dimensions opens. At the top of the window, you can switch between the dimensions while selecting the intersection. Check Figure 8 for details.  Members can be selected by mark next to the name and functions are available at the right side of the member name.
Figure 8: Selection in the dimension “Product”.
At the right top side of the page, you can find the menu with the display options.
Figure 9: Display options.
When you are familiar with the member names, you can type them into the box. It is not necessary to select them in the member selection.
Figure 10: Editing the selection by typing.
Click the “Save and Close” button and the Valid Intersection is added in the list.
Figure 11: Valid Intersections. The top one is disabled.
Now let’s see this on an Ad-Hoc report. A refresh on an existing report shows the result. A logout and new login is not necessary. The entities “420“ and “421“ and the child products of “TP1“ were defined in a Valid Intersection. These are write-enabled, while the rest become read-only.
Figure 12: Result of the Valid Intersection definition.
Adding a new rule to the Valid Intersection. I can edit the rule on the window and I do not need to go into the member selector.
Figure 13: Adding a new combination of members as a rule.

A new query. The results become immediately visible.
Figure 14: Result of the changed Valid Intersection definition.
And now adding the last rule and hand-pick the elements of the product dimension.
Figure 15: And we add another combination into a rule.
With this, the third section of rows has been defined.
Figure 16: Result of the changed Valid Intersection definition.
And now, I combine the remaining entities “410“, “450“ and “810“ with the dimension member “Product”. This is quick and dirty, but it works, because these members will become read-only.
Figure 17: Adding the last rule.
With this, all sections are now defined. Let’s check the results.

Figure 18: Result of the changed Valid Intersection definition.
I change the account. Good, the access rights do not change on the entities and products.
Figure 19: Result after selecting a different account.
Now I change the scenario. The write enabled sections do not change.
Figure 20: Result after selecting scenario “Actual”.
Now I have to make the difference between scenario “Forecast” and “Plan”. In “Forecast” we wanted to add write access to the Entities “410”, “450” and “810”. So we have to extend the current Valid Intersections.
You can easily duplicate a Valid Intersection. Then it is really easy to modify it.
Figure 21: Duplicate a Valid Intersection.
Figure 22: Result from the duplication step.
Then I will rename the intersection into “Entity-Product - Forecast“.
To make the difference between Scenario’s, I will need to add this dimension into the Valid Intersection. I will select the member “Forecast” in each row. In the last row with the entities “410”, “450” and “810” I replace the “Product” for “Children(P_TP1)”.
Figure 23: Changed the selection in this new Valid Intersection.
Figure 24: Result after saving.
The month has been changed into “July” to see the effect on scenario Forecast, but as you can see in figure 25, the entities are not write-enabled! What is wrong?
Figure 25: Result of selecting scenario “Forecast”. Nothing has changed.
The reason is both valid intersections add up. I will select “Budget” in the scenario and I see the rule with “forecast” works.
Figure 26: Result after selecting scenario “Plan”. The intersections are adding up and scenario “Plan” is not in the intersection anymore.

Figure 27: Menu options under “Action”.  In Englisch, the menu choices are:  edit, duplicate, delete, up, and down.  German is the Esperanto of the future.  
It is simple to enable and disable Valid Intersections. Just remove the green checkmark in the column Activate. As in figure 28 shown, a green checkmark it is enabled and a grey one means it is disabled.

  
Figure 28: Enable and disable a Valid Intersection.

I disable the Valid Intersection “Entity-Product”.
Figure 29: The first Valid Intersection is disabled.
And now, entity “410” in “Forecast” is write-enabled. So that is verified to be the reason. I will need to modify the Entity-Product Valid Intersection.  
Figure 30: Result when selecting scenario “Forecast”. Also entity “410” is write-enabled.
And in scenario “Plan” it is not as can be seen in figure 31.
Figure 31: Result with scenario “Plan”.
In the Valid Intersection Entity-Product, I add also the dimension Scenario. In each row, I add “IChildren(Scenario)”. I enable this Valid Intersection after saving. Now, both Valid Intersections are active again.
These are the 4 rules now:
Figure 32: Valid Intersection 1 has been adjusted.
Refreshing the reports. Scenario “Forecast” is now correct.
Figure 33: The result in scenario “Forecast” looks correct.
Scenario “Plan” looks also OK.
Figure 34: Result in scenario “Plan”. It is correct, because entity “410” is read-only.
It is possible to reduce the number of rules to a minimum ….
Figure 35: The Valid Intersection has been reduced to the relevant part.
And it is also possible to combine both Valid Intersections into one.
Figure 36: Combination of the rules in both Valid Intersections into one Valid Intersection.
A check and the results stay correct!

The option Unselected members are valid.

To show the effect of the option “Unselected members are valid" I will extend the current report with additional entities. These entities are “815”,”830” and “840”. In the Valid Intersection, I select the anchor dimension Entity and open the menu. Here I make sure the “Unselected members are valid" is enabled.
Figure 37: Entity with the option “Unselected members are valid".
The members “815”, “830” and “840” are write-enabled in the scenario “Plan” and “Forecast”.
Figure 38: The members “815”, “830” and “840” are write-enabled.
Figure 39: Also in Forecast are members “815”, “830” and “840” write-enabled.
I will switch off the option “Unselected members are valid". This will take care that the members not selected become read-only.
Figure 40: Entity with the option “Unselected members are valid" disabled.
The result is as expected. The entities “815”, “830” and “840” who now are excluded from the selection set are read-only.
Figure 41: The entities “815”, “830” and “840” are read-only in the scenario “Forecast“.
Figure 42: Also in the scenario “Plan“ are the entities “815”, “830” and “840” are read-only.
Now we have reached our goal which is displayed in figure 43.
Figure 43: Overview of the write enabled areas for scenario “Plan” and “Forecast“.

Conclusion

Valid Intersections gives us a very nice possibility of access control. It can be defined up to the single cell level, which was not possible until now in Oracle Hyperion Planning. This functionality is available in PBCS and likely will be coming soon in the on premise version as well.
I did not check if Valid Intersections also work with data load. In the data forms it is working very well and I hope this post helps you on this subject.

Yr. Obt. Svt.‘s conclusion

I’m not sure what is more amazing:  Planning finally supporting ANDs in security or Philip’s ability to clearly explain a complex concept and process in a clear way.  Okay, what’s even more amazing is his willingness to do this as a guest writer.  This was no quick note as Word tells me this is page 20 which is proof, if proof was needed, that his committment to the Oracle EPM’s community’s education is deep and sustaining.
Philip’s clients are lucky to have him.  We’re lucky to have him as a blogger (in Englisch), writer, and presenter.
Be seeing you.

24 February 2016

The Compleat Idiot's Guide to PBCS, No. 5 -- Migrating from PBCS to On-Premises Planning

Wrong Way Corrigan

There are plenty of blog posts, videos, and Oracle documentation on how to go from on-premises Planning to PBCS.  But what about the other way round?  What if you want to take a PBCS application and migrate it to on-premises?  It is actually doable and not all that hard.  

Why would you want to do this keeping in mind the lower level of functionality in on-premises (as of the writing of this post and 11.1.2.4)?  Beyond the “OMG, PBCS isn’t what we thought it would be.  Eject, eject, eject” use case which I don’t think is particularly likely I see these as:
  • Developers need to make changes to hierarchy, calculations, forms (with some caveats about functionality) outside of the development environment (think dev, qual, and prod)
  • Prototyping within a limited PBCS instance environment for customers and consultancies that can’t spring for more than one instance
  • Customers that have a real production environment and treat PBCS as their development environment
  • Any kind of hack is super cool and besides it gives one’s inner geek insight into how PBCS works beneath the covers

So is this approach the wrong way?  It’s certainly possible that the above may fit one of your uses cases.  Just remember that all of the neat-o, gee whiz, spiffy deluxe functions as below are not currently in on-premises.  I’ll do my best to show how to get round these although I may not be catching every function:
  • Smart Forms
  • Smart Push
  • Sandboxing
  • Valid Combinations
  • I’m sure there’s something else but I can’t think of what it is.  You PBCSer’s with more experience than yr. obt. svt. will be able to tell us.  Comment away to this post and I’ll include your notes.

Imports Aweigh

As you remember from my post on my inability to correctly zip a LCM file, PBCS supports LCM although it is called Application Management.  Assuming I actually manage to export an application and then bring it down to my on-premises instance and then make the even greater leap to importing the zip file, Shared Services looks like this in my 11.1.2.4 VM instance on PBCS application import:

Who’s got my data?

Thinking that this worked like an on-premises LCM migration, I created a Planning data source (HYP_PBCSVision) and a Planning app called Vision with the Plan Types from the LCM artifacts.  I ran the import and…

Ah, the datasource name.  I find it intriguing, sort of, that it is named PlanningDatasource1.  If there’s a
“1” maybe there will one day be a “2”?  A geek can dream.

Begin the Beguine

Dimensions

After creating a Planning data source with the name “PlanningDatasource1”, I ran the import again and got:
The dimension Year doesn’t exist?  Is this some kind of weird-o PBCS thing that changes the name of the dimension?  It’s certainly there in on-premises:

And it’s there in the PBCS LCM artifacts as well.  What’s going on?

It is one of yr. obt. svt.’s more glorious moments.  Did you see what I selected up at the top?  Plan Types but not Global Artificats?  Arrrgh.

Select the right Global Artifacts so that there actually is a Year dimension.

KABOOM
Wow, that didn’t work the way I hoped it would.

What’s not working here?
  1. Accounts are failing
  2. Adhoc thingies aren’t playing nice
  3. For the Love of Mike, even the Version dimension doesn’t work
  4. HSP_View?  Whazzat?

Other than that, everything’s tickety-boo.

Insane in the Membrane

Hewing to the commonly held definition of insanity, and putting aside all of the other things that went tits up the last time round, I tried reimporting the standard dimensions:

And had fewer (and smaller) errors.  Yes, sorry for the small typeface but I’m not going through all of this again just to make it easy to read.  I should think about how this is going to look when I write it all up but as I could barely get it to work I’m glad I made it hard to read.  Whew, that was a mouthful.

Everything Happens to Me

The important one is here.  “Sandbox Enabled”?
We have now reached one of those it-ain’t-in-on-premises-yet features.  Sandboxing data is possible in PBCS via Version dimension functionality but the concept just doesn’t exist for on-premises.  And that failure of Version to get created makes the member formulas for Earnings Per Share fail because they reference the Version dimension.  Bummer.

On a Clear Day (You Can See Forever)

It’s easy to find in the LCM Version.csv file:

And just as easy to delete:

As with on-premises, dimensions are also available from the Administration’s menu Import and Export Metadata to File functionality.

Minus all of the LCM-specific header records, the columns are the same:

With much of the application already built, I could import that dimension directly via the same process on the way into on-premises.

However it’s done, the result is (less Sandboxing) complete:

Too clever by half

Ever wondered what the name of the Essbase applications and databases are in PBCS?  You know, the ones you can’t see ‘cos there ain’t no EAS?  Refresh the database to Essbase and there they are:

NB – Vision corresponds to the application name; AVision and BVision hold the ASO plan types.  Interesting, no?

If I have Essbase databases, I can bring in data.  Or can I?

Bugger

Unicode?  Oops.  I didn’t create my Planning datasource with an Essbase unicode connection and it looks like PBCS uses that by default.  As an aside, I don’t know why any Planning or Essbase application doesn’t use Unicode by default but that’s above my pay grade.

Surely I can get round that with EAS?  Uh, no.

Given that I goofed, the easiest way round this encoding issue is to convert the data from UTF-8 to ANSI or at least that’s what I think I need to do.  An easy way, assuming there’s enough memory to do so, is to open the file in Notepad and then do a File->Save As.  The encoding type will be right there next to the Save button.

I used my very favorite text editor, Notepad++, to do convert from UTF-8 to ANSI.  Yes I could have done that in Notepad but I lurv Notepad++ and it works for much bigger files:

If you want a treatise on Encode vs. Convert, have a read here.

I also could have used the Essbase Unicode File Utility but find Notepad++ to just be a whole lot easier.  

As a further aside, I could have converted the Vision application to Unicode if I wanted to:

But not the ASO applications:

The odd thing about the ASO database  data loads is that I did not need to go through a Unicode to ANSI conversion.  The data came in the native file format and I can only conclude that Essbase treats the data encoding differently between the two database types.  Or it’s a bug.  I’d be interested to hear if anyone knows for sure.

With that, data can now be loaded via a load rule.  Yes, I could have brought this back inside the LCM folder hierarchy but I’m tired of that tool.  Besides, I’ve finally gotten this beast into EAS so I’m not letting go.

Success!  Boil in bag!


Is all well?  Well (I kill myself), no, it isn’t.  Yes you saw a successful import, but what you didn’t catch was this data column that I had to ignore in the Load Rule.

What is BaseData?  What indeed.  It’s there in Philip Hulsebosch’s post on PBCS and Smart Push but not in LCM.  Huh?  BaseData is part of the HSP_View dimension which supports Sandboxing which (a bit of a run-on sentence here) is not in LCM’s dimensions.  It’s an intrinsic part of PBCS just like the HSP_Rates dimension in multicurrency Planning apps which are also not specifically defined in LCM.  The application import takes care of this once it realizes that the application is Sandbox Enabled.

The dilemma is that there isn’t an on-premises Sandboxing function.  What to do?  One approach would be to ignore the HSP_View dimension but as we’re replicating PBCS and because the forms all need the dimension, it must be added.  But how given that LCM doesn’t support it?  

Just as with the Version dimension, simply export it from PBCS’ metadata export:

The output from that PBCS metadata export:

Import it in through on-premises’ metadata import function after first creating the dimension.



Ta da, we now have a HSP_View dimension.

The Rest of the Story

There are other artifacts to import but hopefully we’re (I’m) a bit more cognizant of the limitations of on-premises vs. PBCS.  Alas and alack, Jobs and Valid Combinations Rules (especially alack on the latter) aren’t supported in on-premises, so they need to be excluded from the import.

Let’s bring in relational data objects, excluding those oh-so-cool-and-oh-so-not-there-in-on-premises Sandbox Changes:

And KABOOM yet again:

I didn’t do security.  Arrgh.  Let’s do it:

I’m blurring the specific names but the types are Planner, Poweruser, Service Account, and Viewer.  The two groups I need to care about for security are Finance Management and Vision Planner.  I must first create them in Shared Services as they don’t exist.  With that done, I can import them.

Users

As I have security that is not assigned by group, I have to create the PBCS email-driven usernames, e.g., cameron@somethingorotherandthisisntreal.com.

Groups


Text artifacts can then be imported.

Tablets

I did have a spot of bother with forms being available in Tablet mode and ended up manually selecting them:

The end of the beginning

That should be it, I hope.  Is my PBCS-to-on-premises Vision the same barring the functionality that’s not quite there in on-premises?  

PBCS

On-premises


The Roses of Success

That was quite the trip but proof that with a few hacks here and there it’s actually quite easy to bring PBCS down to on-premises Planning.  

Only Oracle and your company’s contracts department know if any of the above is actually legal.  You Have Been Warned.

I love hacks, cf. the name of this blog.  When the hacks are useful so much the better.  Hopefully this post falls into that useful category.  I know it made me better understand PBCS and as the purpose of the Compleat Idiot’s Guide to PBCS is to educate we on-premises practitioners, I think it meets that condition.

Be seeing you.