While exploring different features under EPM 11.1.2.4 release, I happen to stumble upon an interesting setback in Calc Manager which I believe is a potential bug.
The issue occurs when we try to write business rules for Essbase applications and deploy them. It all started with me trying to explore how business rules with RTPs can be executed from Essbase. Interestingly, it the script editor which is buggy while the designer mode works perfectly. I used Sample.Basic, which comes with installation to test out my findings.
I went on deploying both the rules to Essbase to check how they get translated to Essbase scripts.
As per Calc Manager documentation - "When you deploy Essbase business rules with runtime prompts to Essbase, you can use Administration Services, MaxL, or any component that can launch a calc script to launch the business rules. When you deploy these business rules, they are converted to Essbase calc scripts, and the runtime prompt variables are converted to RUNTIMESUBVARS in the Essbase script"
The rules after deployment get converted to RUNTIMESUBVARS, but there is a catch between the two rules. The rule created in script editor did not deploy correctly in Essbase. We can find {PeriodApp} variable written as it is in the script. This would also fail when we try to execute this calc at Essbase level. While the one created using designer mode translates well to replace the RTP with RUNTIMESUBVAR.
At the same time I wanted to check how the rules look like when they are exported. I opened them in XML Notepad and compared side by side
I just named it into different sections to compare. To my surprise where is Section 3 in the rule which was written using script mode ?? That's the issue probably .
Let me brain storm more into this and see how it can be fixed. At the same time, check if RTPs work fine on Planning. I hope they do !!!
The issue occurs when we try to write business rules for Essbase applications and deploy them. It all started with me trying to explore how business rules with RTPs can be executed from Essbase. Interestingly, it the script editor which is buggy while the designer mode works perfectly. I used Sample.Basic, which comes with installation to test out my findings.
- Created a runtime variable PeriodApp of type member which belong to dimension Year from Sample.Basic
- Created a new business rule 'LNCHTST'. Select the 'Script' mode and type in a simple command to copy data from one period to another. And target is a runtime prompt.
- When I try to validate this rule, I get a popup asking for RTP value. Bang !!! Script validation throws an error. I could not determine as to what is the issue. I double checked my rule to make sure I did not make any stupid mistake.
I did try a lot of workarounds to see if I am doing anything wrong, but nothing seem to work out. Then I tried creating the same rule using the designer mode of Calc Manager. Rule name LNCH2 using the same variable and script. To my surprise, it validated without any errors. Definitely, there is something fishy with script editor.
As per Calc Manager documentation - "When you deploy Essbase business rules with runtime prompts to Essbase, you can use Administration Services, MaxL, or any component that can launch a calc script to launch the business rules. When you deploy these business rules, they are converted to Essbase calc scripts, and the runtime prompt variables are converted to RUNTIMESUBVARS in the Essbase script"
The rules after deployment get converted to RUNTIMESUBVARS, but there is a catch between the two rules. The rule created in script editor did not deploy correctly in Essbase. We can find {PeriodApp} variable written as it is in the script. This would also fail when we try to execute this calc at Essbase level. While the one created using designer mode translates well to replace the RTP with RUNTIMESUBVAR.
At the same time I wanted to check how the rules look like when they are exported. I opened them in XML Notepad and compared side by side
Let me brain storm more into this and see how it can be fixed. At the same time, check if RTPs work fine on Planning. I hope they do !!!
No comments:
Post a Comment