Moving from one environment to another

[Arsenal]

Hi all,

Since Cognoise doesn't have a separate admin forum, I thought I wuld ask in here.

A question was thrown out to me today, and since I've 0 admin experience, I thought I would ask it here. Basically, we have 4 environments(dev, dev c, ut and prod), and they are setting up the dev c environment for cognos 8 to replicate the present c8 dev environment.

The question is, how can we, using the present single model we have ( we'll call the model xyz and it has 3 namespaces and different query subjects of course) ensure that when in dev c, users can continue testing, yet developers can continue working on the same model in dev environment...the database name is slightly different with the same table structure.

I didn't nderstand their entire environment settings because the present cognos admin didn't quite explain it clearly. In the past, i guess, they stopped development in dev while testing went on in dev c, and then worked in dev only after dev c was done testing because they manually changed the datasource to point to the dev c environment for the package each time..or some such

any comments, suggestions etc.?

[Arsenal]

Hmmm

I'm thinking if it's perhaps possible to create a new data source connection in cognos connection that points to the dev c database name, then open up the .cpf file in FM, change the datasource connection to use the newly constructed one, create a differently named package, publish the package and then close the .cpf file without saving the changes

this way, we have 2 different packages with 2 different data source connections with nothing stopping us from developing on one package in dev, while testing the same package, with a different name, in dev c

but somehow, this seems to be deceptively simple....i'm having doubts about this method even as I type it out!

[Arsenal]

Hmm, having debated this problem last night, I 'm beginning to think that perhaps they want to have dev and dev c on the same box...i'll clarify this on monday

but suppose the above was true....would the deployment option, wherein we zip the content store, in cognos connection hold good?
if not, would there be another option besides either stopping developing in dev during dev c testing or having tow separate models?

[COGNOiSe administrator]

The best practice would be to have 4 separate instances of Cognos 8. Then your connections within the model stay the same and users can test it without any interference from developers.

[Arsenal]

Cognoise, thanks for your reply.

I see what you're saying. To avoid confusion, let's just say that we want 2 environments on the same box. Let's say that one environment has ABC as the database name, and the other has DEF as the database name with the same table names, schema etc. as ABC.

For reports to use data from DEF, the connection will need to be updated to reflect DEF. At this point, if we were to use the same model to author a new report in our environment, we won't be able to do so. At this point is when the entire issue arises as to if we can have multiple data source connections for the same package, or development will stop in one environment while testing goes on in the other, or if we need to make a duplicate of the present model for independent testing

I apologize if your comment was meant to address the above 3 questions, but I guess I'm not seeing it that way.

[COGNOiSe administrator]

In this case, try creating two database connections, with two sign-ons, for one data source. Then, using secuirty, deny access accordingly to each group requirements.

[Arsenal]

Cognoise,

yes, that's the impression I was getting after doing some searching. I think I had my terminology between data soure connection and database connection messed up.

So, as I understand it, in the currently published model, the admin will need to go into cognos connection>directory?>Tools>datasourceconnection, then edit the connection to include 2 database connections and 2 sign-on's? Or is there something missing i what I've said?

Sorry, but admin access and directory permission within cognos connection is not something I've enjoyed frequently :o

[Darek]

Yes, that's exactly what I'd attempt to do. You need to make sure that no user would have to choose between those two data connections. I've never tried it myself, but to quote Priest Cornelius, "Theoretically, ..." it should work.

[MFGF]

It will definitely work, yes.  Just watch out for metadata caching if you try to access both database connections using the same userid.  If this is an issue, it may be useful to temporarily change the governor settings in Framework manager to enable the 'Enhance Model Portability at runtime' setting, which will prevent metadata caching from happening.  Once testing is complete, you could then disable this setting and republish your packages to improve efficiency.

Best regards,

MF.

[Arsenal]

Well, with the heavyweights here stamping their approval, I guess it's pretty safe to try the method

I was just thinkng (I know...bear with me anyway :-\), that it stands to reason that if a published package can be manipulated to have have multiple database connections, it can also be manipulated to have it's connection string changed to reflect the other database...this goes back to my earlier post on this thread

In a nutshell, publish a second copy of the package(with name changed), then via Cognos Connection, change it's connection string to point to the new database

[COGNOiSe administrator]

Not as easy or convenient in my opinion, yet doable, with some extra work.

And please, don't call me heavy ... I am so trying to loose some weight ...  ;D

[Arsenal]

Have an update....believe that they are going to be sharing the content store between the two environments on that box

the present "admin" was not sure if the multiple database connections solves our problem but he didn't specify his reasons for thinking so.

i guess i'll have a clearer picture when the actual admin gets back on Thursday

wish i had directory persmission...would save me irritating email tag games ::)

