TM1 Forum

Hi

I disagree with one items requested. I actually like TM1's design with all dimensions being equal. The problem with having a designated time dimension, is that for some applications two time dimensions are better, and for others its 3 etc. In insurance it is not unusual to see up to 4 time dimensions in a cube. Even in normal planning you may have one dimension being the month in which a forecast was made, and another being the months that are being forecasted.

Similarly I see no reason to have a dedicated measures dimension. Eg in many systems the Measures dimension is little more than Value and Text, but the real 'measures' dimension, the one where most of the calcualtions take place is actually the Accounts/Nominal dimension.

Dimensions can always be tagged as Measures or Time to help out MDX based tools.

One point that I would agree with though is that it should be possible to name the levels in more than one hierarchy. The }HierarchyProperties cube only allows for a single Hierarchy0

One of the strength of TM1 is its ability to cope with ragged hierarchies, which are very common in Nominal dimensions, etc. The fact that some MDX based front end tools cannot cope with ragged hierarchies and need defined levels is a weakness in those tools, and not something that should be changed in TM1. If necessary strict levels can be forced by duplicating elements eg Other Expense Level 4, Other Expense Level 5. However, this is a compromise and not how most businessed would prefer to view their Chart of Accounts (though some do like a fixed number of levels).

I have been working with Cognos BI and TM1 lately. I am disappointed with the degree of integration. Reports that run in seconds in native TM1 or TM1 Web can take minutes in Cognos BI. Cognos BI is limited to querying a single cube. Many of our reports show values and FX Rates, so we need to pull the FX Rates into the main cube, just so that Cognos BI can report on them (tip make the Rate Measures consolidations of Balance Measures to avoid the need to feed). Cognos BI is unable to recognise TM1 Subsets, Views, Drill Thrus, cube to cube or to relational, Pick Lists, etc. Therefore you end up building report centric features instead of server centric features which lowers re-usability. The ability to adapt the framework is not clear.

I would much prefer to see a set of web controls that could be dropped into VB.NET. This would probably be within reach of the many VBA savvy accountants out there, and would have a wider pool of developers.

Cognos BI has its place in mixed relational and TM1 environments, but in my view it is still too much of a relational-based tool.

I hope to see some big improvements when TM1 10 is launched.

It is still the front end that is letting down a very good server.

TM1 Web is OK, and you can get a reasonable report in it much quicker than you can using Cognos BI. However, Excel is not a perfect report development tool. Active Forms limit expansion to Rows only, and don't cope well with multiple nested row dimensions.

In the TM1 Web Cube Browser I would like to see the Executive Viewer ability to collapse some but now all items in eg nested row dimensions, so expanding the inner dimension doesn't always mean that it expands within every member of the outer dimension, but you have the ability to expand just within the selected element in the outer dimension.

I like the TM1 Web Cube Browser. It is fast and has some good funtionality. In the TM1 Web Cube Browser displaying the dimensions across the top is a major issue since only 3-4 can be displayed before you just get a little number to tell you that there are more dimensions. Why can this be more like MS-Pivot Tables where you have a list (A vertical list not a series of big buttons) of available dimensions, and you drag on only those you want to show?

Given the nature of the Excel to TM1 interface I don't think a lot can be done to improve the latency issue over WANs. I tend to feel that a web based delivery is what people are looking for, as TM1 is increasingly being sold at Enterprise level thanks to IBM's backing. However Excel-TM1-Citrix is often a good compromise. You can use the Macros you can't use in TM1 Web, but the latency is lower. True you need additional hardware but a Web deployment often needs an application server and web server too.

TI could be improved with eg picklists for functions, etc. However, overall TI is a good tool and it is fast. Perhaps the ability to use JDBC and network database links rather than just ODBC which is considered old hat by some IT Depts.

There should be more standardistion eg why SIBSIZ in Excel but SubsetGetSize in TI?

I agree on the need to rename Extract Views as Queries.

