TM1 Forum

Hello Everyone, what are the various ways that one can move data between two or more different TM1 models or across TM1 servers? For instance, assume that one TM1 server is a detailed revenue model and another is your overheads model. How would you move these across TM1 servers to roll into a PL model? Are there any restrictions? Or would you typically have everything on one TM1 server? Thanks!

You can use TM1 Replication to move data between different TM1 servers.

You can also move data from one cube to another cube within the same TM1 server using TI Processes and/or TM1 Rules.

JJ2 wrote:Hello Everyone, what are the various ways that one can move data between two or more different TM1 models or across TM1 servers? For instance, assume that one TM1 server is a detailed revenue model and another is your overheads model. How would you move these across TM1 servers to roll into a PL model? Are there any restrictions? Or would you typically have everything on one TM1 server? Thanks!

Firstly it would be a very VERY strange design decision to have a revenue model and an overhead model on distinct servers and then merge the input models into am integrated GL model on a 3rd server.

It would be a much simpler design (and simpler is almost always better!) to have a single server and do away with the needless replication or file moves. On a sever running a recent version of TM1 you can have each population of users work on distinct cubes without impacting performance on the other group and take advantage of only maintaining common meta data once. From a security perspective each group need not even be aware of the existence of the other set of cubes.

I don't entirely agree that dividing a TM1 app across servers is always a bad idea. Admittedly most of our clients are on 9.0, which strengthens the case for partitioning, but as you will recall from the Waltham Black Belt sessions, even with the new, improved, super whizzo locking model there are a number of situations where users of a server can be locked out by something else going on eg dynamic subset computation, savedataall, rule saves etc. Partitioning into multiple servers avoids all this.

To respond to the original question, the best way to move data between servers is via flat files. You should have the same cubes and dimensions in each server, and have an unmodelled slice in your destination into which you read the data. We also have a module which aligns dimensions between servers. This uses SQL server as the volume transferred is smaller.

I did pitch to Manny and Arthur Lee the case for extending TI to read a view/subset from a different TM1 server. Manny's take was that it was a very specialist requirement. I tried, anyway

Hi David,

To be fair I didn't say that dividing a TM1 app across servers is always a bad idea. I said that keeping a design as simple as possible is almost always the best option. Quite distinct and different opinions.

One of the most powerful feature of TM1 is that you can have an integrated planning model. Integrated in terms of revenue, opex, wages, etc. all in the one model and integrated in terms of one report interface for actual, budget and forecast. If everything is on one server then this allows for real time consolidation, reporting and scenario analysis. Break the model apart and you also break the real time aspect as well as creating a data integration and meta data synchronisation problem that you didn't previously have. Yes in some instances you might need to do it for performance or security reasons but those are the exceptions not the norm.

I often find that people who have come from other development backgrounds often want to split out meta data (such as having unique time, version, etc. dimensions for each and every cube on a server) and also split servers between distinct user groups seemingly for the sake of it. This creates a large amount of additional maintenance overhead and to my mind misses the point of good optimised TM1 design.

Thanks for your replies lotsaram and David. I come from an EP background and am transitioning to TM1 and just wanted to get an idea of what the different options are for moving data between TM1 servers. Both of you have giving me some welcomed ideas on this which I greatly appreciate. From an EP stand point, model size can sometimes be an issue and a typical solution could be to break the model out into smaller components - moving data between these smaller components is a very simple process in EP. It seems that TM1 can handle large models a lot more efficiently and so this may not needed. However, I was still interested to see the alternatives to move data between TM1 servers out of curiosity. Again, thank you both for your input!

Hello evebody!

I have a problem with a similar process.
I need "make a replication" (make a cube copy) from Server A to server B, then I create a replication and in a first time the replication is ok.
Now when I update the cube in Server A and create a Chores for run this replication the Server B don't update!
Is the replication the best option for this operation? if yes, why don't work?
Can someone help me?

andreborges wrote: I have a problem with a similar process.
I need "make a replication" (make a cube copy) from Server A to server B, then I create a replication and in a first time the replication is ok.
Now when I update the cube in Server A and create a Chores for run this replication the Server B don't update!
Is the replication the best option for this operation? if yes, why don't work?
Can someone help me?

Replication is... how can I put this diplomatically... "a less than robust component of the overall TM1 application". I use it, but only to replicate dimensions via their attribute cubes and even then it's useless at replicating subsets. I'd be wary of using it to replicate an actual data cube, though some people do that and it works (kinda-sorta-mostly) for them.

When a replication chore runs it creates a replication log file. More than once I've been unaware of the replication having failed until someone pointed out the some of the changes in the aforementioned dimensions didn't show up on the planet server. Take a look at the replication log and see whether it errored out.

Also make sure that you provided a login and password to the star server (the one that you're replicating from) which has access to the cube and all of the dimensions that you're trying to replicate.

Also bear in mind that replication of data is done via entries in the log files and their date/time stamps. Make sure that you don't have logging turned off for the cubes in question. If your initial updates have been done via TI it's likely they have not been captured in a log anywhere.

Alan Kirk wrote:

andreborges wrote: I have a problem with a similar process.
I need "make a replication" (make a cube copy) from Server A to server B, then I create a replication and in a first time the replication is ok.
Now when I update the cube in Server A and create a Chores for run this replication the Server B don't update!
Is the replication the best option for this operation? if yes, why don't work?
Can someone help me?

Replication is... how can I put this diplomatically... "a less than robust component of the overall TM1 application". I use it, but only to replicate dimensions via their attribute cubes and even then it's useless at replicating subsets. I'd be wary of using it to replicate an actual data cube, though some people do that and it works (kinda-sorta-mostly) for them.

When a replication chore runs it creates a replication log file. More than once I've been unaware of the replication having failed until someone pointed out the some of the changes in the aforementioned dimensions didn't show up on the planet server. Take a look at the replication log and see whether it errored out.

Also make sure that you provided a login and password to the star server (the one that you're replicating from) which has access to the cube and all of the dimensions that you're trying to replicate.

Yes I agree. I tried to use it but also not had a great success. For me, the best pratice is make a export process (save the cube in a txt file and read the txt file - function TextOutput).