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

Jim Heflin JHeflin@ranzal.com

Greenville, SC

USA

www.ranzal.com