Pages

Sunday, March 29, 2015

Executing .Bat files from Calc Manager


Few days back, I had an opportunity to discuss on capability of Calc Manager to trigger .bat files. A fellow colleague of mine happen to have this requirement and had written a CDF to call a batch script. I was not convinced to write a CDF to perform such activity and believed to have some option using which we can avoid writing CDFs.
Most of us have used Maxl and must be aware of the command ‘Shell’. This command triggers underlying operating system commands from within Maxl shell session. This is our easy way to do what we want. With the introduction of Calc Manager CDFs @CalcMgrExecuteEncryptMaxLFile and @CalcMgrExecuteMaxLEnScript, we now have ability to trigger Maxls from within Calc Manager. All we need to make sure is all such requests are sent to Essbase Server and bin folder under Essbase path is our starting point.
Lets use Oracle sample application Vision and Calc Manager to test out.
  • Create a batch file Test.bat. This file accepts a run time parameter and simply writes it to a log file
image
  • Create a RTP to accept Version member from a webform
image
  • Create a business rule which uses RunJava version of the Calc Manager CDF to execute Maxls. We intend to pass the RTP member name as parameter to the batch file which should be written to log file. CDF function requires use of exit keyword if we intend to pass parameters. In this case, RTP member is passed as parameter. We need to enclose it within double quotes to make it act as parameter
image
  • Lets associate this rule as a menu item to a form from Vision app and select the version to trigger this
image
  • Since we unchecked the ‘Hide Prompts’ option, it displays the selected member during execution of rule
image

  • This triggers the Test.bat file and a log file gets generated with the version name written into it
image
***Important***
I noticed a peculiar way application was handling the RTPs, it tend to cache the RTP value that was used during first execution. On executing this rule with different version members, it returned the same member name. Though this would get fixed if we restart out Planning services once. Seems to be a potential bug where RTP values are not updated during subsequent executions.
Hope this helps !!!