Wednesday, December 15, 2010
merging
1. If you’re sure that no changes have been made in the production RPD that are not already reflected in the development one, you can just copy across the development RPD to production and have done with it. The safer way to update the production RPD would be to three-way merge the development one into it, as this will preserve the changes made in production or at least prompt you to choose between them and any subsequent updates in development that conflict with them.
To start a three-way merge, you’ll need the following three RPD files
i. A copy of the original RPD as initially put into production (this is known as the “baseline” RPD)
ii. A copy of the current production RPD (which may now differ from the baseline RPD)
iii The development RPD that you want to merge into the current production one.
ii. A copy of the current production RPD (which may now differ from the baseline RPD)
iii The development RPD that you want to merge into the current production one.
Once you’ve got all these files together, we can start on the three-way merge of the RPDs.
2. To start merging, open up the BI Administration tool using an offline copy of the current production repository.
3. From the application menu, select File > Merge… and then select the baseline RPD as the original RPD.
4. The merge process will then parse the original and current production RPDs to identify and differences between them. If this is the first time you have updated the production RPD, and you’ve not made any changes to it in production, then this process will come up blank, otherwise it’ll point out any changes between the original and current production RPDs.
5. Now you can select the development RPD that you’d like to merge into the production one. Press the Select… button next to the Modified Repository area and pick up the development RPD. It’s most likely that there will be no conflicts (there may be though if you’ve applied hotfixes to the production one), and so you’ll need to press the Stats button to see what items will be added, deleted or updated during the merge process.
6. Now that the production RPD has been updated, it’s time to consider the web catalog. Again, if you don’t let users develop reports in production, or at least you don’t let them develop in the Shared area, you can just archive and then unarchive the Shared and/or the Users folders from the development web catalog to the production one, using the Catalog Manager, to copy across the new reports. If you just want to migrate a few individual reports though, there’s a new option in the form of the Content Accelerator Wizard that you can use for this purpose.
The Content Accelerator Wizard (CAF) is a plug-in to the Catalog Manager that migrates reports between two environments, and will also create any logical column calculations that the reports depend on but that aren’t found in the target RPD. Coupled with a standard RPD three-way merge this is quite a neat way to migrate individual reports from development to production, as you don’t need to have two copies of the Catalog Manager open at one time and it takes care of any calculated columns that you need.
After installing CAF and making sure that the Catalog Manager is pointing towards a JDK 1.6 or higher, open the Catalog Manager to point to the development environment, and select the report you wish to promote (or “clone”) into production.
7. When the clone process starts, you are prompted to select the target web catalog (this need to be an online catalog, and can be either local or a remote server), and the location of the source and target BI Server repository (RPD) file, which have to be connected to offline. The RPD files are required so that the cloning process can create any logical calculations that are needed by the cloned report (if the report requires full logical columns, you’ll need to add these to the target RPD using a three-way merge).
The wizard then prompts you to select the target subject area that the cloned report will be mapped on to.
8. Next comes the mapping process. The logical columns in the source web catalog need to be mapped to their corresponding columns in the target web catalog, together with dimension levels, something that you need to do manually but that can be saved, as a CSV file, to use again in later migrations. Any new calculated columns are added automatically by CAF, but if there isn’t a corresponding target column to map regular columns to then you’ll need to bring it in via an RPD three-way merge.
9. Finally, the migration takes place, and you can choose to perform a consistency check as well as view the log of migrated objects.
10. Once the migration has happened, you can take a look in the target web catalog and see the new report, ready to run and within the /Shared/Cloned folder. The target RPD will have any new calculated logical columns added, with “Autogen” as the name prefix.
So there you have it, one method to do incremental updates of OBIEE projects. In the next instalment, we’ll take a look at version control using Subversion and TortoiseSVN.
¶ 11:17 AM
Post a Comment