If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Migrate FM Model/Package from one envi to another

Started by Bindiya, 06 Apr 2014 08:53:18 AM

Previous topic - Next topic

Bindiya

Hi,
We have datasource with same name ("COGNOS_VIEWS") in DEV, TEST and PROD. Now, it points to schemas "DB_V_DEV", "DB_V_TEST" and "DB_V_PROD" in 3 environments respectively.
Questions..
1. We have developed a model in DEV and the datasource points to DB_V_DEV schema in properties and published the package. Now, will it appropriately point to TEST schema if the package is migrated (deployed) to TEST?
2. If it doesn't automatically points to TEST schema, then will it work if no schema name is specified in properties against datasource during development? or should the model be copied to TEST , change the schema name to DB_V_TEST and then re-publish?
3. To republish package in TEST, we open Cognos configuration, change the Gateway and dispatcher URIs to point to TEST environment and then change the datasource to point to TEST schema in FM model and publish package in TEST. Is this correct process. Is there any way to avoid changing URIs in configuration?

Have gone through some discussions and found mixed comments.
Below say the package has to be republished if schema names are not same across environments..
http://www.cognoise.com/index.php/topic,10885.msg35665.html#msg35665
http://www.cognoise.com/index.php/topic,2413.msg9103.html#msg9103

Below say republishing is not required..
http://www.cognoise.com/index.php/topic,3239.msg11819.html#msg11819

I am very eager to get this clarified. Any suggestions would really be appreciated.

Thanks.

msn

1. It will point to the appropriate schema in TEST/PROD as long as the datasource connection name (defined in Cognos Administration) remains the same between the environments.

2. If the schemas are in Oracle database, you need not mention the Schema name in the Framework Manager Datasource properties. For SQL Server database it will be different. Copying the model to different environments is not a recommended approach. Deploying using the deployment package is the best method.

Hope this helps!

Bindiya

Yes. It helps. Thank you. Probably we need to try and see if it works fine.

Bindiya

One more question. I am just trying to understand how things work internally.
Now say I have imported a table (AGE) from "DB_DEV" schema via "COGNOS_VIEWS" data source. Say, I change the datasource name to "Hello". Now for the datasource "Hello" in the properties, the content manager datasource would still be "COGNOS_VIEWS" and schema would be "DB_DEV".

The query definition would  say some thing like "Select * from [Hello].AGE".
Now at run time it expands the "Hello" datasource to <content manager datasource value>.<schema value> it is correct? Which results in select * from COGNOS_VIEWS..DB_DEV.AGE".

Now, when such a package is deployed to TEST/QA, then what all will be carried with package?
Only datasource name? if so, then I am assuming that it would throw error in TEST saying "Hello" not found. 
If datasource name and content manager datasource value both are passed, then it would identify "Hello" then try to find the associated content manager datasource which is "COGNOS_VIEWS " and would fetch the appropriate TEST schema.

Please let me know.

Bindiya

We got this sorted out  :) . Here is what we tried and the working results.
1. Without removing the schema names, if FM package is deployed to other environments, then it was still pointing to old environment schemas.
2. After developing the model, we deleted the schema names and then deployed the package to other environments. This worked and all the tables rightly pointed to new environment. Only thing important here is the tables need to be pulled from a data source whose default schema is where the table resides in. I.e. Say a table AUTO resides in DB_AUTO_DEV schema and this is the default schema for COGNOS_AUTO_VIEWS data source, then AUTO table  should be pulled into FM from COGNOS_AUTO_VIEWS data source only. Say if you have another data source COGNOS_ABC_VIEWS whose default schema is DB_ABC_DEV, then, this datasource could not be used to pull AUTO table because if you pull so, then once the schema name is deleted, the AUTO query subject would not get validated.
3. This is how it works. After the schema name is deleted from a data source, then the table would be looked for only in the default schema alone. If it is not found there, the query subject would get invalidated.
4. Now, if you want to pull a table from a schema for which there is no datasource created e.g. HOME table resides in DB_HOME_DEV schema and since there is no datasource for it we import it from say COGNOS_ABC_VIEWS datasource. Now, HOME table will get validated only if schema name is explicitly defined (in this case it would be COGNOS_ABC_VIEWS datasource and DB_HOME_DEV schema). But once the schema name is deleted, this query subject would not get validated because it would look for HOME in COGNOS_ABC_VIEWS default schema which is DB_ABC_DEV not DB_HOME_DEV. This could be handled by using Parameter map macros as schema. Here there will be no hardcoding and the schema name gets passed at run time.