TM1 API get parameters names from TI process

[stex2727]

I'm comfortable with running a process (with parameters) through the API using this code

http://forums.olapforums.com/viewtopic. ... 4468#p4468

Rather than hardcoding or duplicating the parameters on a spreadsheet I was wondering if it is possible to get a list a processes parameter names and their default values directly on the server. Or if someone could point me in the right direction


Steve

[jim wood]

I'm currently playing around with loading procsses via VBA and I aslo would be interested in this.

[lotsaram]

I haven't ever looked into doing this with the API, don't even know if it is possible. However it is quite easy to read the parameters and default values directly from the .pro file. It's a simple kludge (assuming you have access to the data directory.)

[Mike Cowie]

Hi Steve,

Using the TM1 API you can get some details about the parameters once you have a valid handle to the TI process. There are a number of not officially documented properties of a process that you can retrieve. Because they're not officially documented they could technically change at any time even though I don't think they ever have.

Here are the properties I believe you can retrieve across any officially supported TM1 version (hopefully what they return is obvious to anyone familiar with TI parameters):
Declare Function TM1ProcessParametersDefaultValues Lib "tm1api.dll" () As Long
Declare Function TM1ProcessParametersNames Lib "tm1api.dll" () As Long
Declare Function TM1ProcessParametersPromptStrings Lib "tm1api.dll" () As Long
Declare Function TM1ProcessParametersTypes Lib "tm1api.dll" () As Long

Since these are properties of a process, you need to use TM1ObjectPropertyGet to retrieve them. If you had a handle to the TI process for example, the function call might look something like this:
Dim DefaultValuesArrayHandle As Long
DefaultValuesArrayHandle = TM1ObjectPropertyGet(ValPoolHandle, ProcessHandle, TM1ProcessParametersDefaultValues)

I think I've previously tried and successfully used all but the PromptStrings item (which I just haven't needed yet). All of these will return a handle to a TM1 array as far as I know (be sure to use TM1ValType to verify that, in case there's a problem).

In particular, I would expect that these two always return a handle to an array of string handles:
TM1ProcessParametersNames
TM1ProcessParametersPromptStrings

This one should always return a handle to an array of string or real (double) handles, depending on the parameter type (you'd have to check each array item's type before reading it using TM1ValStringGet_VB/TM1ValStringGet or TM1ValRealGet):
TM1ProcessParametersDefaultValues

This one will tell you the expected type of each parameter and returns an array of index handles:
TM1ProcessParametersTypes

Note: this last property takes a bit of extra work to use - for each type index handle you get back, you need to get it's index value using TM1ValIndexGet and compare the result to one of the two TI variable type constant functions that TM1 has for parameters (you also need to use TM1ValIndexGet on these, too):
Declare Function TM1TypeVariableString Lib "tm1api.dll" () As Long
Declare Function TM1TypeVariableNumeric Lib "tm1api.dll" () As Long

For example, if you had a handle to parameter 1 you could use something like:
Parameter1ValueIndex = TM1ValIndexGet(SessionHandle, Parameter1ValueHandle)
If Parameter1ValueIndex = TM1ValIndexGet(SessionHandle, TM1TypeVariableNumeric) Then
MsgBox "This parameter is numeric."
Else
MsgBox "This parameter is string"
End If

Obviously, if you don't have parameters in a process you'll get a handle to an array with no items!

Hope this is useful. Sorry the code snippets aren't more detailed, but I don't have anything that can be easily snipped out that would make much sense, out of context. If you know a little about the TM1 VB/C API this should be enough to get you steered in the right direction, however.

Regards,
Mike

[tomok]

If your aim is to rid yourself of having to worry about parameter lists as part of your VBA code you can write the processes to be "parameter-less", meaning they get their parameters from a cube, or a subset. For example, I know we all like to create processes that are good for all situations, like any year, or company, or budget version. Let's say you have a TI process that takes the current budget version for the current working year and exports it to flat file. Whereas, you could pass the budget version and year into the TI process via parameters, you could also grab those two parameters in the TI process from a "parameters" cube with a CellGetS(ParamCube,Dim1,Dim2,.....) in the Prolog tab or from a subset. It is effectively the same thing as passing a parameter but you don't have to worry about a parameter list inside your VBA code. Of course, you still have to take care of populating the parameter cube or subset before you call the process.

I always create an "Admin" cube in my models and in those I store things like "Current Working Version" or "Current Working Year", etc. and in those I store names of elements from the Version and Time dimension so that I can access those in reports and/or TI processes. Just a thought.

[stex2727]

Thanks guys for replie, unfortunately I'm in Sydney for 2 weeks but will have a look at API when I get home.

Steve

[Darkhorse]

Going to revieve a 4 year old thread,

did anyone get this working ?

[iansdigby]

I couldn't get this to work.
TM1ProcessParametersNames seems to return a TM1ValTypeIndex, though it is supposed to be an array of strings.

[Alan Kirk]

I couldn't get this to work.
TM1ProcessParametersNames seems to return a TM1ValTypeIndex, though it is supposed to be an array of strings.

It doesn't return an array of strings, it returns a handle to an array of strings as Mike Cowie said way back in 2011. You then have to iterate the members of the array using TM1ValArrayGet.

But I do agree with what Tomok also said lo those many years ago; in most cases the API shouldn't be the first place to turn to to solve a problem. There are usually less head-bashing approaches.