Do You Automate Or Extend TM1? (Poll and discussion)

[Alan Kirk]

I was talking to someone just recently and said that I thought that most TM1 admins had probably used macro functions extensively, and that many if not most had at least dabbled in the API. They said that they didn't feel that that was true, and that VBA usage had been diminishing over the last 10 years or so since Action Buttons and Active Forms have made it less necessary.

It was most interesting to get a different perspective on that and it set me to wondering about how the current crop of users and administrators feel about this (not to mention a potential interesting source of discussion). Consequently I present the following poll. There are 10 options, and you can choose up to 9 of them (since the first one is exclusive of all of the others, obviously). You can change your vote if you later start using a different set of tools. By "use" I'm not necessarily referring to something that you do on a day to day basis, but something that you at least use periodically. For example if you have written a solution to loop through a subset to "burst" a standard report once a month, then you "use" VBA. If you have written an application to turn your chores on and off using the classic API, then you "use" that. But if you once dabbled in a test process to pull a number out of the server using the .Net API, then you don't really "use" it, you just played with it.

So have at it, and feel free to post about any kewl things that you've come up with or any frustrations about kewl things you would like to come up with if only the tools were good enough. (I've stickied this for 30 days in the hope of getting a decent cross section of opinions.)

[RJ!]

I picked no, reason being I think our set up is rather basic in function (though maybe not in complexity) and we haven't come across a situation to warrant it.

As much as I'd like to dabble in the VBA & RESTful API, it pretty much comes back to if it ain't broke, don't fix it. On top of this, we are at a cross roads in regards to the future of our TM1 Environment. The other reason we have not been able to go too far into building solutions with VBA/RESTful API is skills (either lack of or lack of a proper back up).

We are a 2 man team consisting of a Manager/Dev + Dev/Admin that do everything "in-house".


I'd be interested to see how many of those that have selected one of the other options are not working as consultants?

[garry cook]

I'd be interested to see how many of those that have selected one of the other options are not working as consultants?

My teams have all been in house over quite a few different companies over a number of years and without some of these tools (especially VBA which is used on a daily basis), we wouldn't have been able to do a large proportion of the stuff we have done previously. With the exception of the most basic of requirements, I'd much rather work with my own code than an Action Button as it gives a substantial level of control that we don't exist with Action Buttons. It would be like using TI with only the wizard - without it we would be completely hamstrung in terms of user interfacing to the system.

[George Regateiro]

I'd be interested to see how many of those that have selected one of the other options are not working as consultants?

Count me as 1. We have utilized the APIs in house fairly extensively. Requirements around removing disabled AD accounts from TM1 automatically and having auto killing of long running threads are just some of the things that we have been automating with the various APIs for a while. We have avoided VBA just because of the need for TM1 Web. Up until this point the API work has been around admin and automation tasks, we have tried to keep the UI components stock. With the Rest API coming into play though I can see a time where our TI use decreases to gain the logic and control functionality of other languages, allowing TI to become the data loading tool that it is good at.

On thing that I did not notice on the list was the entire Java TI component (unless we are wrapping that in the Java API). Is anyone using that to any extent? I remember seeing some initial performance metrics that made it seem promising but have not seen much on it since.

[Alan Kirk]

On thing that I did not notice on the list was the entire Java TI component (unless we are wrapping that in the Java API). Is anyone using that to any extent? I remember seeing some initial performance metrics that made it seem promising but have not seen much on it since.

D'OH!!! You know how when you are getting really, deeply involved in something you think you've done something relating to it, but you were only thought it out without having actually done it? Same principle. I've been deep diving on the Java TI extensions recently and had it firmly fixed in my mind that I'd included it on the list when clearly I hadn't. (Java API isn't the same; that's really client side, the new TI extensions are server side.) My bad. Unfortunately I can't change the list now without blowing away the votes. This could explain the votes in that last item, though...

[paulsimon]

Hi Alan

I tend to try to try to avoid too much non-TM1 coding. For the simple reason that I am a contractor and someone has to maintain the system when I leave. I am usually working with Finance users, rather than IT staff, and not many Finance users are that comfortable with VBA let alone Java. Even with IT Depts they are not going to be too happy if they are .Net houses and you leave them with a lot of Java, or vice-versa. Obviously it is a different situation if you have an in house team and you have at least two people with the necessary skills to provide cover for holidays and in case one leaves. Even then, it will make it harder to recruit someone else as you need to find someone with both TM1 and Java skills or you need to find a Java expert in your IT Dept and teach them the TM1 APIs to help out.

The other reason is that many of the systems that I work on use TM1 Web, and you cannot use VBA in these. That usually means a combination of inventive Excel Formulae and some of the URL API which is so limited that it is not difficult to pick up.

My other tool for automating TM1 is good old DOS BAT/CMD files. I use these for things like shutting the Services down, copying in items for promotions, backups, etc.

I do have a considerable library of TM1 Macros some of which use the API but I sell these as an Add In so the users only need to use them and don't need to get involved in VBA, etc.

Regards

Paul Simon

[Steve Rowe]

+1 for DOS, have used the API for calling TIs but don't currently so left that unchecked...

[MarkTM1]

Use out of the box functionality. While VBA would be useful for more flexible report bursting, the ‘Print Report’ functionality largely met the needs for report bursting and is easy to understand by users. Can see RunTI will be useful if we develop parallel uploading of data. Like to keep things as simple as possible.

[TrevorGoss]

I am very pleased with the TIRun program, we now kick large cubes in a TI which we call within a batch, rather than someone running it in our client and waiting for over an hour for there desktop to be free.

So I gave it a vote..and now it is winning, excellent.

[macsir]

TM1 REST API is the future! I am using it now.

[TrevorGoss]

TM1 REST API is the future! I am using it now.

As I've heard lol, you have expressed delight in this in the TM1REST API that we have both contributed to. Soon I will give it a try and post my opinions.

There is a tool that Alan left out, which would mean it goes under the "I use some other automation method that Kirk forgot to include on the list, dangit" and that is TM1xfer. Does anyone use this? So far for me it has been a failure, I get an error telling me that access is denied and the documentation on this error was not very helpful.

[Alan Kirk]

There is a tool that Alan left out, which would mean it goes under the "I use some other automation method that Kirk forgot to include on the list, dangit" and that is TM1xfer. Does anyone use this? So far for me it has been a failure, I get an error telling me that access is denied and the documentation on this error was not very helpful.

I left it out because prior to this post I'd never heard of the thing. I'm still not completely sure what the point of it is, though presumably it does have one. It's described as follows:

The tm1xfer utility compresses and moves TM1® server objects from one platform to another platform while preserving mixed case names for objects on both Microsoft Windows and UNIX platforms.

To go from one Windows platform to another right clicking on 7Zip and shunting the file into an archive would seem to be an easier way. (If 7zip is installed, and I can't imagine why anyone wouldn't - I know Steve, I know, "Mermaid's Brassiere".)

If it's Windows to that case sensitive pain in the... I mean, a flavour of *nix, then... how often do you need to do that?

However I'd imagine that whoever wrote it saw some kind of need, and it may be one that I'm not picking up on.

Aside from which in the question I was thinking more along the lines of automation in day to day or periodic use. Something like this would seem to be a utility that you use in conjunction with TM1 but not necessarily as part of an automated extension of it.