kscope14 understanding the zombies that lurk within your system
Post on 13-Sep-2014
120 views
DESCRIPTION
Understanding the Zombies that lurk within your system: The Rules. This presentation assumes an HFM administrator level understanding of the system in general. But no familiarity with rules or how they run.TRANSCRIPT
Understanding the Zombies that lurk within your system:
The Rules
Jim Heflin
Edgewater Ranzal
Focus
Services
People
Methodology
Customers
Partnership
15 Years
700+ clients
1000+ projects
About Edgewater Ranzal
We offer a full spectrum of EPM/BI Services Dashboards & Scorecards, Financial
Analytics & Reporting, Operational Analytics,
What-if Analysis, Query & Reporting, Visual
Exploration
Financial performance, Legal,
Segment & Mgmt Reporting, Financial
Close
HFM Optimization, Performance Lab
SOX Compliance Support
Strategic Finance, Planning,
Budgeting, Forecasting, Workforce
Planning, Capital Planning, Project
Financial Planning
Data Integration, Financial Data
Management, Data Warehousing,
Master Data Management &DRM,
ETL Services, Automation
Project/Program Mgmt, EPM
Road Maps, Application
Reviews, Business
Requirements, Process
Change, Documentation
Installation, Upgrades,
Migration, System
Monitoring, Backup and
Recovery, Disaster
Recovery, Load Testing,
Hardware Sizing, Exalytics
Benchmarking
Consolidation
Business
Intelligence
Enterprise
Planning
Infrastructure
Training &
Support Services
Project
Management
Data
Services
Costing &
Profitability
Mgmt
Support Services – Infrastructure &
Application Support Contracts
Key Teach Course Delivery: Planning, Essbase,
Financial Reporting, Smart View, HPCM, HFM,
FDM, DRM, OBIEE
Custom Training Delivery: Process & Reporting
HPCM Standard & Detailed
Models, Waterfall Allocations,
Activity Based Costing,
Customer, Product & LOB
Profitability
What the rules do?
Rule organization and styles
How rules run from 30,000 feet
Finding an issue
Making changes to the rules
Objectives
This presentation assumes an HFM administrator
level understanding of the system in general. But
no familiarity with rules or how they run.
Assumptions
Nah… I think we
can safely assume
he is not a biter!
The rules just move data from A to B in HFM.
There may be 1000 lines of code or 100 objects
involved but at the end of the day we are pulling
in some data, doing some math and writing it
back.
The rules are needed any time the math
involved is more than aggregation.
What are rules and what do they do?
The rules can pull data from anywhere in the
system but can only write data were they are
currently running.
From a rule perspective, currently running
means one Scenario, Year, Period, Value, and
Entity at a time.
You do not know the entity order in which the
rules will run. * Yes there are exceptions to what I am saying. If you can explain the detail behind the
exceptions perhaps there is a Kscope presentation in your future.
Guiding principles *
Classic Rules
The .rle file
● Sub procedures
● Sub procedure called from the
main procedure / Rule Set level
● Lines of code in VB Script
Pick Your Poison
Calculation Manager
Organization
The Rules ● Rule Sets
● Rules
● Objects
Calculation Manager
● Collection of Rule Sets
● From a practical perspective this is what gets deployed
● Behind the scenes this is converted to VB script and
loaded to HFM upon deployment
Classic Rules
● The .rle file which is essentially text
● The rule file that gets loaded to the system
● This file can not be further broken down from a load
perspective. There is no partial load of this file.
Rule Organization – The Rules
Rule Sets are what HFM runs when you click on a
Calculate, Consolidate etc
Calculation Manager
● The type is set when you create the rule set
● From a practical perspective this is what gets deployed
Classic Rules
● Sub Procedures called Calculate, Translate,
Consolidate etc.
● These are all in the same text file but there is no
connection between each of them within the file
Rule Organization – Rule Sets
In Calculation Manager Individual Rules are called
in the order it appears in they appear in the rule set.
In Classic Rules a sub procedure is written to
address each specific topic… sometimes.
● This is not enforced so you will see lot of variation that
we will touch on next
Individual Rules
In theory each rule should address a specific goal
like Cash Flow or Statistics, but as this becomes
stylistic there is a lot of variation.
There are three primary styles
● Rule Split by Value dimension
● Rule Split by Subject
● Monster Mash
The Different Styles of Rules
Calculate Rule Set
Entity Currency Rules
Net Income to CY RE rule
Cash Flow
Statistics
Entity Currency Adjust
Net Income to CY RE rule
Cash Flow
Statistics
Value Dimension Split
Calculate Rule Set
Net Income to CY RE rule
Cash Flow
Statistics
Using this method the value
dimension conditions (and other
conditions) are within each
individual rule
Rule Split by Topic
All the
rules
are
just
tossed
about
willy
nilly
The Monster Mash
This is
more
common
in script
files
Trying to follow the execution of these rules is like trying
to follow an individual noodle in bowl of spaghetti!
Sometimes there is no style.
A Calculation Manager Rule is made up of Objects
● When looking at rules in the graphical designer, the
Objects are the boxes and triangles, etc. They look a lot
like a flow chart.
● When the rules run they follow the graphical flow.
● Most objects are used to call a HFM specific function.
In Classic each Sub Procedure is made up of lines
of code.
● A line of code (or a group of them) act like an object
● Execution is generally top to bottom of the file
Objects and Code
I clicked Consolidate.
Now what happens?
The rules really aren’t
a mysterious black
box. But it does help
to understand when
they run.
Rules that go bump in the night…
We will approach this from the perspective of
running a consolidation as this is the most
common action.
A consolidation is typically run for one Scenario,
Year and Period.
Within the above selection the rules run on each
Entity.
Within each entity the rules may run multiple
times at different places in the Value dimension.
Running the Rules
The Value Dimension within HFM
[Contribution Adjs]
<Entity Curr Adjs>
[Parent Adjs]
<Parent Curr Adjs>
[Elimination]
<Entity Currency>
<Parent Currency>
[Parent]
[Proportion]
[Contribution Total]
[Contribution]
[Parent Total]
<Parent Currency Total>
<Entity Currency Total> Translate Rule Set
Consolidate Rule Set
The Calculate Rule Set can run at each black circle.
The Translate Rule Set as the data moves from
Entity Currency Total to Parent Currency.
The Consolidate Rule Set as the data moves from
Parent Total to Proportion and Elimination
Rules Sets Running
OK it ran but it crashed
Do you have any documentation? If so read it.
Really.
If there is no documentation you should create
a high level document about the rules.
● This is by the rule, not by the object or line.
● What are the rules? Cash Flow, Stats, Etc
● When do they run?
● This is exactly what I do when performing an
assessment or looking at system performance.
About that documentation…
You need to have some
perspective as to which
rules are running when
and where
Perspective
Without that you don’t
know the scale of the
issue or where you
should be looking
Yes I understand you are telling me that
absolutely nothing changed in the system and
those dang rules just went crazy and died.
What changed?
My own experience
is a bit different.
● Changes can be internal to the application
● Did you change the rules?
● Metadata changes are the number one culprit
● Are new data intersections being populated?
● The change may be external to the application
● Infrastructure changes can break applications
● Did your OS just apply patches like a spiffy new web browser?
● The possibilities are endless here – the easy way to check is to
see if all applications in the environment are broken at once.
Rules don’t just die – a small bite matters!
Do the rules fail everywhere?
Can you run a Calculate on a base level entity?
Can you run a Consolidate on a USD base / USD
parent combination?
Can you run a Consolidate on a Foreign base /
USD parent combination?
Can you run any of the above on other Scenarios?
Questions to ask
Normal ?
Jim – The
neighbors
just called
about your
garden
gnomes…
Can you change a variable to get the rule running
again?
● Can you load an older rule file or change them back?
● Can you change the metadata back to the prior version?
● Can you clear one months data?
● Is data in a new scenario?
● Are rules running for the first time? This could be a leap
year, new data, a existing scenario populated for the
first time.
Can you get back to when things were normal?
HFM has an Administrative task called system
messages. There is a wealth of information here
including rule errors.
You are looking for the red icon to find errors.
A lot of the messages reference line numbers in
HFM itself and that will not help you.
Look for errors that have dimensions mentioned.
You may get lucky and the error may tell you that
A#SendChecksToJim is not valid in your system.
Look at the system messages
Changing Rules
for the first time
doesn’t have to
be as big a deal
as you may be
imagining…
Changing a Rule
The most difficult part is often finding out what is
actually wrong
Often the issue is not in the rules but in the
Metadata or Data
If the problem is in the rules is this something that
you will feel comfortable fixing?
Fixing rogue rules
Work in a Development environment
Copy the rule file or Calc Man rule / object you
intend to change… just in case.
Make one adjustment at a time
DIY Rule Fixing
Write your own rules – The new Harley’s are out and the flame thrower option is to die for!
Again work in a Development
Environment
Start small and simple
If working in Calc Man, after you
write each object look at the rule in
script
Writing a new rule
Validate! It may not catch your errors… but then
again it may
Fully deploy and test each rule individually
Making untested changes in production first is like
tightrope walking without a net. It will end badly.
● Start any changes in your development environment.
● At worst, you can application copy over top of your dev
mutant rule debacle.
● Yes. Making changes to the Test application in your
production environment can end up crashing your HFM
application server and result in bringing down
production. So stop doing this.
Dev and QA environments have a purpose
Knowledge Crushes the Zombie Menace