TM1 Forum

Hi All

I am looking for a TI process command that can be used to immediately disconnect clients from the server at the time this TI process is executed (through a scheduled chore).

I can't seem to find one though, in the help or notes. Does anyone know of this ?

I want the ability to disconnect the client - even when they are in the middle of retreiving data or sending it.

Any solutions would be gladly listened to !!!

Thanks
Ajay

There are API calls to disconnect users but no equivalent TI functions.

Why would you have a need to do this in the first place?

I would be interested in something like this as well.

For me the reason is Contributor. If users are in a model and working with data, and a TI process is kicked off to update data, this causes the users sandbox and base data to be out of sync.
Here's where it gets really weird. If the user hits the recalculate button the data is show to user. Everything appears to be fine, but when they hit the commit button it wipes out the data that was brought in through the TI process.

Basically in order to make mass updates through a TI or through a spreadsheet as an admin, you need to make sure all contributor users have committed their data and logged out so as to make sure no sandboxes are open.

Im hoping that it would be possible to create some kind of process to commit users data and get their sandboxes closed and keep them locked out untill updates had been completed.

By the way when I say sandbox, I don't mean a user created one. Contributor uses sandboxes for whoever takes ownership of a node, it just doesnt show up to the end user.

lotsaram wrote:There are API calls to disconnect users but no equivalent TI functions.

Why would you have a need to do this in the first place?

Hi Lotsaram,

Could you possibly expand on this. Is there a command to disconnect all users or do you have to go through them all with a different command??

Thanks in advance,

Jim.

Someone can correct me if I'm wrong, but I don't believe a disconnect all function exists in the C API. You'd have to get the array of handles that represents all the client connections to a particular server and then disconnect them one by one.

On the other hand, if you're using the .NET API there is a LogoutAll method in the ServerInfo class.

bagovino wrote:Someone can correct me if I'm wrong, but I don't believe a disconnect all function exists in the C API. You'd have to get the array of handles that represents all the client connections to a particular server and then disconnect them one by one.

On the other hand, if you're using the .NET API there is a LogoutAll method in the ServerInfo class.

I havn't tested it but I believe that logs the current client out of all of the servers that they are connected to (equivalent to the TM1 -> Network -> Disconnect command in the pre-Excel 2007 menu), not that it disconnects all clients from a server.

You're right, I just tested it looks like the Users collection is only populated by connections you create in your session, so you can't use it to log out everyone.

Any way of doing it outside excel? We are looking to compile an executable. When I say we I mean a colleague and I'm trying to give him a good head start,

Jim.

jim wood wrote:Any way of doing it outside excel? We are looking to compile an executable. When I say we I mean a colleague and I'm trying to give him a good head start,

You know that the C++ bit of the "Classic" API isn't really intended for use with Excel, right?

You can create an .exe in C++ or VB6 using the classic API; neither of those will require Excel, nor for VB code does it even need VBA[1]. (Though I do have an Access database which uses API code to connect to cubes, so it works in non-Excel VBA as well... but that's just by the by.)

In theory you can incorporate the Classic API's code into a .Net executable as well, but it's not commonly attempted.

You could also create a .Net executable using the .Net API but there's little point; as per the previous couple of posts in this thread and others that I've made, the powers that be at Iboglix decided to make the .Net API "as useful as chickens**t on a pump handle" (to quote an expression that I once heard and find apposite in this case) when it comes to creating an administrative tool. The .Net API is fine if all you want to do is pull some numbers from a cube and is a waste of space for anything more comprehensive.

Obviously the third choice that you have is the Java API; that's clearly an "outside Excel" solution as well.

The primary difference between creating an .exe and using Excel is that you do have to log into the server with a stand-alone; you can't just piggy-back off an existing connection the way you can in Excel with TM1_API2HAN.

However all of these will be non-trivial undertakings. Set aside plenty of time, and plenty of patience.

[1] Pedantry corner: The VBA library is in fact used in VB6 .exes. This is why M$ was able to dump support for VB6 without pulling it from VBA. However I of course mean that you aren't limited to coding VB API code in a VBA environment.

Jim, check your ACG email. If you do decide to go the .NET route I attached some sample code using the C API in C# using pinvoke.