I seem to be getting conflicting/confusing information from the various postings in the BoB Universe Designer forum about whether it is advisable to use Refresh Structure when migrating a universe from say Dev to Test, after the appropriate SAP BW InfoProvider has been transported from BW Dev to BW Test environments. Does anybody have some best practice guidlines, or even practices that they use?
I’m happy with the procedure and how to interpret the results in an RDBMS environmnet (e.g. Oracle) but SAP BW is a black box.
Do you understand the difference between “refresh” and “integrity check”? They are not substitutes for each other, whether using a cube or any other data source. Each feature has a specific purpose.
Yes Dave, I understand them comprehensively, but it’s not always clear from the postings, why somebody chooses one over the other. In a RDBMS environment I know exactly which one to use, and why. But in a SAP BW environment, when InfoProviders are transported between SAP environments (and I want to ensure no changes to the InfoProvider as a result of the transport) I am less clear about which to use.
Do you have any specific guidance as to which to use in the SAP BW environments as a reult of such transports?
Actually Dave, we do both whenever we do a universe migration.
The reasons are:
We run the Refresh Structure to make sure that there are no changes in the underlying database that may impact our universe. If there are changes to the database but we don’t have objects built for those particular columns the universe is still fine.
We run the Integrity Check to make sure all of our objects are still valid and nothing broke.
We run these before saving the universe out to the target environment. (We don’t use the import wizard, we save the universe out of the source environment and then log into the target environment to run the checks.)
This has proven to be a valuable quality check before we move migrate a universe. We have been able to find issues with our database by doing this.
I should add that we have different databases for each environment just like we do for Business Objects. I know some users hit the same database for all of the Business Objects environments so this could be the difference.
But an integrity check will find those items that impact the universe without altering / updating the universe itself. Code changes should not be done during migration, right?
Think about it… an integrity check will find missing (dropped) tables, renamed tables, missing or renamed columns, anything that will break the universe will be caught. Frankly speaking, I don’t that there are any reasons to run a “Refresh Structure” during a migration.
You have good points Dave. I guess I never though about that fact that a structure refresh potentially changing the structure of the universe and thus the underlying file. This is similar to making a code change during a migration. This may be because it happens so rarely.
I think we will drop that piece of our migrations.
This is what makes BB so great. Funny how “Best Practices” can always be improved.
I agree. It shows up what has changed in a database structure but should not have done, flagging up that they have not migrated their database correctly from, say, Development to Staging.
(BOB member since 2004-04-13)
(BOB member since 2002-06-06)
(BOB member since 2002-06-06)