TM1 Forum

Ajay

So far this thread has all been about replication, however, you originally asked about Citrix, as well.

We had problems with slow and unpredictable response from users in Italy accessing a TM1 server in London via the TM1 Client.

From memory, our network latency was only 100 - much faster than the 250 that Cognos quote. However, we were still having problems.

TM1 Web was not an option as many of our reports have extensive macros.

TM1 Web, like Replication has its own set of problems.

Rather than use Citrix we used Terminal Services. This has cured the latency issue. Access in Italy is still on average a little slower than access from London, but only in the order of 10%. Previously performance ranged from 20% slower to 1000% slower.

There have been a few user interface issues, with Terminal Services, which I did not encounter before when using Citrix, eg Windows opening behind other Windows instead of on top. However, these are minor glitches. I am not sure how the costs compare with Citrix. The cost of a CAL for Terminal Services is around £70 per user, which is cheaper than TM1 Web.

Obviously you need another server for the Terminal Services, however, you would need that for TM1 Web, and if you are doing a full replication of all data, then, with replication each local server is going to need a similar spec to your main server, which would get expensive.

With a local server you can only have one user, whereas with Terminal Services or TM1 Web, you can have many. I am sure that some of your remote branches will need more than one user.

You also need to check on the number of local server licenses that you have. I haven't looked at any prices lately but I think they were around £2800 + £500 Maint which is a lot more a Terminal Services Client, if you don't already have them.

If you look at TCO Total Cost of Ownership, a TS solution also gives you benefits in that you only need to install/upgrade the TM1 Client once. By comparison carrying out a coordinated upgrade to a new version in multiple remote locations can be a lot more tricky and costly. So long as your client PCs are on Win XP Pro SP3 then the necessary TS Client is part of the operating system. If you are on an earlier SP, it can be installed separately. TM1 Web also avoid some of the deployment costs of Replication. However, that can be offset by the cost of the TM1 Web license, Server, and the cost of the additional work to design reports specifically for TM1 Web deployment.

Our IT Dept configured TS so that Excel with TM1 starts as a TS application. It therefore starts just like normal Excel. They only need to login to the remote server the first time. There is no need to manage a separate session. However, that approach has advantages if you are deploying more than one application.

A downside of a TS or TM1 Web solution is that you do need a reliable connection. I do remember a client that only had a network connection available for a few hours a night, and nothing during the day. For them a nightly replication was a better solution. Note that when I say replication I mean just that. They broke the replication connection and re-created it every night, thereby ensuring a full copy of the cubes, rather than a synchronisation from the logs.

If you do go for synchronisation alone, I would recommend, a follow up email/file synchronisation containing check total figures for reconciliation.

Regards


Paul Simon

PaulSimon wrote:The cost of a CAL for Terminal Services is around £70 per user, which is cheaper than TM1 Web ... Obviously you need another server for the Terminal Services, however, you would need that for TM1 Web

Hi Paul,

Depends on when TM1 was purchased, for the last few versions TM1 Web has been bundled so no additional cost on top of TM1 application server. Also as far as hardware goes no need to host TM1 Web on a separate server unless the app server is already strained for capacity.

Hi Lotsaram.

It's true to say that TM1 Web is now bundled, but, that just added £10k to the prices. A lot of clients bought their licenses before then and don't a web license. We still have our much cherished concurrent user licenses, and we are not giving them up for named user licenses without a fight, or at least a much more realistic conversion factor. We don't have a license for TM1 Web or Executive Viewer.

You can run TM1 Web on the same server, which is probably OK on a big 64 bit box. However, there are also issues around firewalls to consider, and IT Depts tend to have fixed ideas about what should and should not be outside the firewall so you may need to separate the boxes for that.

Personally for Web Deployment I was much more impressed by a demo I say of a tool called Cockpit, which is an MDX based application building tool for TM1. I tend to find that when you start building applications to be deployed around the world then having something a little better than the Excel Event model is a good idea.

Regards


Paul Simon

lotsaram wrote:

PaulSimon wrote:The cost of a CAL for Terminal Services is around £70 per user, which is cheaper than TM1 Web ... Obviously you need another server for the Terminal Services, however, you would need that for TM1 Web

Hi Paul,

