I tried to start a discussion here but did not get much response. Hoping get the discussion going this time.
I’m really struggling with migrating universes (unv and unx) using Promotion Management and keeping connections properly assigned.
In XI3, we would use LCM to migrate universes, and purposely not include the connection in the job. The universe in the target environment would retain its previously-assigned connection, which is exactly the behavior that we wanted. We used this method for six years.
In BI4, this no longer works. when a unv universe is migrated with PM, the target universe’s assigned connection will be changed to whatever it was in the source. That is, the target universe is completely overwritten from the source. Now, after every PM migration, we have to import the universe in UDT, assign the connection, and export.
The situation is similar but worse for unx universes. We have to import the universe, edit the connection shortcut, select the correct connection, save the connection shortcut, and publish the universe.
It appears that we’re supposed to use Connection Overrides, but from my experience, Overrides are more trouble than they’re worth, do not provide the same flexibility, and can potentially cause universes to point to an undesired data source.
So, I’m curious what other folks are doing for universe migration for unv and unx universes. Are you doing the import/export thing, using Overrides, or something else?
I did some testing with Connection Overrides (that’s what SAP told me I should use), but I have a number of concerns with implementing them:
[list][:777b596692]They require that the connections have the same name in each environment; so we couldn’t have a connection named “DW Dev” in our dev environment “DW QA” in QA, and “DW” in production. So it’s not clear from the connection name which environment it points to (with no indication of how it got reverted).
[:777b596692]The connection info is stored in the override, and is pushed to the target environment with each migration. So if I change a connection password in production but neglect to change it in the override, the next migration will result in an old password being used in production.
[:777b596692]There’s nothing to indicate to the migration user that an override has occurred. If someone else creates an override for a connection that I use, and I migrate my universe, it may be pointed to a database that I wasn’t expecting.
[:777b596692]We have universes that share the same connection in dev but are associated with different connections in production. This strategy would not be possible with overrides.[/list]
…and some others. I’m curious if you had the same observations and how you mitigated them if so?
We haven’t even considered using Connection Overrides and probably won’t. What we have found is if you have the CUIDs in sync across all of the environments where you are doing promotions, you don’t need to do anything with the connections. The promoted universe sees the CUID that it uses in the target environment and uses it. This would help address you first bullet point of naming the connection differently, the name won’t matter because the universe looks at the CUID. Your other bullet points are certainly valid concerns especially the last one.
I have been doing testing with Crystal Report Overrides, which we do want to use. We have a significant amount of Crystal Reports 2013 reports that report directly against stored procedures and the Database Configuration needs to be updated every time they are promoted.
I was able to get one Crystal Report Override configured and promoted although the BOE promotion did not work and I had to export the override to a biar file and then import it into the target environment (1759284 - How To: Step-by-Step LCM Override Settings via LCMBIAR file).
Now that I have tested the promotion process with this one override and have it working, I want to promote some more overrides but I haven’t bee able to get any more overrides to promote no matter what I try.
There doesn’t seem to be much documentation on using overrides either. This makes it more difficult to use them.
I’m sorry for replying late … only stumbled on the Q today.
( In fact, I am looking why LCM/Promotion Mgr says the overrides on my connection weren’t promoted)
As for the promotion of universes (with/without connection) we learned to do it this way :
While in BO XI 3 : using “lifecycle wizard” (is that the right name?) , we could promote a universe with or without its connection.
In BI 4.1 (SP5) the “Promotion Manager” can do exactly that : promote objects “without their dependencies”. In fact, for me it’s an easier interface.
Workflow:
a) in dev : create universe and connection. Name the connection “BO_LIVEDATA” or “BO_NightlyDATA”
b) also in dev : copy the connection (say BO_nightlyDATA) twice and name those BO_nightlyDATA_UAT and BO_nightlyDATA_PROD
c) these copies are used for “testing” universe behaviour. Normal universe development uses the BO_nightlyDATA connection, which -in the dev environment- probably points to development data.
d) develop the universe with development tests.
e) in the “promotion environment” (we use dev) create a promotion object “from dev to UAT” and add the universe
On “dependencies” check the dependecies. this includes the connection
Of course you’ll need a second promotion object “all alike” to promote the universe (a first time) to PROD
PROMOTE the development universe to UAT and to PROD (probably in prod nobody has access to it yet)
That way, the universe ends up in the “right” universe folder (same CUID as the one in dev) and using its new copy of “the” connection BO_nightlyDATA.
That connection too now has the same CUID in prod and UAT, that it had in dev.
f) in UAT: change the connection’s internals to point to “acceptance data”,
and do the same in prod to point to production data
You do not need to change the universe for that: from Universe Design Tool, you ONLY change the connection’s content.
g) Now go back to the promotion environment, edit both promotion objects and exclude the dependencies. Save both promotion objects.
h) When new development is done on the universe, make sure it uses connection BO_nightlyDATA , and not another one. The other ones aren’t needed in the other environments.
i) schedule (now?) your promotion object: ONLY the universe is promoted to UAT now, the connection in UAT points to testing data.
j) idem for promotion to prod, after UAT accepted your changes
Your approach is similar to what I’ve been recommending lately, but I’ve noted a few risks:
[list][:8bfeb4121e]If someone uses the connection for another universe, then migrates that universe (with the connection) to another environment, the connection credentials will be overridden in the target environment. So this could result in my universe in the production environment being pointed at the dev database. This could be mitigated by locking down security on the connection in QA/production, but that inherently limits the ability to change the connection when necessary.
[:8bfeb4121e]You need to be sure that the universe is pointed at the original connection when migrating it, else the universe will not be associated with any connection in the target environment. Using your examples, if I were to switch the universe to the BO_nightlyDATA_UAT connection before migrating it to the UAT environment, then the universe will not be associated with any connection in UAT. I would need to import the universe in UAT, select the connection, and export.[/list]
I’m curious if you had the same concerns, and how you addressed them?
We have all the connections secured in all of our environments so that only the Administrators can make any changes to the connections. This is even though we are starting to push universe development outside of the Administration group. It has worked well so far. We mostly use ODBC connections and if a universe developer wants to point to a different data source, they can just update their ODBC DSN or they can create a personal connection to point where ever they want. We suggest that they use a personal connection for local development work anyway.
Our universe developers are responsible to make sure their universe has the correct connection selected when they export it to Business Objects. This is part of their training and we have a list of the connections for the universes available to them on a SharePoint site.
So far, we have only had an issue when we had to rename one of the connections and we only had a problem until we deleted the old connection.
Indeed those are risks.
Reading that they have been replied to: I recognise the argument that “properly designed procedures, when followed, can lessen the risks”
It’s the same thing for promoting the tested universe to production after the go from UAT: if promoting “from dev”, the person promoting the universe (with/without connection) needs to use the proper check-in (ongoing development) / check out (version recently approved in UAT) and after the promotion: chack out the ongoing development.
I see there is “logic” in it.
We are now trying to develop on your previous remark : “if someone changes the connection”,
or worse: "if the connection is used by more than one universe … "
So we really had those “BO_livedata” and “BO_nightlycopy” connections, used by more than one universe.
But usually such a “set” of universes are not updated all together but one by one.
So we decided (our IT analyst asked us to invent something like it) … in order to be able to “switch connections between dev/test/prod data while testing in DEV and later in UAT”
So the current “scheme” becomes:
for each universe, create a NEW connection (con_universe) , that will point to the “current” data. Provide the extra connections for test data, prod data.
So we multiply the number of connections: one for each universe, instead of one for each database / data silo.
BUT
the Promotion Manager now refuses to “promote” the new connection. Either “the result will not be a tree” (if no “parent” is found in target …
Then I created a “dummy universe”, promoted it … the connection goes with it: everything fine.
My colleague creates a second universe-specific connection:
a) promotion to test FAILS
b) having the dummy universe use the new connection, we promote the dummy universe “with dependencies” : universe is promoted, connection is not
And (on BI 4.1 SP 5 ) we CAN try doing the same with the “internaluseonlynoversioncheck” thing (worked in the past) but that too seems to “fail” on the connection.
What now is best practice for “promotion of connections” ?
The “tree” error is a real PItA, and another reason why migrations were way easier, safer, and more efficient in XI3.
From the analysis I’ve done, the “tree” error occurs when you try to migrate a connection that has an association to a universe into a target environment where that universe is associated with a different connection.
For example: in the Dev environment, connection C is used by universe U.
In the UAT environment, connection C does not exist. Universe U is there but it uses connection C2.
You try to migrate connection C to UAT, and it fails with the “tree” error. The reason it fails is because it’s trying to add an association between universe U and connection C without removing the association between U and C2. Universes (except for multi-source unx) can only be associated with a single connection, so the attempt to associate a second connection causes it to fail
(Note that this happens even though you’re only migrating C; although you’re not migrating U, the promotion job include’s C’s properties, which include the references to universes.)
In this example, the solution would be fairly simple: delete the universe in the target environment and re-migrate C and U. However, this may be a problem if U has modifications that should not be brought into UAT yet.
Consider this nightmare scenario: you have 10 universes that use connection C. All 10 universes and the connection are migrated from Dev to UAT. Everything is in sync.
Now, in UAT, someone changes three of the universes to use a different connection.
You attempt to migrate connection C from dev to UAT and get the Tree error. Now, to fix the problem, you need to:
Run a Relationship Query in dev to locate the universes associated with C.
Run the same query in UAT.
Identify the universes that are using C in dev but not using C in UAT.
For each of those universes:
4a) Delete them in UAT and include them in the migration job, then switch the connections back after migrating, or
4b) Import the universes in UAT, switch them to connection C, export them, run the migration job again, change the connections back to what it was before, and re-export.
With that being said, we only promote a connection if it doesn’t already exist in the target environment.
The key here is to keep the CUIDs of the connections in sync between the environments and to use the same connection in all environments.
This doesn’t fit your scenario of wanting to be able to point your universe to different data sources though.
We use have some functionality configured to allow the users to change connections themselves using ODBC connections. See my post in this topic ODBC or OLE DB for MS SQL databases? for some more information.
(BOB member since 2002-08-29)
(BOB member since 2002-06-20)
(BOB member since 2007-06-18)