As TM1 is breaking more into the Enterprise space, more companies are demanding that there is an automated method to promote from Dev to UAT to Prod. It would be relatively easy to do this if only it was possible to copy a .pro and run a command to get it registered on the server, without the need to shut the server down. If you can do the same with .cho, then that is all you need, as you can then do everything with a .pro, and in a controled environment, that is how it should be done. Eg you can create cubes, views, subsets, load rules, etc.

Ability to re-order dimensions programatically from TI. The problem we have is that some of our smaller systems do a full deployment and reload each time. There is no way to optimise the physical order of the dimensions except via the GUI so deployment cannot be automated. Also in production, developers are often not permitted to use the GUI or even log in.

Improvements to the usability of the API. I would like to see a proper object model based API instead of the loose connection of functions that we have at present. The .NET API was a step in the right direction but it seems that its future is in doubt. I think that IBM should be supporting both Java and .Net as the two main development standards. At least .Net gives the ability to use VB which is more familiar to accountants than Java's curly bracket syntax. Correc the many errors in the documentation on the API. Fix the bug in the help file than just gives a long list of functions with no index. (Kind of seems like someone thought, oh not many people will ever use this so why bother).

Combine all Help Files back into a single searchable document, as I still have to look in three different guides to find out which one covers the thing that I am looking for.

Introduce PALO like syntax in the Rules language so you can write something like SALES = N: Units (+) * Price, with the (+) meaning that the feed should come from the Units rather than the price.

Add the ability to extend the rules language via the API.

Do away with the need to use the DB() on the RHS of string rules. Why can't people use [ ] notation? This is a frequent gotcha for beginners.

Do away with BLB files on Rules. I have seen so many errors where people have just copied the RUX, and then opened the rules to edit them, which has called up the old rules from the BLB file. Either bring the formatting information into the RUX or do the formatting in a way that does not require the rule statements themselves to be replicated in the BLB.

Convert Chore, Process, View, Subset, and Rule files to XML, rather than the home grown set of flags that are impossible to understand.

Fix silly bugs like the need to do Ctrl-C twice in TI. Surely IBm's own consultants encounter these too. Is there a pipeline for IBM's own consultants to get things fixed. Various people have raised PMRs for this but this along with a lot of other bugs never seem to get fixed. Yes they aren't show stoppers, but they can be very off putting to new users.

That is probalby a long enough list for now.

Regards


Paul

The legendary Christmas Wishlist was kicked off by the BigDster at 10:19pm (my time), Wednesday 7 December, 2005. A day that will live in infamy, only because of the number of requests on it that were never implemented.

If indeed someone is reviewing this thread, is it worth reposting the link to this? It was a pretty lengthy list of which numerous points are likely still valid. Just a thought.

You certainly raised it in that list on Friday 27 January, 2006. (Is anyone feeling old yet?)

Yes, I really do feel old when you put a date on it like that

I probably shouldn't mention that your very first request on the list (8 December 2005) was for "a pair of blonde female Swedish masseurs".

The seven years of parenthood that kicked in a few weeks after I posted that have dulled my memory of what I would actually do if I received such a gift

Generally I agree with most of the other posts. The reason I'm only putting forward the one above is simply that it's something that when I talked to the Applix main IT bods (as they were at the time), they reckoned that this wouldn't take a huge amount of effort - certainly compared with a lot of other things that folk were asking for. Realise that was a while back and things have moved on but in terms of this area, it's not had a huge amount changed since then and it's been a PITA ever since TI first appeared way back in V7 (at least I think it was 7, seem to remember using it in 7.1.4).

Sadly, it seems unlikely that any IBM bods reading this post will have much influence on the overall roadmap with things like complete GUI redesigns as I think that's likely to be set in stone for the forseeable future but something like changing the query type is something that seems to me as a possibility to fit into the existing release schedule without a huge impact on roadmaps.

