The document presents key techniques and best practices for improving Essbase calculations and coding style, emphasizing the importance of readability, maintainability, and design. It discusses strategies for reducing maintenance costs, optimizing code structure, and promoting clear communication through standard naming conventions. The session aims to help participants develop efficient and reliable calculations that enhance the return on investment.

1. Essbase Calculations:
Elements of Style
Ron Moore
Principal Architect, Alithya

2. ABOUT THE SPEAKER
Ron Moore
> Principal Architect at Alithya
> Over 20 years Essbase consulting and training
experience
> Certified in Essbase, Planning and R programming
> Many webcasts and KScope sessions
> 19 Oracle University Quality Awards
Ron.Moore@Alithya.com
2

3. Oracle ERP, EPM, & Analytics ARE in our DNA
ALITHYA delivers end-to-end ERP, EPM, & Analytics solutions and
is a leading Oracle Cloud and On-Premise Partner
4,000+ Oracle Implementations1,000+
Oracle
Customers23+
Years Driving Finance
Process Improvements for
Our Clients
7 Oracle ACEs
Seasoned
delivery team
with avg 8
years serving
clients
Adaptable Deployment Models
Experienced
management
team with avg 15
years in the
company
Certified Cloud
Resources
Diverse Client Portfolio & Industry ExpertiseTeam Highlights
Retail
Technology CPG and
Manufacturing
Healthcare
AnalyticsEPM
Energy/
Utilities
Financial
Services Hybrid CloudOn-premise
ERP

4. SESSION OBJECTIVES
> MEANINGFUL soft/stylistic techniques that contribute to BETTER calc
scripts/business rules
> Targeted to Essbase CALC, but parts are relevant outside that domain
> NOT about optimization
> NOT about “content” best practices
> NOT a rigid mandate

5. BETTER CALC SCRIPTS: DOES STYLE MATTER AND WHY
> Objectives
> First, make it correct
> Then, make it fast
> Then, make it clear
> Costs
> Development cost
> Maintenance cost
> Clear, easily understandable code reduces maintenance costs and promotes reusability. That’s
an enormous improvement in ROI.

6. CALC CODE STYLE IN THREE PARTS
Design
Great calculation results
depend on outline
structure, order of
processing and a clear
understanding of
requirements. Great calc
code starts with great
design.
Readability
Easier to understand
means easier and
cheaper to create,
modify and maintain.
More readable code
delivers higher ROI.
Mechanics
There are a few basic
best practices to make
your code more reliable,
faster and easier to
understand.
6

7. 7
Design

8. GREAT CODE STARTS WITH GREAT DESIGN
If you think good architecture is expensive, try bad architecture.“
- Brian Foote
> Lay it out in Excel
> Control data
> Who can run it, how and why?
> Specify the treatment of every dimension
> Think about processing from a dimensional and block structure point
of view

9. GROK THE BLOCK
> The single best optimization practice is to reduce the number of blocks
processed.
> Application:
> Assuming Accounts is dense do BS and IS in the same script and same FIX
rather than separate scripts or separate FIX statements
> Think through everything that needs to be done to a set of blocks and if
possible do it all in the same pass
> (Almost) Always fix on Level 0 blocks for the main calcs, and decide
if/what to aggregate later.

10. STAY DRY
> Don’t Repeat Yourself v Write Every Time
> Wet requires multiple points of maintenance which takes more time
and increases errors
Hunt and Thomas, The Pragmatic Programmer,
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

11. THINK DIMENSIONALLY
11
> He's intelligent but lacks
experience. His is pattern
indicates, two
dimensional thinking.

12. TAKE ADVANTAGE OF DIMENSIONALITY
> The members in the fix statement and the member on the Left taken
together set the scope of the calculation. You can usually swap them
for convenience.

13. TAKE ADVANTAGE OF DIMENSIONALITY:
“VIEW” DIMENSION CONCEPT
13
Consider this Accts
Dim
Add YTD But adding members
requires maintenance
A “View” dimension
requires almost no
maintenance

14. TAKE ADVANTAGE OF DIMENSIONALITY:
WHERE SHOULD I PUT THIS CALCULATION?
> Principle: Every member intersects with all members of every other
dimension
> Application: If you want a member to intersect with specific members
you have to locate it on a different dimension than the members it
should intersect
> Q:Should “CurrMonth v PriorMonth” go on the Scenario or the Period
dimension?
> A: If you want to see it for Actual, Plan and Forecast it can’t go on the
Scenario dimension, so it would have to be Period
> Twist: What if you wanted to see “CurrMonth v PriorMonth” for every
month?
> A: Use a View dimension
14

15. 15
Readability

16. STANDARDIZE AND USE NAMING CONVENTIONS
> What might be ambiguous or cause
errors? How can I communicate
purpose and requirements?
> verb/Noun
> Data Type
> Case
> Abbreviations

