Copy a dimension from one server to another server nightly using TI Code

[manu0521]

Hi All,

I have a manual dimension in my server 1 and this will be updated when requested.

Now server 2 uses the same dimension and I would like to write a TI process which would run nightly so that it copies the manual dimension from server 1 and puts it in Server 2.

I need the some help to write the TI code which would do this.

I think I have to export the dimension to a flat file and then read it and create elements.

Any suggestions is appreciated.

Thanks,

[Elessar]

I think using replication is better. Replicate the }Elementattributes cube to copy attributes too

[TrevorGoss]

I need the some help to write the TI code which would do this.

Try using the ExecuteCommand function and run a command line argument to copy or move the flat file from one directory to another

Code: Select all

## Double quotes for spaces in command
vQuote = CHAR(34);

sCmd = 'cmd /c copy z:\Folder1\' | vQuote | 'file.dim' | vQuote | 'z:\Folder2\';

ExecuteCommand(sCmd,0);

the vQuote variable is to add double quotes to the string, in case you have spaces in your argument.

I think using replication is better. Replicate the }Elementattributes cube to copy attributes too

That may well be, the TI could be used to run via a chore.

Thanks.

[manu0521]

If I am using a TI Process to copy a dimension from one server to other server,where should I write the TI process? Should it be in the destination server ?
The below code says to execute in command prompt.
Please provide suggestions or samples fro copying dimension via TI Process.

Thanks,

[manu0521]

Can anyone let me know the TI code to copy a dimension from one server to another

[Alan Kirk]

Can anyone let me know the TI code to copy a dimension from one server to another

While we're here to give a hand up, we're not really in the "Do You Haz Teh Codez" business around here.

You've already been given some starting points.Trevor Goss' suggestion of copying the .dim file will work (though you would need to copy the attributes cube and dim as well to get the whole thing) and it only really works if you reboot the second server. (Trevor's code suggested copying the "flat file" and his code showed how to do that with a .dim file, but .dim files aren't actually flat files, they're binaries which are read at server startup. You would need to have exported the dimension structure to a flat file first; see below.)

There are third party tools that allow hot promotion of dimensions between servers, but I'll assume that you don't have any of those.

If you want to bring across the entire dimension with attributes, Replication, not TI, is the theoretical way to do it as noted above. I say "theoretical" because I used to use it for exactly that purpose, then stopped when I started getting people ringing up and saying that the names on server 2 weren't updating despite the replication running and there being no error log. So I dug into the replication log and found, oh lookie, "Some unspecified error that I can't be bothered telling you about occurred so I'm just going to stop mid stream for no apparent reason." So I deleted and recreated the replication, and it worked again for a while. Then it started doing the same thing again.

Since then I have not trusted replication for anything.

So the remaining option is for you to write a TI process on the source server to export the dimension to a text file, then another TI process on the target server to reimport it.

However Bedrock already has processes which contain the core code to do the export ( Bedrock.Dim.Export ) on the source server and the reimport on the target server ( Bedrock.Dim.Import ).You have to write the code to call those processes, but the documentation covers how to do that.

[TrevorGoss]

You've already been given some starting points. Trevor Goss' suggestion of copying the .dim file will work (though you would need to copy the attributes cube and dim as well to get the whole thing) and it only really works if you reboot the second server. (Trevor's code suggested copying the "flat file" and his code showed how to do that with a .dim file, but .dim files aren't actually flat files, they're binaries which are read at server startup. You would need to have exported the dimension structure to a flat file first; see below.)

This is true, the TI would have to get all the attribute files as well as anything else it depends on, this could cause the TI to become messy.

Can anyone let me know the TI code to copy a dimension from one server to another

I note you are on 9.5, if you ever upgrade to 10.2 you will get Performance Modeler which has a transfer tool. This tool does not require any downtime and will automatically select all the dependant objects that relate to the original object you select.

[Alan Kirk]

I note you are on 9.5, if you ever upgrade to 10.2 you will get Performance Modeler which has a transfer tool. This tool does not require any downtime and will automatically select all the dependant objects that relate to the original object you select.

Ah yes, good point; I'd memory-suppressed that particular nightmare.

Is anyone using that operationally? I recall that my initial tests of it "did not end well", but I can't recall the specifics.

[TrevorGoss]

Ah yes, good point; I'd memory-suppressed that particular nightmare.

I can understand why you suppress those memories, I do the same.

Is anyone using that operationally? I recall that my initial tests of it "did not end well", but I can't recall the specifics.

We use it when we want to bring across one Web Application from UAT to production.

We once tried to bring across one TI from UAT to production and it crashed, which is embarrassing, and ever since then we have been hesitant in using it for anything other than application transferring.

[pandinus]

Is anyone using that operationally? I recall that my initial tests of it "did not end well", but I can't recall the specifics.

We use it from time to time to move stuff over from development to accept, or from accept to production.
Main advantage is that no restart of the target instance is required. This also seems to be the only correct way to transfer TM1 Applications without breaking things and getting inexplicable error messages.
Main disadvantage is that you have to be extremely careful with which objects to transfer. But then again, you have to do the same when transferring the old-fashioned file-based way.

[Andrew_M]

Another option is to use ODBO connection to a source server via TI process. In this case TI process can be configured through a wizard ( server name , user name, dimension name, etc. ) and there is no need to write a code in tabs if you don't need any additional/specific logic or you are not familiar with a programming in TI.
But I remember one major restriction here is that both servers should be on the common Adminhost.

[gtonkin]

This seems like a good opportunity to use TM1RunTI
You would probably need to do most of what has been suggested above i.e.

• Create a TI on the source model/server to export the dimension - remember to export, principal, parents, attributes etc. that you would need later
• Use TI to copy the file to the other server
• Use TI execute the TM1RunTI command with the relevant parameters or create a batch file to do this step and the one above
• On the target model/server, create you TI which will update the dimension based on the exported file

Check out the required parameters for TM1RunTI as you will need to supply credentials etc.