Hello all,

I am back from the TM1 Customer day in Germany, last Monday and Tuesday. It was great to meet so many familiar faces from the TM1 community!

When discussing TM1, obviously new things can be learnt but also shared. It seems to me that the concept of global variables was not fully clear, and therefore not used, to at least some of the people I spoke to.

Tie this to the ability to have recursive calls in processes and we can support advanced structures.

Some TM1 developers prefer to pass around parameter values (year, month, company, version, ...) in this way, instead of having real parameters for the processes. That is a matter of preference I guess, for processes that are not called directly by the end user.

Global variables, most of the time string variables but numbers are possible too, are created using:

StringGlobalVariable('name_of_the_variable');

e.g.

StringGlobalVariable('vUsername_alias');

Add this line anywhere in the TI process but most probably not in the Metadata/Data tabs and almost always near the top of the Prolog tab.

After that, populate the variable with a value. Either a simple constant value, either the result of an entire processing.

Next the idea is to pass that information to a different process (or the same process in a subsequent run of it).

As in, a mother process has the line:

StringGlobalVariable('vUsername_alias');

Then the mother process calls a second process:

nRet = ExecuteProcess( 'Get_Username' );

with a certain logic. The called process 'Get_Username' also has in the Prolog tab:

StringGlobalVariable('vUsername_alias');

and somewhere in the process:

vUsername_alias = 'Wim';

but probably it is the result of lookups to a dimension alias or similar logic.

Lastly, the mother process can then know for sure that 'vUsername_alias' is populated correctly.

It helps us in segregating code in processes, calling generic TI processes and consume the return values like global string variables.

When using a recursive approach, you would have:

StringGlobalVariable( 'vMode' );

StringGlobalVariable( 'vCube' );

If( vMode @= '' );

    n = 1;

    While( n <= Dimsiz( '}Cubes' ));

        vCube = Dimnm( '}Cubes', n );

        ...

        vMode = 'clear cube';

        ExecuteProcess( GetProcessName );

        ...

        n = n + 1;

    End;

ElseIf( vMode @= 'clear cube' );

     CubeClearData( vCube );

EndIf;

When calling itself, the TI process with a given data source type could even switch to a different data source type.

GetProcessName is a built-in TM1 variable that contains the name of the current TI process. We are not obliged to hardcode the process name.

Above is a silly example of course but you get the point.

On the one hand, the risk is to overcomplicate matters. On the other hand, I like it that all logic is contained within a single TI.

No need to maintain separate TIs, where without any doubt, some values are duplicated, risk of 'forgetting to adjust', etc.

It makes migrations easier, to name just 1 benefit.

The TI debugger in PAW also plays nicely with these recursive calls to the same process.

Hope that this information clears up some confusion as well as introduces a more advanced way of writing (some of) your TI scripts.