Don't get me wrong - it's not that I think these points shouldn't be made or anything, just that I've had my fingers burned with lenghtly correspondence with Applix / Cognos / IBM / Key User Groups / Support Requests etc and have for the most part seen no move towards some of the core areas. Massive movements in other parts to be fair but at the expense of some of the basic functionality. I'm hoping that technically smaller things like the .que move for TI inputs might stand more of a chance of making it into a version some time sooner than many of the other key points raised.

Anyroad, Merry Xmas & Happy New Year when it comes to all

I may just be talking crazy but I hit this issue today and thought I might as well throw it in the pile too.

I need to get the Standard Deviation of a set. Thinking I was smart, I wrote an MDX query to do it, but quickly learnt it can only be used as a comparison value (i.e. obtain elements greater than the StdDev) and can't be used to retrieve the actual value. So now I've built a big ugly workaround to do it.

Using MDX to obtain values like StdDev and Mean in a TI or Rule....that would be handy.

Christopher Kernahan wrote:Using MDX to obtain values like StdDev and Mean in a TI or Rule....that would be handy.

I agree. Extending the rules language to include support for MDX would be huge.

Probably most of these items have been mentioned in earlier posts, but my wishlist:

analysis tools (Architect/Perspectives)
- asymmetric selections
- integrate some EV functionality
- be able to do some analysis on dimensions/hierarchies (compare, find common parent, etc)
developer tools
- debugging of TI and/or improve logging
- autocomplete & code markup for rules and TI and be able to select a word with double-click
- .NET API where you can also create elements/dimensions/cubes instead of just reading data from a cube
- extend MDX support
- GUI improvements
- - > now I have to scroll back through all my dimensions to my cube after I save a subset (There must be a way to better organize cubes, dimensions, processess)
- - > there is this 'goto line' button that takes up a good portion of the screen !?!
- - > find/replace in TI
- - > make the copy function work when the c key is pressed (OnKeyPress), not when the ctrl button is released after the c key !? (like probably most of you I have developed a TM1-copy-paste-syndrom in all other applications; ctrl-c-c-c....)
- Rules/TI functions:
- - > there is a TABDIM function but no function that returns the number of dimensions in a cube
- - > be able to use arrays in TI:
DimElements[1] = 'Jan';
DimElements[2] = '2011';
DimElements[3] = 'MyMeasure';
CellPutn(Value, 'MyCube', DimElements);

This is what I could come up with in the last half hour. Let's see if any of the suggestions on this page here will be implemented!

As mentioned in the thread: http://www.tm1forum.com/viewtopic.php?f=3&t=3696

It would be handy to enable sandbox creation without the ability to promote the sandbox data. As mentioned in thread I can think of instances where this would be very handy indeed.

While think of it
Allow an instance to release its garbage RAM back to the OS after a certain amount of non-use.

That might actually be possible Steve if the developers gave this a go (and didn't use a custom memory management system): http://msdn.microsoft.com/en-us/library/ms686234

It would be simply lovely if I could organise my TI processes into folders.

Paris
x

(note the UK spelling )

ParisHilton wrote:It would be simply lovely if I could organise my TI processes into folders.

Paris
x

(note the UK spelling )

They might argue that you can do that using the application folders, but either way keep the suggestions coming guys......

jim wood wrote:

ParisHilton wrote:It would be simply lovely if I could organise my TI processes into folders.

They might argue that you can do that using the application folders

They doubtless will and you can, but the problem is that it's poorly implemented as discussed here. Granted the set-up cost of moving them into folders will be a one-off, but even if you have only 20 or 30 chores it will be substantial. But more importantly, the problem shouldn't exist in the first place. I didn't bring up issues like that (or the poor design of slice buttons, or the lack of an AsciiAppend function, or the fact that you can't see the scheduled runtime of a chore without disabling it, or the lack of a full implementation of MDX, or the unbelievably bad design of having the help files split up so that you have to take a stab at figuring out which one contains what you need, or...) mainly because there's no point in making this too much of a wish list for specific features. Should we get the opportunity to have a chat with the development team or some members thereof we could spend forty days and forty nights covering points of specific deficiency, but many would get lost in the noise.