17. CREATE A STYLE GUIDE FOR YOUR ORGANIZATION
> Member names
> Variable names
> Script names (CALC, MaxL, MDX, Bat, Other)
> Other Essbase artifacts
Promote Prevent
Consistency Collisions when a shared artifact
is and used incorrectly
Communication Errors when code is reused
Reusability

18. DATA LOAD RULE NAMING CONVENTION EXAMPLE
18
File File Name
Data Load Source file FY20Acutals.txt
Data Load Rule lFY20Act.rul
MaxL procedure lFY20Act.mxl
Batch file to launch Maxl lFY20Act.bat
Err file lFY20Act.err
• Dimension Build rules start with b and then include 7 characters of the filename
• Data Load rules start with l and then include 7 characters of the filename

19. VARIABLE NAMING
19
Variable Type Identification/Ambiguity Suggestions
Substitution Variables
Run Time Substitution
variables
• Identified by &
• Usually a member name but can
be virtually any text
• Same name can be used for
server, app or db scope
Identify scope e.g. finplanCurrYear
Identify dimension e.g. scenarioFcst
VAR • Single position local variable
• No easy identification
Identify it as variable e.g. vDaysInMonth
ARRAY • Multiple position variable
• No easy identification
• Inherits size form associated
dimension
Identify is as an array variable and its
dimension e.g. atimeDaysInMonth
Run-Time prompts • Identified by {}
• 12 different types that require
different types of values
• Different scope levels
Identify the type and for some types the
dimension e.g msGeos
Identify the scope
What might be ambiguous or cause errors? How can I communicate
purpose and requirements?

20. CALC SCRIPT/BUSINESS RULE NAMING CONVENTION
EXAMPLE
20
File Script Name/Rule Name
Aggregate 5 business dimensions ag5Dim.csc
ag5BusinessDims
Clear forecast
Note: specific forecast should be parameterized with a SubVar
clFcst.csc
clForecast
Data Copy actuals to forecast dcAct2FC.csc
dcActToFcst
• Use verbNoun method for common actions
• 2 characters for verb followed by meaningful noun

21. MAKE PITHY COMMENTS
Why – Not What
Explain the reasons behind the
code that may not be obvious to
the reader. Why did you write it
that way?
Identify Sections
Call out the major processes
contained within the script.
Make it easy to find what
happens where.
Pseudocode
Write pseudocode based on your
requirements. Then leave it (or a
stripped-down version) there to
comment your code.
21
Change Tracking
Comment out old code,
identifying the beginning and
end of the new and old blocks.
Identify it with a reason and a
date.
Start with a Header
Include a purpose, when to use
it, dependencies (e.g. subvars )
and a change log.
Comment ENDFIX
Comment the end of a FIX block
tying it back to the opening.
E.g. /* End FIX on Actual
Scenario */

22. MAKE SETTINGS EXPLICIT
> Make settings explicit. Show them even if they are defaults.
/* Housekeeping */
SET UPDATECALC OFF;
SET AGGMISSG ON;
SET MSG SUMMARY;
SET CALCPARALLEL 2;
SET EMPTYMEMBERSETS ON;
22

23. 23
Mechanics

24. MECHANICS BASICS
> Always double quote member names
> Address all dimensions in FIX statements
> Member names not aliases
> Capitalize Function/Calc Command names
> Indent
> Limit lines to 80 characters
> Simpler is better
24

25. BE DELIBERATE WITH FIX STATEMENT SCOPE
> Global Calculation – Essbase calcs everything that is not explicitly
excluded
> That could result in accidentally touching out of scope data
> Address every dimension in scoping calculations (FIX, IF) so you don’t
accidentally touch numbers you shouldn’t

26. ORGANIZE FIX STATEMENTS BY DIMENSION CATEGORY
Dimension Type Examples Examples of different actions
Measures Measure
Account
Time Year
Period
Historical periods v Forecast/Plan
periods
Business /
Segmentation
Entity
Product
Customer
LOB
Channel
This is the way users break down
the business.
Version Version
Scenario
Actuals v. Forecast/Plan
Change tracking
Scenario analysis
System Data type
View
Currency

27. USE CALC MANAGER FEATURES
> Design View allows you to visualize calc structure
> Script components provide reusable code blocks
> 80 character BR names
> BR descriptions provide useful information for users

28. REDUCE CLUTTER AND ERRORS WITH VARIABLES AND
PARAMETERIZATION
> Substitution variables
> RTSV
> RTPs
> Var and Array
> Global Variables

29. ADDITIONAL READING
29
Description Link
Story, Oracle CEAL blog, EPM 11.1.2.x
Planning/PBCSBest Practices for BSO Business
Rule Optimization
https://blogs.oracle.com/cealteam/epm-1112x-
planningpbcs-best-practices-for-bso-business-
rule-optimisation
Pattis, CMU Coding Style notes https://www.cs.cmu.edu/~pattis/15-1XX/15-
200/lectures/style/index.html
Wikipedia, Elements Of Programming Style https://en.wikipedia.org/wiki/The_Elements_of_P
rogramming_Style