Jorge Mendoza

Jedox doesn’t allow you restrict the amount of times a user logs in to the server, and if the amount of concurrent users you have is small; then you will have the need to limit the amount of connections per user.

Luckily it’s quick and easy to do so, by following these simple steps:

Create a new element in the User Dimension: it will define the amount of sessions that the user has.
Change palo.ini: add a new authentication method.
Add a SVS script: php script that will handle the authentication.

Creating the new element in the User Dimension

We need to add an attribute to the _USER_PROPERTIES dimension (which is hidden for the normal user) in the System database, which in this case is going to be called “sessions”.
Since there’s no direct access to that dimension, we need to modify it through an ETL job.

Change the session values

Create a Paste View to modify the values for the users. The rule is that that cell for the user is blank, then the user has unlimited logins, otherwise you need to specify a number (starting from 1).
The Paste View should look like this:

Add the SVS script to handle the sessions

Look for the current SVS script that is running, if you don’t have anything running then go to <Jedox Installation>\svs\ and save the following file.

Then the sep.inc.php file in <Jedox Installation>\svs\, needs to be changed to include the previously download file:

<?php
include './sep.inc.session_limit.php';
?>

If you already have a SVS script running, then you need to change/complement the OnAuthenticate function, with the one provided.

Change palo.ini

Once the SVS script in place, now it’s time to enable SVS (if not already done) and the authorization login in palo.ini.
For that, we add the following lines (if they didn’t previously exist before) to palo.ini:

workerlogin authentication
worker "<Jedox Installation>\svs\SupervisionServer.exe"

Disadvantages

There’s no information in the login screen that will reflect that the user has reached the number of concurrent sessions. It will say “Incorrect Username/Password”.
However, going to the SVS log file, the information will be stored (in case it’s necessary to identify how many users are trying to create more sessions than allowed).

Let’s imagine that we want to do a server upgrade to our current Jedox installation; that is, going from Server A (which is our current Jedox environment) to Server B.

Let’s start with Server B

1. Install everything necessary for Jedox to run (i.e. Java,).

2. Install Jedox (guide).

The beauty of this, is that the installation is a completely new one; so you can even upgrade to the latest version.
Remember to enable the same features that your current Jedox environment has (i.e. Drill Through).
Also, at these point, there’s no need to worry about the Licence yet.

3. Check that Jedox is running, and all of the services are up.

4. Stop Jedox, so we can change some of the configuration files later.

Let’s go to Server A

1. Grab a copy of the following folders:

Data folder (including all of the folders inside, specially the System folder).
ETL folder
Web folder

If you don’t have a backup folder, you will need to stop the services in order to make a copy of these folders.

2. Copy the following lines from palo_config.xml and config.php

<Jedox Installation>\httpd\app\etc\config.php:

<?xml version="1.0" encoding="utf-8"?>
<palo_configuration xmlns="http://www.jedox.com/wss" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <server>
<host>127.0.0.1</host>
<port>7777</port>
  </server>
<secret>sometext</secret>
  <subset_cache size="500" treshold="50" timecheck="1000" disabled="no"/>
</palo_configuration>

<Jedox Installation>\core\palo_config.xml:

// shared secret - needs to be 16 chars long
define('CFG_SECRET', 'sometext');

// palo
define('CFG_PALO_HOST', '127.0.0.1');
define('CFG_PALO_PORT', '7777');
define('CFG_PALO_USER', '_internal_suite');
define('CFG_PALO_PASS', 'some_password');

3. Copy the Data, Web and ETL folders from Server A to Server B (replace what’s necessary) to Server B.

Let’s go back to Server B

1. Change the CFG_SECRET and CFG_PALO_PASS in both palo_config.xml and config.php files to match Server A details.

2. Remember to copy any other files with custom configurations, for examples: sep.inc.php, httpd.conf or any other manually modified (just remember the ones originally changed).

3. Start Jedox.

After that, the Server B will have the same Databases (including all of the cubes), ETL projects and Web Reports. Also, it will carry on the users, groups and roles already setup in Server A, implying that all of the security rules are already in place.

Note: It might be an issue with the Web Reports, which have an internal connection that are unique to every Jedox Installation. In that case, it might be better to export them from Server A and import them to Server B.