However if we were to apply a broader brush on this subject, I'd say that the problem could be described as this; that there is often a disconnect between what seems like a cool feature in the development lab, and how that feature operates in the real world. It's almost as if some features (such as the aforementioned application folders) are tested out on Planning Sample and if they work well enough there then "yep, let's ship it!" notwithstanding that when you get into a real workplace, where the cubes and views live in multitudes and the rules and TI code are long and complex, those cool features don't work so well. This is presumably why the development team don't see a problem with the dinosaur of a TM1 editor either; in a very simple situation, when you allow that appalling wizard to generate the code for you to load simple data files where there are no complications, it works well enough. But the reality is that a real life workplace, with interfaces from multiple legacy systems each with its own quirks, demands genuine code and not the dribbling of the Wizard.

In my original post I raised the question

I wrote:Third party utilities like Vizier and TM1 Tools have identified substantial gaps in the basic functionality. When are (or, indeed, are) these gaps going to be addressed in the main TM1 product?

And in many ways, the application folders are just another manifestation of this. If I had to re-express that it would be "when will the development team put more emphasis on the way features need to be used in real workplaces, with large scale models as demonstrated by {insert laundry list of issues here}?"

Alan,

I was keeping in line with the thread. I was simply pointing out what IBM might say to the point. I'm not doubting whether they are suitable or not. Lets keep this to suggestions rather than turning it in to a what's good and what's not debate. Keep the suggestions coming guys.....

I don't know if this issue is too small or too specific. I read the whole thread and see many things I've been desiring, but I didn't see this:

It would be nice if there was something between public and private. Particularly subsets and view.
A user frequently makes something relevant to their business unit, but not necessarily the whole company. They'd like to share it with people in their security group. But only the admin can make it public (I know there is a TI process that can do it)
But this would cause these items to proliferate. As it is, I'm already starting to feels that I have too many subsets and views.
It would be nice is the security could be set to none so these public items wouldn't show on everybody's drop down, and that a user could make 'public' to their own security group or otherwise specify a range of who should see it.

The one thing we all want here is the ability to colour a cell e.g. red when negative, within the cube viewer. So, conditional formatting please a la Excel?

Another Simple One with Much Benefit

In Process Called Traceback in Message Log Can we have the parameters listed under which the process ran?

pmakulski wrote:It would be nice if there was something between public and private. Particularly subsets and view.

I 2nd, 3rd and 4th this. It is something I hear from users all the time. We have developed TI's to pick up private subsets and views and copy them to nominated users or members of nominated groups by executing batch files but this is rather clumsy compared to a better security concept for views and subsets.

The ability to run a chore within an action button, rather than just run a TI.

Steve Vincent wrote:The ability to run a chore within an action button, rather than just run a TI.

I'm not trying to be contrary, but with ExecuteProcess why does that matter any more? (I'm sure it's something that IBM would say.) ExecuteProcess has the same ability to share global variables as a chore does; granted there's no equivalent to ChoreQuit though that can be worked around via a control cube (actually I think I just answered my own question; I'd assume that that's why you'd want it), but also... if that were to be implemented I think that they'd need to sort out the different behaviour between Processes and Chores with regard to parameters in conjunction with that.

Not saying it's the only way to do it, but i always understood that executing a TI from another TI was not as efficient as running them via chores. Admittedly, i use both methods but where a chore does other stuff like run replication it would be nice to be able to use the action buttons for that as well. Some of my chores are scheduled but do get run ad-hoc too, which is the main reason it would have been handy to me at least.

Right now action buttons are pretty limited, with a bit of thought IBM could make a lot more from them

Constraints similar to RDBs definable for Dimension or Starting Hierarchy within Dimension

1. Elements appear no more than once ( prevents double counting)
2. Weighting is always 1
3. Maximum Depth limit
4. Orphaned N level elements not allowed.
5. All inclusive hierarchies to which all elements must belong

I am sure more come to mind.