Business Intelligence using Hyperion

Hyperion Planning Losing Substitution Variables

User Rating:  / 0

Details

Created on Monday, 13 September 2010 17:54

Last Updated on Wednesday, 17 April 2013 17:09

Written by Howard Johnson

Hits: 15777

In Planning 11.1.1.3 using EPMA, there seems to be an issue where the substitution variables are disappearing from business rules.  I have not seen this issue with Hyperion Planning Classic applications.  What makes this peculiar is that the business rules appear to run without issue.

One fix is to:

you need to go into each business rule one at a time and export them. Save them to your pc. It will be in .xml format. Once you have saved them all, try importing just one of them and see if the variable reappears. Then reimport each one of them one at a time.  This seems to reregister the variable and suddenly it will appear.

This issue should not occur if you have the latest patches applied.  At this time, calc manager is at patch 3 and planning has a patch 4 out.

I've also seen where:
-sometimes changing the default value does not take effect in the rule until you manually deploy the rule after updating the variable value
-once a variable is used, changing the default value, limits, or even the string that appears results in corrupting that variable. Every rule that used that variable is now broken until that variable is replaced with a new one. I had a bunch of rules.

tip: Make sure you allow at least 3 weeks to migrate your development to production.

hj

Hyperion Planning Best Practices

User Rating:  / 0

Details

Created on Tuesday, 23 February 2010 04:46

Last Updated on Wednesday, 17 April 2013 17:09

Written by Howard Johnson

Hits: 17789

Many times the focus of a Hyperion Planning project relate to system testing of the business logic.  All too often not enough time is spent walking through the workflow of the typical user.  After working on over 4 dozen Hyperion Planning projects I've seen some pretty whacked out projects.  Things like users having to have a cheat sheet of which rules to run when, a hand written set of notes for which forms to submit in what order, etc.

Through use of some of the built in features and some design strategies, your Planning system can be much more user friendly, can produce predictable results, and will result in many fewer phone calls for support.  Your users will complain less and be much more productive.

• Web forms can have business rules attached to them that run on save.  Use them.
• Just because you have 8 web forms for data entry for a type of business model does not mean that you need to have 8 different business rules.  Take a look at the 8 different rules and see if you can combine them into 1 rule without a noticable difference in performance.  Then attach the same 1 business rule to all 8 web forms.  You have just streamlined your administration.
• Don't allow users to consolidate on top of each other.  While you probably want to allow a user to consolidate their slice of the world (if it doesn't take too long), be careful of allowing a total database consolidation to be kicked off by more than one user at a time.  If you allow all your users to launch an agg all on the entire database, then you run the risk of "changing" numbers when users are creating reports.  Depending on the calculations being performed (allocations come to mind), you can also create a system that will crash upon a heavy load.
• Task lists: There are objects called task lists that force the user to follow a prescribed set of steps.  It will not let a user jump ahead in the budget process until the specific steps are completed.  I have mixed thoughts on this feature as as of system 11.1.1.3, the user could turn off enforcement of the task lists.  Aside from that, I think it dummies down the system a little too much.  Sometimes it's good for a user to enter their data then see that parts of their budget are not filled in due to their not loading some driver assumptions.  Some customers make great use of task lists but I don't feel they are essential to design a usable system.
• During the day versus over night scripts: The hardest thing as a developer is to keep track of all the business rules and code changes.  There are many cases where during the day the numbers look good but when an overnight process runs the numbers appear to change.  This is due to running an overnight process that will fix or catch calcs that didn't complete during the day.  This type of script is essential but they are very complicated to maintain due to the order of operations that makes a big difference.
• To use member formulas or not:  In designing your Planning system you have a choice as to where to implement your business logic.  You can make extensive use of member formulas or you can perform all your logic inside of Business Rules.  There are advantages to each.  With the member formulas, your consolidation calc scripts / business rules will be much simpler.  The drawback is that to make changes to these formulas, you will have to perform Planning database refreshes.  This will cause outtages however brief in the system.  If you embed all your business logic in Business Rules, then you can more easily make changes to the business logic during the day without bringing down the system to your end users.  You can also more easily control security over who can run what business logic by enforcing security at the Business Rule level.
• If you use member formulas "do not" enter all of them via the web interface.  I've come across too many Planning systems that utilize member formulas extensively.  In most of these cases, the models have to be rebuilt for optimization purposes.  This means that during a rebuild if you don't have the building of the formulas scripted they will have to be reentered manually.  If you are going to use member formulas, make sure you can bulk load them into the Hyperion Planning relational repository.

Hyperion Planning Infrastructure Install

User Rating:  / 0

Details

Created on Tuesday, 24 August 2010 16:58

Last Updated on Wednesday, 17 April 2013 17:09

Written by Howard Johnson

Hits: 11013

The proper installation of the Oracle EPMA or Hyperion Planning software is key to a successful project.

I am amazed at the folks that are looking for an infrastructure install who are pinching pennies.  I hear rates that are below many consuting rates that are for the actual install of the environment.  There is a reason that some of the large Hyperion Partners are outsourcing this install work.  It can get pretty nasty.

The baseline for the installation of an environment for Hyperion is roughly 1 week per environment.  2 environments means 2 weeks.  This is the best case scenario.  I've yet to see a unix install go smoothly enough to be done in 2 weeks for 2 environments.

If you look at the install as the foundation of a house, something upon which all other items will be built, you'd think you want the most solid foundation possible.

Key items to ask of your install personnel:

-are you going to install all the patches (the answer is yes).  Can I get a listing of all the applicable patches and what they fix

-you will provide me with startup / shutdown scripts for the environment and this will be tested before you leave.

-can you help us increase our default java cache settings for the environment as I understand that they are set ridiculously low upon a default install?

If you get these questions answered, you can be a little more assured that your environment isn't broken coming out of the gate.

Oh yeah, don't forget a sanity check on the server specs.

A typical Hyperion Planning or Oracle EPM environment for production is at least 3 servers, each with at least 2 processors and 8 gig of ram.

server1: essbase: 8 way minimum (16 gig ram)

server2: planning, epma, 2 way minimum (8 gig ram)

server3: bi+, reports 2 way minimum (8 gig ram)

If you're going virtual make sure the above is met as well.

hj