Merging Bundles With Customized Peopletools Objects

We’re always happy yet apprehensive to get a new bundle of bug fixes for Peoplesoft. We anticipate that our applications will run more reliably, perhaps faster, and maybe with a few new features. The chore that nobody likes, though, is checking for Oracle’s changes that affect the Peopletools objects we have customized.

The Merge Process

We install the bundles in our Demo system and run the Application Designer function that creates a “compare report.” This process compares the Project in Demo with the same Peopletools objects in our production system, Prod. We get a series of printable reports, one for each object type (record, page, Peoplecode, etc.). The reports show any differences in the properties of the objects. (A property of a Peoplecode program is its source code.)

We scour the reports for objects that we have customized. Those objects have changes made by Oracle in Demo and changes we made in Prod. Sometimes, our changes are bug fixes or minor modernizations that Oracle has now matched. More often, our changes are features we needed before and still need.

We usually copy the changed objects from Demo to our development system, Dev, and reapply the customizations we found in Prod. Occasionally, we keep our version of an object in Dev, and manually apply the changes we found in Demo.

Next, we test the Dev system, and make any more changes as needed. Finally, we migrate the objects to Prod.

Streamlining Compare Report

The compare reports can be quite long, especially the ones for various types of Peoplecode. We’ve had inch-thick stacks of legal-sized paper with tiny fonts. Nobody enjoys evaluating them. Here is a way to save some trees, save some eye-strain, and save some time.

1. Load the Application Designer project with the bundle changed objects.
2. Save it with another project name (e.g. CUSTOMIZED_OBJECTS).
3. Run the compare report function. In addition to generating the reports, this process also sets flags on each object in the project (e.g. Changed, Unchanged, Changed*, and Unchanged*). The asterisks indicate that last update operator for the object was a user account other than PPLSOFT; the object was customized.
4. Save the project again.
5. Clear the project from the Application Designer by performing a “new – project” operation.
6. Run this SQL in a database browser like SQLPlus or TOAD.

and TARGETSTATUS not in (4,5);

7. Load the CUSTOMIZED_OBJECTS project back into the Application Designer.
8. Run the compare reports function again.

Now your compare reports show only the objects that your organization customized.

Nothing’s Perfect

There may be false positives; the reports may include some objects that don’t seem to have any customizations. If somebody loads an object just to view it, and accidentally clicks the save button, it will have a customized timestamp even though it hasn’t changed.

There may be false negatives; sometimes a customization may be broken by a bundle change, even though the customized object was unaffected. For example, we might have written a snippet of custom Peoplecode that relies on a variable set by delivered Peoplecode. The bundle might remove the delivered code on which we’re relying, or might move it to a point in the execution queue after our custom code. This technique doesn’t reduce the testing we need, it just reduces the number of objects to review for the merge process.

Comments are closed.