When executing TI processes we will very often like to log the parameter values at run-time. Why? In case anything is not as expected (functionally, or a TI error, server crash, ...), the user could ask for assistance and we almost immediately know the implied parameter values (even without asking the customer to provide it). Or we just want to know ourselves in an easy way: did we already load the data for company XYZ?

In these cases, you can set it up in a variety of ways, from simple to very advanced. Advanced solutions could be a SQL server database or a dedicated cube in TM1. Simple solutions might just use the LogOutput function. This short article demonstrates the simple approach.

So the LogOutput function would create an output such as this when the process parameters include Year, Period, Version and pIndex (first solution involves Expand, second solution involves pipe string concatenation):

LogOutput( 'INFO', Expand( '... parameter values -

    Year: %pYear%.

    Period: %pPeriod%.

    Version: %pVersion%.

    Index value: %pIndex%' ));

LogOutput( 'INFO', '... parameter values - '

     | 'Year: ' | pYear | '. '

     | 'Period: ' | pPeriod | '. '

     | 'Version: ' | pVersion | '. '

     | 'Index value: ' | NumberToString( pIndex ) );

There is also the option to have the code on 1 line. It makes the code a bit less readable but you can choose:

LogOutput( 'INFO', Expand( '... parameter values - Year: %pYear%. Period: %pPeriod%. Version: %pVersion%. Index value: %pIndex%' ));

LogOutput( 'INFO', '... parameter values - ' | 'Year: ' | pYear | '. ' | 'Period: ' | pPeriod | '. ' | 'Version: ' | pVersion | '. ' | 'Index value: ' | NumberToString( pIndex ) );

Notes:

• You can adapt the code yourself. However, the Excel file stored here (https://community.ibm.com/community/user/viewdocument/logging-process-parameter-values?CommunityKey=8fde0600-e22b-4178-acf5-bf4eda43146b) allows you to generate the code in multiple ways. You can then copy/paste a blue cell in PAW. Most of the time, parameter values remain quite fixed and you work in a constent manner. The other options in yellow will also remain fixed usually - although anyone can have their own preferences.
• I prefer the more long-winded pipe concatenation, since parameters inside a string are not validated. When pVersion does not exist, Expand will not throw an error at design time, only a run-time. The longer syntax will be indicated as wrong in PAW for the parameter pVersion.
• A distinction is made between textual and numerical parameter values.
• It would be great if IBM PA would log the parameter values but alas it does not do that.

Enjoy ! :-)