Manage User Sessions on your IBM Cognos TM1 Server

Being a TM1 administrator, at times we are required to manage user sessions on the system.  Some activities include finding active users or user activity on the system.  And in certain times, disconnect users as part of ongoing maintenance/system upkeep.

Track User activity

There is a mechanism available to track current active users on the TM1 instance.  However, if you want to see who all have logged on through the course of the day, or last few days, then you can enable the LOGIN Logger.  With 10.2.2 FP1 there are new loggers available.  One of them is TM1.Login, which will write the login and logout of all users into TM1Server.log file

If you already have a tm1s-log.properties file, then you’d need to do add this line.  If you don’t have this file, you can locate one in the directory of each sample TM1 database.  Location of the tm1s-log.properties should be in the same directory as that of the tm1s.cfg

log4j.logger.TM1.Login=DEBUG

Once done, you will see entries like below in the tm1server.log file, which will continually record the login/logout session of the users.  One fantastic thing is that, if you have BI report that uses TM1 as data source, then this logger will help you track the report executions as well.

 

Find Active Users

This is a fairly straightforward task, which will involve setting up a parameter in the tm1s.cfg file.  The parameter name is ClientPropertiesSyncInterval and it is dynamic.  This property tells us the frequency (in seconds), at which Clients’ properties in the Control Cube }ClientProperties is updated.  The example below will update every 5 minutes (300 seconds)

ClientPropertiesSyncInterval=300

Once you have done this setting, you can now open the control cube }ClientProperties and see the active users.  If this cube is not visible then, you would need to turn on the “Display Control Objects” from View menu.  Select STATUS as the element of interest, turn on zero suppression and it will now list active users on your instance.  It will not show the users who were active earlier and are now logged out.

Disconnect Users

There are situations that sometime leads you to disconnect users from the system:

• During system maintenance, routine downtime etc
• A developer has kicked off a TI and it can not be cancelled through TM1 Top or Operations console, then you can disconnect the user

To do this:

1. Right click on your server -> Choose ‘Server Manager‘
2. Choose option ‘Disconnect Clients‘, enter number of minutes
3. Click on ‘Select Clients‘.  it will open up }Clients dimension.  Turn on the alias }TM1_DefaultDisplayValue (CAMIDs listed will not tell who the user is).  Click OK
4. Click OK again … this will disconnect selected users from the TM1 instance.  You can verify this from your TM1 top session or Operations Console

Reference –

TM1 Taking a Peek Under the Covers, and Learning how to Troubleshoot (Session #1169 @ IBM Vision 2015)

 

Cognos TM1 Chores: Single Commit vs Multiple Commit

A chore in IBM Cognos TM1 server is a container for a group of one or more Turbo Integrator (TI) Processes.  It defines the sequence in which the processes are executed. These processes inside of a chore are executed sequentially – in other words, the 2nd process in a chore is executed after the 1st one finishes; 3rd process is executed after the completion of the 2nd one … and so on.

Chores can also be used to run the same process multiple times – in such scenarios, the parameters passed to the process will be different.

• Chores once activated (enabled) run periodically on the set schedule.  When the chore is run from a schedule, it runs on its own thread.
• Alternately, you could right click on the chore and run it on demand

Irrespective of how the chore is run, all the TI processes are embedded in one transaction.  This means that any locks acquired by the 1st process are held onto, until the last process is completed.  Therefore any data updates done by the group of TIs in the chore are committed, only when the last process is completed.  This is the default behavior of Cognos TM1 server.

Starting from 10.1, we now have a provision to commit each TI in a chore as and when it is processed.  In such scenarios, the locks are not held onto, until the last process is completed.  Therefore, the data modified by a TI in chore is committed and locks are released, when its execution within the chore is complete.

Let’s look at an example, which demonstrates the difference between the 2 options – Single Commit versus Multiple Commit.  To illustrate this, I will use a simple cube, 3 TI processes and 2 chores.

1st TI Process – All it does is increment the value by 10 in the 1st intersection of the cube

vi_Value = CellGetN (vs_CubeName, ‘A’, ‘E1’, ‘zDim_03’);
AsciiOutput (GetProcessErrorFileDirectory | ‘sk03.txt’, ‘Before: ‘ | NumberToString (vi_Value) );

CellIncrementN (10, vs_CubeName, ‘A’, ‘E1’, ‘zDim_03’);

vi_Value = CellGetN (vs_CubeName, ‘A’, ‘E1’, ‘zDim_03’);
AsciiOutput (GetProcessErrorFileDirectory | ‘sk03.txt’, ‘After: ‘ | NumberToString (vi_Value) );

2nd TI Process – This waits for sometime, before incrementing the value by 10 for the aforementioned intersection

vi_SimplyWaitCounter = 10000000 * 2;
WHILE (vi_SimplyWaitCounter > 0);
vi_SimplyWaitCounter = vi_SimplyWaitCounter – 1;
END;

val = CellGetN (vs_CubeName, ‘A’, ‘E1’, ‘zDim_03’);
AsciiOutput (GetProcessErrorFileDirectory | ‘sk01.txt’, ‘Before: ‘ | NumberToString (val) );

CellIncrementN (10, vs_CubeName, ‘A’, ‘E1’, ‘zDim_03’);

val = CellGetN (vs_CubeName, ‘A’, ‘E1’, ‘zDim_03’);
AsciiOutput (GetProcessErrorFileDirectory | ‘sk01.txt’, ‘After: ‘ | NumberToString (val) );

3rd TI Process:  Almost same as 1st process, except that it writes to sk03.txt, instead of sk01.txt and increments intersection value by 5 instead of 10

1st chore: Comprises of Process 1 and Process 2
2nd Chore: Comprises of Process 3 alone

Scenario 1 – Single Commit

Run Chore 1 on demand (from one session).  Run Chore 2 on demand (from another session).  If you open the cube, the value will be 20.  Here’s chart showing what transpired.

• 1st TI process in Chore 1 (named Process 1) executes and puts value of 10 in the cube. This happens in a fraction of second.  By this time the 2nd TI in the chore 1 (named Process 2) is already running and doing its wait. 
• Now the 1st TI from Chore 2 (named Process 3) is executed. 
• When it reads the value from the cube, it reads it as 0.  Although the process 1 from chore 1 is completed, we have used Single Committ, so the committed value is not visible outside of the chore (i.e. in process 3 of chore 2). 

Therefore the final value in the cube is 20 (10 + 10) as opposed to 25 (10 + 5 + 10)!  You can see the cube value and the log entries below:

Scenario 2 – Multiple Commit

Clear the value in the cube.  Then run Chore 1 on demand (from one session).  Run Chore 2 on demand (from another session).  If you open the cube, the value will be 25.  Here’s chart showing what transpired.

• 1st TI process in Chore 1 (named Process 1) executes and puts value of 10 in the cube. This happens in a fraction of second.  After this the data is committed and the locks are released.  By this time the 2nd TI in the chore 1 (named Process 2) is already running and doing its wait.
• Now the 1st TI from Chore 2 (named Process 3) is executed.
• When it reads the value from the cube, it reads it as 10 (instead of 0).  This is because of multi commit
• After few seconds, when the Process 2 in Chore 2 reads the value, it shows 15 (10 + 5).  It then adds 10 more to it, totaling the result to 25