Supervision Server Event Handlers
Supervision Server uses event handlers to react to users interacting with the In-Memory DB. Examples of these event handlers can be found in the
sample_scripts folder located at
<Install_path>\svs\. This folder contains many sample scripts that can be used for a variety of tasks. The parameters of each event handler can also be found in these files, as well as additional information to define more specific reactions. For example, the name of the saved database can be passed to
OnDatabaseSaved such that the script is able to branch accordingly.
For each OLAP server, there is one global pool of workers for all cubes, dimensions, login, etc. Each initialized worker starts a new SVS process. The default initial worker size is 1 and default maximum size is 32; these values can be changed in the palo.ini with the keys worker-pool-init-size and worker-pool-max-size. If the maximum number of workers has been reached, the next request will fail with an error message “Too many SVS workers running, operation cancelled”. This cycle will continue until a worker is freed up.
Note: by default, the SVS event handler is disabled when running a cube load in Integrator.
The event handlers are described below.
Executed by the System Supervisor when a user tries to login. Only used when option “workerlogin information” is passed to the Jedox OLAP Server.
Executed by the System Supervisor when a user tries to logout.Only used if some option of type “workerlogin” is passed to Jedox OLAP Server.
Executed by the System Supervisor when a user tries to login. Only used with “workerlogin authentication “option. Returns true or false depending on the success of the authentication.
Executed by the System Supervisor when a user tries to login. Only used with “workerlogin authorization “option. Return true or false as well as the set of groups the user belongs to (inside the array passed to the handler).
Executed by all workers when Jedox OLAP server stops execution.
Called by all workers when Jedox OLAP server sends a termination signal. This happens, for example, when a cube has no set of hot cells and the Jedox OLAP server terminates cube supervision.
Executed by the System Supervisor when a database is saved.
Within the function InitCubeWorker, one set (cube slice) of cells can be defined for every cube, and each of these “hot areas” can be linked to its own callback PHP function that will be executed if a user changes the value of a cell inside the set. This callback function, which is called in the InitCubeWorker event definition as part of the WatchCubeArea method and is defined in the script, has predefined parameters that will be automatically filled by the Supervision Server when the event is triggered at runtime (for an example, see the SalesCube function in the sep.inc.on_cell_change.php sample script). These parameters are described below:
|$database||Name of the database where the writeback occurs|
|$cube||Name of the cube where the writeback occurs|
|$areaid||Internal ID of the area for which the cube worker was defined|
|$sid||Session ID of the user doing the writeback (can be used to retrieve the user name)|
|$coordinates||Array of element names, defining the cell where the writeback occurs|
|$value||Value being written|
|$splashMode||Splash mode used during the writeback: values can be 0 (no splashing), 1 (default splashing with “#”), 2 (add splashing with “!!”), or 3 (set splashing with “!”)|
|$additive||Parameter specifying whether the “add” parameter was used (1) or not used (0) in the writeback. Note that this parameter is always 0 for manual writebacks from Jedox Excel Add-in or Jedox Web.|
InitCubeWorker can also be used to define a specific callback for copy events, using the WatchCubeAreaCopy method. For an example, see
sep.inc.on_cell_copy.php. The parameters for this event definition are similar to those above, with the following differences:
|$coordinatesFrom||Array with the source coordinates of the copy operation|
|$coordinatesTo||Array with the source coordinates of the copy operation|
|$function||Parameter specifying which function was used for the “predict” command. Currently, the only supported function is linear regression (1).|
|$areaPredict||Source area for the “predict” command (if any)|
|$useRules||Parameter specifying whether the “withrules” keyword was used (1) or not used (0) in the writeback|
OnDrillthroughExt is a proprietary event used for interaction with Jedox Integrator. Jedox Integrator must be installed with Drillthrough functionality for SVS, and the statement
enable-drillthrough must be written into the palo.ini.
This event uses the following parameters:
|$database||Name of the database where the writeback occurs.|
|$cube||Name of the cube where the writeback occurs.|
|$mode||Contains information on which front end was used to execute the drillthrough. Value is 1 if Drillthrough was executed in Jedox Web and 2 if it was executed in Jedox Excel Add-in.|
|$arg||Contains the cell coordinates on which the user attempts to retrieve Drillthrough information. It can be parsed in the Drillthrough script and used to retrieve the Drillthrough data from the data source. For details, see the sample scripts.|
|$sid||Session ID of the user doing the writeback (can be used to retrieve the user name).|
Within the function InitDimensionWorker, you can define one or several dimensions to be watched for changes. Each of these watched dimensions can then be linked back to its own callback PHP function that will be executed if the defined event (creation, renaming, or deletion of an element) occurs.
Note: the trigger to Supervision Server is merely to notify it that the event has occurred. The action itself will be executed in the OLAP server.