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.
“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?
- Accounts are failing
- Adhoc thingies aren’t playing nice
- For the Love of Mike, even the Version dimension doesn’t work
- 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:
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.
