Page 1 of 1

Environment Migration

Posted: Wed Feb 02, 2011 11:03 pm
by tomok
Hi All, I'm looking for ideas concerning migrating TM1 models between DEV, QA and PROD. I have a good understanding of the contents of the data folder, as well as the TM1Web folders and know what can be found in there. I have tried two different approaches to migrations and they both come up lacking. For discussion purposes let's say I have three TM1 services called DEV, QA and PROD and they are all on separate machines:

1. Copy the contents of the data folder from QA to PROD and recycyle PROD service. Works great except all my reports have the word "QA" in them so I have to open each report, rename "QA" to "PROD", and update.
2. Give QA and PROD services the same name. Then when I copy the data folder over reports don't have to be republished. Problem is now I can't be logged into both QA and PROD at the same time (to do validation) because both services have the same name.

Does anyone have any ideas or workarounds to solve these problems?

Re: Environment Migration

Posted: Thu Feb 03, 2011 2:10 am
by blackhawk
What you could do is create in each report three formulas:

A1: =TM1User("Prod")
A2: =TM1User("Dev")
A3: =TM1User("QA")

Then in in A4, just put an if statement like this:

A4: =IF( A1 <> "", "Prod:", IF( A2 <> "", "Dev:", IF( A3 <> "", "QA:", "" )))
A5: ="Financials"

Then in all your other report fomulas, just use something like:

=DBRW( $A$4 + $A$5, B1, B2, ... );

Now, whatever server you are logged into, will show up properly in the report!

Re: Environment Migration

