Hyperion Planning What You Should Know
Hyperion Planning What You Should Know
Hyperion Planning What You Should Know
com
Prepared By
Amit Sharma
Learnhyperion.wordpress.com
Hyperion/OBIEE Trainer/Consultant
There are some important points one should remember while working on Hyperion Planning. This is in
fact more important when are experienced in Hyperion Essbase and moving your career to Hyperion
Planning.
. Do not modify
the outline
directly into
Essbase
.
Modification in Essbase outline is done through Planning. Every time any modification is done in
Hyperion planning first it saves in Hyperion Planning underlying RDBMS tables and then pushed to
Essbase. Making any changes in Essbase outline put Essbase outline and Planning underlying tables in
out of sync as a result Planning system is get corrupted. At this time it's time to visit your recovery
procedures. BTW: make sure your backups for Essbase and the relational Planning tables are taken at
the same time.
The below diagram shows that the Essbase has one Database corresponding to one plan selected in
Hyperion Planning while creating Hyperion Planning Application. The underlying Planning database
table HSP_Plan_Type contains only one entry for one plan type in Essbase Database. This shows the
direct relationship with how Planning underlying table stores the Essbase outline data.
Take backup of all the underlying Hyperion Planning database tables and artifacts after making
some changes in Essbase outline by Planning web interface.
Before
refresh no
database
available
After
refresh the
database is
available
In the second instance I added a two new members to the outline in Entity dimension, before
refreshing the outline, the newly added members are available in Planning relational databases as
given below. On refreshing the application the metadata is read and refresh the Essbase outline.
-During the refresh process, never, ever select "Create" from the refresh window (unless your
developers has instructed you to do this). I was at a client where their directions were to select
"Create" for their refresh process. They would then have to create their YTD members by hand in the
outline directly. This took place every refresh instance. If they had instead chosen "Refresh" instead
of create, these outline changes would not get lost. Also, in the older versions of Hyperion
Planning, the software did not allow you to create complex member formulas in the web then push
them to Essbase. This meant that you had to directly enter formulas in Essbase. By selecting
the "Create" button, all of your custom Essbase changes get lost. Planning takes all the metadata and
creates the database from scratch based on the metadata stored in the relational tables.
To demonstrate this I have manually added the member formula directly in Essbase(Just to
demonstrate concept however this is not recommended approach) outline and later I select Create
button in Manage Database rather then using Refresh, as a result I lost member formula.
Member formula
manually added
Member formula
lost after
selecting create
button.
-In the Hyperion Planning web interface, never ever add a dimension by mistake. This is easier said
than done. When you are in the Planning web trying to add a new member, it's very easy to
accidentally add a dimension by mistake.
-In Hyperion Planning do not enter all your member formulas manually in either the web interface or
directly into Essbase. I have seen too many instances where all the formulas were entered via the
web then a rebuild of the entire application was mandated. With Hyperion Planning, assumptions are
made at the creation of the app that will possibly not be true as the project progresses. We have to
keep in mind during the build phase, that everything possible should be scripted. Instead of manually
Pl mail to aloo_a2 for all Hyperion/OBIEE training/support/project execution help
Learn Hyperion/OBIEE by Amit Sharma learnhyperion.wordpress.com
entering the formulas, place them into a file for bulk loading into Planning via either a tool like ODI,
DIM, or even directly to Essbase via load rules.
I have many instances where Planner finds very difficult to adapt the new environment, they still
love to use the Excel based budgeting and macros based solution I've seen systems where a business
analyst is supposed to run 5 different rules by hand after submitting 6 different web forms. A system
such as this represents a poor design. In this case, each of the 5 rules were consolidated into 1
business rule. This 1 rule was then attached to each of the 5 web forms to run on save. This not only
streamlines the workflow for the analyst, it also reduces the number of business rules from 5 to 1.
Maintenance will also benefit.
. I always use multiple instances for Planning in VMWare, this allows me to play around without
worrying about the application/software get corrupted. Do not run Hyperion Planning without a
development environment A development environment will cost you less than 5k these days. That's
less than the cost of an onsite consultant for a week. This will allow you to test different strategies
without trashing your production environment.