Get USERID in TI Process

[John Hammond]

As ususal I am probably missing something here.

I can't find a function to do this in the TI list.

So I looked in Server Manager and tried to use this code.

Code: Select all

userid = SubsetGetElementName('}clients', '}TM1_DefaultDisplayValue', 1);

Unfortunately TI won't process Private subsets which of course }TM1_DefaultDisplayValue will have to be private since it is per user. (Why this restriction btw?).

So I searched the manual and the forum for what I would consider is quite a common operation but found nothing.

Please, does anyone have any ideas?

[John Hammond]

Just wanted to get the Servername too but again is not doable in TI I think, but checking in the API all is possible.

TM1SystemServerClientName_VB
Purpose Returns a client's name.
Definition Declare Sub TM1SystemServerClientName_VB Lib "tm1api.dll" (ByVal hUser As Long, ByVal index As Integer, ByVal res As String, ByVal max As Integer)
Parameters hUser is a long. It is user handle returned by the function TM1SystemServerConnect.
index is an integer. This integer is an offset into the list of available servers currently available to the client. These servers are listed in the admin server user interface.
res is a string where the result is returned.
max is an integer indicating the maximum length of a string that can be accepted by res.
Result The function returns a string. The string contains the name of the current user. Use TM1ValStringGet to retrieve information.
Security None.
Errors None.
See Also TM1SystemServerConnect

Is there any plans to include all API functionality in TI processes?

[Alan Kirk]

As ususal I am probably missing something here.

I can't find a function to do this in the TI list.

So I looked in Server Manager and tried to use this code.

Code: Select all

userid = SubsetGetElementName('}clients', '}TM1_DefaultDisplayValue', 1);

Unfortunately TI won't process Private subsets which of course }TM1_DefaultDisplayValue will have to be private since it is per user. (Why this restriction btw?).

TI runs at Admin level. Even an Admin user can't see clients' private subsets and incidentally, that's also true of the API (or at least the C/VB API, I haven't used the .Net one extensively yet). The process knows who triggered it, but it still runs as Admin. To change this could have unintended and unfortunate consequences.

So I searched the manual and the forum for what I would consider is quite a common operation but found nothing.

For some odd reason the 9.4 reference guide omits a reference to the TI function TM1User(), though it does mention the corresponding worksheet function. Nonetheless, for (I think it was 9.1) and above, TM1User() is a valid TI function.

[Alan Kirk]

Just wanted to get the Servername too but again is not doable in TI I think, but checking in the API all is possible.

TM1SystemServerClientName_VB
Purpose Returns a client's name.
Definition Declare Sub TM1SystemServerClientName_VB Lib "tm1api.dll" (ByVal hUser As Long, ByVal index As Integer, ByVal res As String, ByVal max As Integer)
Parameters hUser is a long. It is user handle returned by the function TM1SystemServerConnect.
index is an integer. This integer is an offset into the list of available servers currently available to the client. These servers are listed in the admin server user interface.
res is a string where the result is returned.
max is an integer indicating the maximum length of a string that can be accepted by res.
Result The function returns a string. The string contains the name of the current user. Use TM1ValStringGet to retrieve information.
Security None.
Errors None.
See Also TM1SystemServerConnect

Is there any plans to include all API functionality in TI processes?

I think you'll find that that API function returns a client's name, not a server name.

And why on Earth would you want to do that in a TI? A TI process can act on only one server, its own. Consequently there's no need for it to know what the server's name is, it's simply "the server that I'm running on, and the only one that I can execute code on". If you really want to know the server's name for whatever reason, probably the easiest way is to simply store it in a control cube somewhere.

[John Hammond]

IBM - no thanks for leaving out TM1User() from the docs.

Alan - thanks again.

And why on Earth would you want to do that in a TI? A TI process can act on only one server, its own. Consequently there's no need for it to know what the server's name is, it's simply "the server that I'm running on, and the only one that I can execute code on". If you really want to know the server's name for whatever reason, probably the easiest way is to simply store it in a control cube somewhere

Wanted to write generic code that ran on any server which needs to know the directory the server is running in and the server name is part of that. Most products give you obvious stuff like a variable that contains the name of the program being run so you can be very generic about your functionality.

I think you'll find that that API function returns a client's name, not a server name.

Should have made that clear. Was having a general moan about there being stuff in api that was not in TI.

[Michel Zijlema]

John,

Wanted to write generic code that ran on any server which needs to know the directory the server is running in and the server name is part of that. Most products give you obvious stuff like a variable that contains the name of the program being run so you can be very generic about your functionality.

Alternatively you could setup a cube with the server specific information you need and have the TI process reference this cube. You can add the cube to each TM1 Server and fill the cube with the required TM1 Server specific information.

Michel

[image2x]

As ususal I am probably missing something here.

TI runs at Admin level. Even an Admin user can't see clients' private subsets and incidentally, that's also true of the API (or at least the C/VB API, I haven't used the .Net one extensively yet). The process knows who triggered it, but it still runs as Admin. To change this could have unintended and unfortunate consequences.

I'd very much like to see a TI option to run with the effective permissions of the initiating user.

As there is no bulk data import facility for end users like there is in Cognos Planning (the Data Load wizard), we've had to rely heavily (200-300 templates a month) on user template uploads to TM1 (via an http upload script) and then they initiate the TI import process themselves. Of course, as TI runs as Admin, it bypasses all of the account/dimension security we have in place.

Of course, the better overall solution for us would be for Cognos to implement a client wizard for bulk imports like there is in CP.

--John

[Andy Key]

If it is the ServerName and DataBaseDirectory you want, why not use tm1s.cfg as the source for a TI process, use a delimiter of =, check the value in the first column, if it matches an element in the measure dimension of a System Data cube, then store the value from the second column.

Just use tm1s.cfg with no path as the DataSourceNameForServer, and create a dummy one somewhere that you can access for the DataSourceNameForClient.

Schedule it to run at a suitable interval, or call this TI at the start of the process that refers to the DataBaseDirectory to make sure it is up to date. This saves you having to remember to change the cube manually if you are copying servers around.