Depends on when TM1 was purchased, for the last few versions TM1 Web has been bundled so no additional cost on top of TM1 application server. Also as far as hardware goes no need to host TM1 Web on a separate server unless the app server is already strained for capacity.

Paul, would you like to incite the Cockpit people to post some information in the Commercial subsection?

Back on the replication issue, today i have been so close to nailing it yet a small part still defies me.

The set-up is i have (currently) 3 services to work with. My STAR is on server A. Next in line (we'll call it the PLANET) is on server B. Last in the chain is MOON, which is also running on server B. I am replicating from STAR to PLANET a bunch of element attribute cubes, along with their respective dims, rules, views and subsets. All of that works perfectly, including copying changes in 3 "normal" cubes that are also part of the replication. These cubes copy data but NOTHING else, the reason for this is a couple of dim structures need to be different in PLANET to those in STAR, and these are in turn passed to MOON. There will eventually be several MOONS, so this method i see as being the easier to manage in the future.

So the whole first part works 100%. I save data on STAR, run the replication and job done. The next step is to replicate from PLANET to MOON, again copying the element attribute cubes (and all that comes with them) along with the 3 data cubes, although using the amended structures. This is where it falls over yet i cannot fathom why. If i replicate one cube on its own its fine. No error messages after running it, all the logs say it completed successfully. One dimension in particular tho will never sync, if it is done on its own or as part of the full sync it always fails, the biggest problem being that the full sync will abort on the error, so nothing else (such as the data cubes) will get copied. Server Explorer gives you no error at all, but checking the logs shows the most utterly helpful line "Dimension Update Failed". Thats it tho, no reason, not even the slightest whiff of a hint as to why.

Both PLANET and MOON have server B as the admin host.
PLANET had save data run before the sync.
All the other dims when run manually sync fine with no errors.
There are no rules against the element attribute cube.
There are no aliases on the dim.
There are no user locks on the dim.
I have bigger dims that sync successfully so size should not be an issue.

I'm at a loss as to why this one dim will not sync, especially as it works fine from STAR to PLANET. If anyone has any ideas as to what else to check i'd be very grateful as i've just about exhausted mine

tried various other things today and eventually, by pure chance, i found out the issue.

My last restort was to down the server and copy a "good" version of the dim it was stopping on in case the file was corrupt. Sever wouldn't allow me to do that, gave me the windows error that usually means no security or read/write lock on the file. Rebooted the whole machine and still got that error, so went hunting in the event logs to see why the server was being a pig.

i found entries in the application logs that tied in with the times i ran the failed replication tasks. TM1 only reports to the user (via its own logs, not user messages) that it failed and at which part of the replication, in this case the "work breakdown" dim rebuild. Thats not all TM1 does tho, it also passes extra information to windows which it logs via the event logs. If you don't have admin access to your windows server, you'll never be able to get at this crucial piece of info.

In my case it said it couldn't update the dim because if it did a rule would not complie. The rule was using a reference to an alias that did exist in the MOON but is being replaced by the STAR. If you try to update a dim via XDIs and there is an alias clash or something a rule relies on is missing, the TM1 user interface will tell you exactly what the issue is and not update it. Its doing the same with replications but with the key info you need to resolve it missing.

So, if a replication does not work and you don't know why, cut out the middle man and check the event logs on the server. it'll probably save you an awful lot of messing around. I will test the same issue in 9.4 when i get chance to see if that improved, but chances are not.

Deep Joy Not for the first time the admin guide supplied by Applix/Cognos is a crock of doo doo.

The guide states that you can set up a replication by chaining servers together (page 137 of the 9.0 guide). This is not true and frankly a pain in the rear.

Replication relies upon log files to work. If you load data from a text file and don't log it, replication will not pick up those changes. On top of that, if you did log the changes but had the servers in a chain like their diagram, the middle server which does the first replication will not create a log so the next one in the chain picks nothing up.

It means that unless you are replicating cubes that are logged (including any data loaded via TI) AND you have a star / planets setup rather than a chain, replication is some what useless

Replication relies upon log files to work.

And the default code entered by the TI wizard if you try to automate a quick data load is to turn logging off

(NB TI Wizard is spawn of the devil)

You learn about THAT one by painful experience !