[Arsenal]

Cognoise wins ;D

We will try the multiple database method

they have made a new databse connection string that has connection to the two databases, and the model will be changed to reflect this new database before testing...after testing is done, we'll rechange the model back to the dev database


Only trouble is, developers are the one's who will also test in dev c..sucks

so for the 4-5 days that we have to alternate between dev and dev c, we'll be driven mad by the prompts everytime we validate reports in dev ...till testing is complete and e can switch back to the dev database in the model

i would have imagined that Report Studio will not pormpt for database once it has received the initial selection, unless browser is closed, but i guess that is not the case

our cognos login is the same as our NT login, so I guess there is no way to get around the constant prompting during the dev c days, because it rules out creating separate user roles/groups

[COGNOiSe administrator]

So you are not going to use security to prevent them from seeing both connections?

[Arsenal]

How would we do that, administrator?

For one, we who develop reports etc. in dev, will also be validating the reports in dev c by matching the data being pulled in by the reports against what is expected. In other words, us developers will have access to both dev and dev c databases, so we can continue to develop reports in dev, and then validate reports in dev c when new data is expected in

The problem is compounded because our Cognos login is the same as our system log in ...so, there is no way of assigning security

Unless you can think up some other way.....our admin can't, and neither can any of us....i'll personally come over and hug ya if you can save us from our current predicament of database prompting ;)

[COGNOiSe administrator]

Two choices:

1. Have an extra login, in AD or separate LDAP, for developers, and let them authenticate without SSO.
2. If your developers are also directory admins in DEV, you could create two groups, one for regular users with one test DB conn, and one for dev DB. The developers would then be able to reassign themselves as required, to test or dev DB Group.

Would that work for you?

[COGNOiSe administrator]

The other option would be to somehow leverage macros and parameter maps at the FM level. Then you could use CSVIdentity or a hidden (except for developers) prompt with a default value. But I agree, this is not the most fortunate setup. Splitting environments, even on the same hardware, would be my preference. Puts more structure around it.

Here is another one, what if you had two gateways, using same CS and two namespaces, one for regular AD and the other for a modified AD, one that would additionally populate a session variable to some static value? This way the users would not see any difference, while your developers could be authenticating with the dev namespace and leveraging the extra static session value, like #$account.parameters.var1#? Even better, you could populate that static value for both ENV and leverage it equally in both namespaces, ie: myDB_TEST and myDB_DEV, would be resolved equally with myDB_#$account.parameters.var1#.

Crazy, but it just might work.

[Arsenal]

administrator, thanks very much for your reply

can i admit that  didn't understand much about your second post ( using session parameters/parameter maps) :-\

i don't have much experience in using parameter maps...and neither do the admins, i suspect. I doubt seeing them go for a comlicated procedure anyway....u want  a job? i'll recommend you to the manager ;)

we do have 2 different environments on the same box..close to it anyway. sharing content store. i have no control over that, and have been overridden anyway on the multiple content store issue

as for your first post....right after i put in the update, i thought about having extra logins.i can put that proposal up...but would we need a separae instal of the LDAP (we use LDAP) for that?
and er, don't mind me asking but what is sso?

somehow i doubt they'll want to put in a separate login into the LDAP, though.

i'm sory if i haven't understood your post in its entirety...no fault of urs though :-X

[CogDT]

Wait...I just read your first and last post skipping all of the posts which likely contained your solution ( ;) ) but you have two different environments pointing to the same content store?  Like....does that even work?  Actually, if both environments point to the same content store db...then it's really one big environment.  Either way, you're on your way to a large headache. 

1) separate environments, separate content stores
2) same security namespace in each environment
3) proven practice = deploy your prod (or highest level whichever that may be) into dev c, dev then ut or whichever so that all environments mimic one-another.

[COGNOiSe administrator]

Arsenal, no worries mate! And thanks for the job offer, but I've manged to build quite a succesful company with two other Cognoids, over the past 3 years. If you are coming to the conference in Florida, despite the steep cost, stop by at our booth. We will be showing some cool stuff.

SSO - Single-Sing-On, usually associated with Integrated Windows Security, Site Minder or certificate based authentication, where users have only to login once to the network and every application recognizes their credentials.

CogDT, what Arsenal is forced to do is to run two logical, or conceptual, environments with one Content Store, which technically is fine, but logistically, backwards. The various suggestions we were able to offer, are just workarounds, to help a fella in need. It is still fun for me to think them up and explain how they could work, but I'm just twisted that way.