Die Syntax von @CalcMgrExecuteEncryptMaxLFile lautet wie folgt:
FIX ("Sales","100-10","New York","Actual")
"Jan"(
@CalcMgrExecuteEncryptMaxLFile("2115028571,2505324337","C:/Temp/exportdata.mxls", @List("906388712099924604712352658511","0893542980829559883146306518502837293210"), "true");
ENDFIX
Das erste Argument ist der Private Key, das zweite Argument ist die MaxL-Skriptdatei, das dritte Argument sind die Argumente für das Skript, und das letzte Argument gibt an, ob die Ausführung asynchron erfolgen soll oder nicht ("True" steht für "asynchron", und "False" steht für "synchron").
Bei diesem Verfahren gibt es ein paar Probleme. Das erste Problem ist die Anzahl der benötigten Ausführungen für ein Skript: Es wird für alle Elementkombinationen der FIX-Anweisung ausgeführt. Das zweite Problem besteht darin, dass das Skript möglicherweise überhaupt nicht ausgeführt wird, wenn Oracle Essbase zufolge keine Blöcke für die Elementkombinationen der FIX-Anweisung vorhanden sind.
In der Regel sollte das MaxL-Skript nur einmal ausgeführt und der Befehl RUNJAVA verwendet werden:
RUNJAVA com.hyperion.calcmgr.common.cdf.MaxLFunctions
<LOG FILE> OPTIONAL ex., "logfile=c:/Temp/maxlrule.log" The path should be accessible from the ESSBASE process.
<ASYNCH FLAG> OPTIONAL ex., "true" This means calc engine does not wait for the completion of the MaxL script. The default is "false"
<ALL OTHER PARAMETERS YOU PASS TO ESSMSH>
Beispiel:
RUNJAVA com.hyperion.calcmgr.common.cdf.MaxLFunctions
"logfile=c:/Temp/maxlrule.log"
"-D"
"c:\\Temp\\maxl.msh"
"28567271,1186612387"
"893848844082678214004255849650"
"4647275840619320283077900267208176084380"
"{varAppName}";