I try to structure business rules to utilize run time prompts that grab the member variables from the form. When the rule is launched on save from the form, the prompts are hidden and the rule uses the variable member. It makes for a better user experience, they don’t have to reply to a prompt. This is easy to do when the needed dimension member is in the form POV or page. But what if the variable is in the rows or columns? Unfortunately, a variable in the rows or columns will cause the form to prompt for input to execute the rule.
Here’s the form design with User Variables for Scenario and Years in the Page.
And a User Variable for Currency in the row.
The business rule references the variables.
When the form is saved and the rule launched, you get this.
Year and Scenario populate with the values from the form, but Currency does not because it is in the rows.
I can’t change my form design to move Currency to the POV or page, but fortunately there is a solution in Groovy, and it’s pretty simple to implement.
Since I already have the script in a business rule, I can use that in a new Groovy rule.
Create a new rule.
Change from Designer mode to Edit Script.
Then change Script Type to Groovy Script.
The first line is to establish the RTPS variables. These variables will pull the User Variable values from the form that are in the POV/Page.
Next is to define the variables for use in the calc script.
- Define strScenario as the RTPS of Scenario
- Define strYear as the RTPS of Years
- Define strCurrency to retrieve the User Variable of Currency using the Groovy command getUserVariable
With these variables defined, we can then update the script to use them. Recall that the script was referencing variables like this.
We need to replace those references with the new variables that have been defined. We also made some other changes to the FIX statements to accommodate different processing based on the Scenario value.
- To reference the variables for Scenario and Year, the names are prefixed with $
- To reference the variable for Currency, the name is prefixed with $ and also placed in double quotes
The first variables are based on the RTPS values, but since the Currency variable is based on the value retrieved with the Groovy command getUserVariable, we need to place it in the double quotes. There may be other ways to retrieve the User Variable, this is the way I’ve done it.
Now with the new Groovy rule configured to obtain the variables, we can attach it to the form and test it out. I don’t have any screen shots from launching the form save in Smart View because there’s nothing to show. No prompts came up, the rule ran without intervention. To see that it did run, we open the Job Console and look at the completed job.
Our Groovy script had commands to print the values of the variables, so we can see that the rule ran on USD, OEP_Plan, and FY22.
You may have noticed there was another Groovy line that we didn’t discuss. The command getSubstitutionVariableValue is similar to getUserVariable. The syntax is slightly different.
Notice that for getUserVariable there is a suffix of .value.name. There is no suffix on the getSubstitutionVariableValue. As with everything Groovy, there may be other ways to do this, but this is what worked in my situation.
To reference this variable in the script, it is prefixed with $ and placed in double quotes, just like the User Variable.
One more thing to point out that is very important. To execute the calculation script within the Groovy rule, it must be placed within a couple Groovy commands so it is recognized.
The script section is defined at the beginning with String OTCcalc and three double quotes. Then it is closed at the end with three double quotes and return OTCcalc. The string name can be anything, I try to keep it similar to the rule name.
Groovy makes it rather simple to utilize User Variables and Substitution Variables from a form regardless of where on the form the variables are used. This was a very basic example, and I’ll again point out that there are likely other ways to use Groovy for this process, but this is how it worked for my situation. The important message I’m trying to convey is that Groovy is a super powerful tool in the EPM toolbox, and the sooner one can start learning it and using it, the better you’ll be able to work with EPM.
As always, happy EPM’ng!
Random EPM Notes 