Beyond Static FIXes
One of the first features of EPM Groovy was focused calculations using dynamic fixes. we’ve relied on dynamic fixes based on edited or selected members/rows. Now, we’ll explore a new approach: understanding the currently edited form and dynamically adjusting calculation regions based on the form name.
Typically, EPM business rules fall into two categories: those designed for form-level calculations and those used for overnight jobs or administrator tasks. Examples of these rule names might be:
- Calculate Expenses (Likely for form context calculations)
- Calculate Expenses_All_Entities (Likely for scheduled/overnight tasks or administrators)
This existing approach works well for ease of debugging and maintenance. However, Groovy offers the option to combine these two rules into one.
The purpose is to explore Groovy to make EPM calculations adapt to the form being processed/edited. While Groovy offers a flexible option, remember there are often multiple ways to achieve the same using traditional approaches.
Different Forms – Different Rules
Let’s consider a scenario with two forms in your application:
- Global Assumption Form: When this form is updated, the attached rule needs to calculate for all intersections, encompassing all cost centers, entities, etc.
- Entity-Specific Form: This form derives the “Entity” dimension from a user variable. Any calculations triggered on this form should be restricted to the level zero members currently selected in the “Entity” user variable.
This demonstrates how Groovy scripting can dynamically adjust calculation regions based on the form being edited.
Lets build the core script:
I primarily develop my core calculations as scripts due to their flexibility in designer mode business rules, edit mode business rules, and Groovy business rules etc.
I have a sample calc as below:
Wrap this script in a Groovy script
As we explore separating calculations based on forms, I’ve established two categories:
- Forms with Entity User Variables: These forms allow users to dynamically select entities through a dedicated user variable.
- Hardcoded Forms (No Entity): These forms have a pre-defined entity scope and don’t involve user-selectable entities.
List<String> globalAssumptionForms = ['WF01 - Global Assumptions','WF02 - Global Assumptions - Tax Input']
List<String> positionPlanningForms = ['WF06 - Plan Existing Positions','WF06 - Plan New Positions']
let’s tackle the FIX for the global assumption form first. This script will run calculations for all entities in my application.
The below code will get me the current operation form
println operation.grid.sourceInfo.name
//Global Assumption: check and trigger all entities calculation
if (operation.hasGrid() && operation.grid.sourceInfo.name in globalAssumptionForms) {
println "Global Assumption Form Execution : ${operation.grid.sourceInfo.name}"
calcScript << """FIX(@Relative("Entity", 0))
%Script (name := "Calc FTE", application := "MyApp", plantype := "plan")
ENDFIX"""
}
Moving on to the second category: forms with entity user variables. Here’s how we’ll incorporate the user variable into the FIX statement for dynamic entity selection. The variable value can be fetched in more than one method. Here is the simple one:
//All positions: check and trigger specific entities
if (operation.hasGrid() && operation.grid.sourceInfo.name in positionPlanningForms) {
println "Position Planning form Execution : ${operation.grid.sourceInfo.name}"
calcScript << """FIX([[PlanningFunctions.getUserVarValue("Entity")]])
%Script (name := "Calc FTE", application := "MyApp", plantype := "plan")
ENDFIX"""
}
As we handle more use cases, the scripts can become more lengthier. It’s also important to consider situations where the rule might not be triggered by a form. We can implement logic to check for this scenario as well.
Deploy and Test the Rules within Forms
Global Assumption Form Output:
User Variable Form Output:
That’s a wrap
With that, calculations can automatically adjust based on which form a user is editing/working. This makes things easier and more accurate by personalizing calculations for different situations. This is just a glimpse of the many ways Groovy can simplify and improve your EPM experience. I hope this information is helpful.