Posted: Thu Feb 03, 2011 2:25 am
by Martin Ryan
My own way of handling it would be your first option (I like Blackhawk's idea though). Provided you don't have that many reports it's not too difficult to update it all and you can always write a VBA routine that opens up all the reports and makes the necessary changes (I think someone on the forum has this code, perhaps they might be able to share). Then the only slow part is adding them to the applications folder.

I don't like option 2, there's two much chance of someone stuffing up a live system by mistake.

Can't think of an option three either. I've always thought TM1 handles module promotion poorly. Cubewise's hot promote tool goes someway to addressing this, though I don't think it helps with your reports.

Martin

Re: Environment Migration

Posted: Thu Feb 03, 2011 2:49 am
by blackhawk
I should probably mention that you may want to put the IF statement in order of precedence in the event that you are connected to more than one server. As a developer, I would suggest DEV, QA and then PROD, so you don't accidently change something in prod :shock:

As a user who has access to these other environments, the order may be different; so take that into consideration when you put them into your reports.


Good luck!

Re: Environment Migration

Posted: Thu Feb 03, 2011 10:11 am
by dubs
tomok wrote:Hi All, I'm looking for ideas concerning migrating TM1 models between DEV, QA and PROD. I have a good understanding of the contents of the data folder, as well as the TM1Web folders and know what can be found in there. I have tried two different approaches to migrations and they both come up lacking. For discussion purposes let's say I have three TM1 services called DEV, QA and PROD and they are all on separate machines:

1. Copy the contents of the data folder from QA to PROD and recycyle PROD service. Works great except all my reports have the word "QA" in them so I have to open each report, rename "QA" to "PROD", and update.
2. Give QA and PROD services the same name. Then when I copy the data folder over reports don't have to be republished. Problem is now I can't be logged into both QA and PROD at the same time (to do validation) because both services have the same name.

Does anyone have any ideas or workarounds to solve these problems?
I had to write a bit of VBA to go through my reports and update the server name references, in terms of internal TM1 stuff I put all my references in a cube but for the reports the only way I could do this was to use VBA.

As you are using TM1Web I have no idea how you would do this so think the second option is probably best - I thought you said you had these environments on different machines - do you have separate web services running for each? if so surely it would be a case of connecting to PROD on the dev server IP and connecting to PROD on the prod server IP using different browser sessions? I do tend to agree with blackhawk that its better to have unique names so you know where you are but know many would suggest keeping the names the same.

Re: Environment Migration

Posted: Mon Feb 07, 2011 1:31 pm
by Steve Vincent
blackhawk wrote:What you could do is create in each report three formulas:

A1: =TM1User("Prod")
A2: =TM1User("Dev")
A3: =TM1User("QA")

Then in in A4, just put an if statement like this:

A4: =IF( A1 <> "", "Prod:", IF( A2 <> "", "Dev:", IF( A3 <> "", "QA:", "" )))
A5: ="Financials"

Then in all your other report fomulas, just use something like:

=DBRW( $A$4 + $A$5, B1, B2, ... );

Now, whatever server you are logged into, will show up properly in the report!
I like that solution but it doesn't cover everything. Where DIMIX, SUBNM, ELPAR etc are concerned you'll get varying results with that route. My main bug bare is that SUBNM looses its double click functionality when the dimension reference is a cell value and not hard coded. For that reason alone i stick with the good old find a replace. Shame...

Re: Environment Migration

Posted: Mon Feb 07, 2011 5:42 pm
by Alan Kirk
Steve Vincent wrote:
blackhawk wrote:What you could do is create in each report three formulas:

A1: =TM1User("Prod")
A2: =TM1User("Dev")
A3: =TM1User("QA")

Then in in A4, just put an if statement like this:

A4: =IF( A1 <> "", "Prod:", IF( A2 <> "", "Dev:", IF( A3 <> "", "QA:", "" )))
A5: ="Financials"

Then in all your other report fomulas, just use something like:

=DBRW( $A$4 + $A$5, B1, B2, ... );

Now, whatever server you are logged into, will show up properly in the report!
I like that solution but it doesn't cover everything. Where DIMIX, SUBNM, ELPAR etc are concerned you'll get varying results with that route. My main bug bare is that SUBNM looses its double click functionality when the dimension reference is a cell value and not hard coded. For that reason alone i stick with the good old find a replace. Shame...
In your version. This changed in 9.4 remember. In fact, it's a FAQ. ;) (Under the heading "Functionality of SubNm, including change in 9.4.1" in the User Interface section.)

Re: Environment Migration

Posted: Tue Feb 08, 2011 12:54 pm
by Steve Vincent
Now why would i read a FAQ on a version that i *still* can't this place to upgrade to? :lol:

[thanks Alan]

Re: Environment Migration

Posted: Wed Jul 06, 2011 6:32 am
by ub14
Hi,

We have similar issue, need to migrate set of .pro files to qa/uat/prod. In TI Process , we are using ODBC Data source, providing usrid/pwd for dev enviornment. but when we migrate to different environment ,the usrid/pwd may be different, so everytime we need to modify this manually. Is there any we can automate the usid/pws udpation process based on some scripts ?

Thanks in advance
vsub

Re: Environment Migration

Posted: Wed Jul 06, 2011 7:34 am
by moby91
ub14 wrote:Is there any we can automate the usid/pws udpation process based on some scripts ?
What about using the TI Local Variables DatasourceUsername and DatasourcePassword ?


See the manual TM1 9.5.2 Reference Guide ->

http://publib.boulder.ibm.com/infocente ... ceusername
TM1 9.5.2 Reference
TM1 TurboIntegrator Variables > TurboIntegrator Local Variables >
DatasourceUsername

http://publib.boulder.ibm.com/infocente ... cepassword
TM1 9.5.2 Reference
TM1 TurboIntegrator Variables > TurboIntegrator Local Variables >
DatasourcePassword


See the thread ->

http://www.tm1forum.com/viewtopic.php?f=3&t=3020
datasource username and password

Re: Environment Migration

Posted: Wed Jul 06, 2011 1:20 pm
by ub14
where can i set the local variables DatasourceUserName and DatasourcePassword dynamically for ODBC Datasource. These local variables are temporary and will be deleted after every process run (Local variables exist only in the context of the process in which they are used, and are not available outside of the process. Local variables are destroyed when a process exits).

Re: Environment Migration

Posted: Wed Jul 06, 2011 2:13 pm
by qml
Each of your 3 server instances could have a "system parameters" cube that would store all the file paths, connection passwords and what not. Then your TIs could pull this data from the cube and use the mentioned TI local variables to change/set connection params to those that would be right for the given server.

Re: Environment Migration

Posted: Wed Jul 06, 2011 5:38 pm
by jstrygner
The name of the ODBC connection - I agree that the best way is to put it in a cube (or attribute that in fact also is a cube).

I once had an issue, when TM1 administrators were not supposed to see user id and password for the ODBC (if you'd store those in TM1, they would).

It was a windows, so in this case we used regedit and stored password and ID in here (attachment) and in TI you left user id and password blank.

Re: Environment Migration

Posted: Tue Jul 12, 2011 9:42 am
by ub14
Hi,

We are trying to call set of TI Process through master TI Process by passing DataSource,userid and Password as parameters. with below prolog statment in master ti and calling the child TI Process.

master TI Prolog statment:
=========================
ExecuteProcess(processName,'PDataSource',DataSourceNameForServer,'PUserName',DataSourceUsername,'Ppassword',DataSourcePassword);

Child TI Prolog statements
======================
DataSourceNameForServer=PDataSource;
DataSourceUsername=PUserName;
DataSourcePassword=Ppassword;

The Process is failing with unable to open DataSource error everytime, but when we go and update password odbc dsn in registry, the process working fine.

We would like to know is there any way we can avoid this since we can't frequently update the password change in other environments (lke Production).