A Closer Look at Siebel Incremental Repository Merge (Part 2)

Before we start, let's get a copy of the latest Siebel Database Upgrade Guide, which has a new chapter on IRM.

The Upgrade Guide also explains how to set up Siebel Tools for the IRM, as described in my last post. Now we'll focus on the IRM process itself. Here is the cookbook:

1. Edit the tools.cfg file
2. Rename the repository
3. Check-in and unlock all projects
4. Generate repositories
5. Run statistics on the database
6. Merge repositories
7. Review log files
8. Apply schema changes and import seed data
9. Review merge conflicts
10. Run post-merge utilities
11. Full compile
12. Delete unneeded repositories

1. Edit the tools.cfg file

Before we start, we should ensure that we have the proper version of Siebel Tools (8.1.1.10 that is, enabled for iPack mode as described in the last post) on a decent Windows workstation (or server) with the appropriate amount of free memory (2 GB to be on the safe side).

Ensure that the tools.cfg file is set up correctly, especially with the following parameters:

Also, ensure that you add the /iPackMode switch to the shortcut you use to launch Siebel Tools. IRM and the other features are only available when Siebel Tools is run in "Innovation Pack Mode".

2. Rename the repository

If you are a member of the "lucky team", you might have contributed to a Siebel upgrade project from one major release (e.g. 7.8) to a newer one (e.g. 8.1). Then you probably remember the task of renaming the existing development repository from "Siebel Repository" to "Prior Customer Repository". Well, that hasn't changed with IRM.

So we log on to Siebel Tools against the development server database and rename the repository accordingly.

3. Check-in and unlock all projects

Ensuring that all developers have checked in their latest changes and all projects are unlocked in the development server database will save us a lot of trouble.

4. Generate repositories

Now the process can start. Open the Prior Customer Repository if needed and from the Tools menu, choose Upgrade | iPack Deployment Wizard.

5. Run statistics on the database

Once the wizard displays that the import process was completed successfully, we are instructed to hit the Pause button. To improve the performance of the upcoming merge, the Database Upgrade Guide explains how to execute the runstats command against the development server database.

6. Merge repositories

Once the database completes collecting statistics, we can continue (or restart) the Innovation Pack Deployment Wizard and launch the merge process itself.

Again, this is technically the same thing that happens during a full upgrade. Siebel Tools executes a three-way repository merge. This usually takes a few hours, so you can read the documentation now and keep your fingers crossed as usual.

7. Review log files

Once the merge process is complete, we should inspect the IRM_Merge#.log file (with # being a number, usually zero) in the Siebel Tools /log directory and verify that it doesn't show up with any errors or difficulties.

8. Apply schema changes and import seed data

Experienced Siebel upgraders might remember that the full upgrade always includes the Database Upgrade Wizard which takes care of the database-related stuff such as importing repositories and applying schema changes. Well, here's another difference: The IRM wizard takes care of the schema and also triggers the necessary command line utilities to import the new seed data which comes along with the innovation pack.

This is the final step in the IRM wizard.

9. Review merge conflicts

The merge process produces very detailed data (at the property level) about every single difference between the four repositories. We can use the traditional Siebel Tools view (Applications Upgrade Object List - accessible from the Screens menu) to look for conflicts as usual or use the new Hierarchical Merge Report which is part of the new IRM functionality.

As with a full upgrade, a full inspection (involving some SQL select statements directly against the S_MERGE% tables) filtering out unecessary data and diligent analysis of the merge results is the key to a successful upgrade. The outcome of this step (which can take some time) is a list of developer tasks to "repair" objects (hopefully only a handful or none at all) which the merge process has rendered unusable.

10. Run post-merge utilities

The Database Upgrade Guide now instructs us to run the post-merge utilities which are also part of a full upgrade. It might seem an unnecessary step but you would have to decide for or against this step on a project-by-project basis, depending on the customization of standard objects.

11. Full compile

The new Siebel Repository now contains all customizations and the ACRs delivered by Oracle as part of the innovation pack. Once the developers have finished their "repair" duties, we must run a full compile to produce a brand-new SRF file. Ensure that your project plan allots enough time for testing!

12. Delete unneeded repositories

This is the final step in any upgrade, be it "incremental" or "full". To reduce the burden of the database, we (export and archive) and delete the three unused repositories using Siebel Tools.

Summary

The new Incremental Repository Merge bears much similarity to a full version upgrade. The biggest difference is that there is a single wizard which runs in Siebel Tools and takes care of all technical steps as opposed to a multi-utility approach in a "big" upgrade. Nonetheless, the same lengthy import and merge process are executed against the database so there is much room for errors or difficulties. In addition, project teams must be aware that the Oracle delivered repository data might be in conflict with existing customizations, so the same level of scrutiny and diligence must be adhered to as in a "big" upgrade project.

have a nice day

@lex