Technology Blueprints & Strategy with Gary Crisci

While recently working on a project to migrate an on-premise Hyperion Planning application to Oracle Planning and Budgeting Cloud Service (PBCS) I ran into a requirement to export data from the application to a downstream data warehouse. On premise this is handled with a BSO export calculation script. One of the changes we implemented when moving the app to the cloud was to take advantage of the ASO reporting cube plan type to eliminate the need to run aggregations on the BSO plan type. This decision however caused a challenge for exporting the data. When evaluating options we recognized that while we could use a business rule to export the data from the BSO plan type, not all the data we needed was available since we were not aggregating the BSO cube. In light of this we decided we would extract the data from the ASO reporting cube. The challenge with this approach however was that we could no longer use the business rule export since it is not supported for ASO plan type, furthermo...

Overview PBCS has made life so easy when it comes to moving data between plan types.  Setting up a Planning to Essbase ASO reporting cube, on-premise, is a very involved process with automations to either export/import data or to move data via partitions.  With PBCS it's pretty much as easy as clicking a button in the UI or calling a data map definition in EPMAutomate. A number of questions come up when determining how you want to architect your PBCS app.  You need to think about how data is going to be stored in the different plan types and how the data flow is going to work so that you get the results you need as quick as possible while ensuring the app is easy for users to navigate.  Features like Smart Push, which allow you to create data forms pointing to a BSO plan type and also write to an ASO plan type (or another BSO type if you wish) give you a lot of options to isolate your users from seeing what's going on behind the curtain.  I make it a sell...

Something I've worked on a number of times and even spoke about at the ODTUG Kaleidoscope conference is MDX and specifically how to use it to do time related calcs like period-to-date functions and Time Balancing. I've seen quite a few posts on the subject and figured it was worth putting up some examples here. More recent releases of Essbase will do time balancing natively, but period-to-date is something you still have to work out. My preferred method of doing this is to add an analytic dimension to the database and set the formula in one of the calculated members. For those of you who aren't familiar with the term, an analytic dimension is one that you add to your database that has a single default load member, all other members are calculated. In the case of time functionality I usually call this dimension [View] and have a default member called [Periodic]. I will then have some other members as needed, like [Time Balance], [QTD], [YTD], etc. For Example: The perio...

Ok, so for my first post I figured I would write about something that just happened the other day that I thought was pretty cool. By the way, this is pretty much going to be the format of this blog, when I do something that I think is cool, I'll write about it and if anyone can get any benefit out of it cool. So as I was saying, I came up against a little challenge the other day and the result came out pretty nicely. At the end of the day I had to create two different time roll-ups in my ASO cube. I thought about actually doing two different time dimensions (what the hell it's an ASO cube I can have as many dimensions as I want) I resisted this temptation and went back to my OLAP basics, would the two dimensions have any meaning if I cross tabbed them in a report? Answer: no; so I went back to alternate roll-up. Now an Alternate roll-up is certainly nothing new, and probably not worth writing about in and of itself, but this one did pose a couple of challenges. (For those...