| Comparing and Migrating Projects | KEVIN RESCHENBERG
02-08-2006 |
One of the easiest ways to create instability
in your PeopleSoft environments is to misuse the
migration features in Application Designer.
Today I'd like to talk about some of the basic
features.
We migrate objects between environments either
when applying updates from PeopleSoft or when
applying customizations. Delivered changes
(upgrades, service packs, bundles, updates,
tax updates, patches, fixes—how many other
names for these things are there?) come with
their own instructions, but it is still important
to understand the different options we have.
While the compare reports may be a little rough,
App Designer's compare and migration
options are very comprehensive and give us a
great deal of control over the process.
Some new developers—and even some who have been
using App Designer for years—may be a little
confused about some of the options. I'll admit to
having a few misconceptions myself for a long
time. There are still areas that I don't fully
understand. Part of the problem, I believe, is
that PeopleSoft thinks of the migration process
as a way of automatically applying delivered
changes. Even the term "upgrade" used on the
menus reveals this way of thinking. On the other hand,
most of us approach
it as a way of applying customization, or of
merging customization with delivered changes.
That's the approach I'll take while discussing
the process here.
Before starting a major migration, it doesn't
hurt to clear your local cache, which is
probably stored at C:\PS\CACHE\your-environment-name.
This is especially true if you have done any
sort of database refresh. Have you ever seen a
case in which two obviously different versions
of an object compare as "same/same," or a
new object that doesn't even exist in the target
database compares as "same/same"? That's bad
cache.
The most important view for migration is under
the Upgrade tab in App Designer. Open a project,
select that tab, and open an object type.
The columns are:
Source: The state of the object in this database (more on this later)
Target: The state of the object in the target database
Action: What App Designer would do if you started the migration right now
Upgrade: A checkbox that instructs App Designer to do the "Action"
Done: A checkbox that indicates whether the "Action" has been done
When you first insert an object into the project,
App Designer has not yet compared it with any other
database.
It assumes that you will want to migrate the object.
Therefore, it sets the object initially to Source=Unknown,
Target=Unknown, Action=Copy, Upgrade=Yes, and Done=No.
The "Unknowns" simply mean that App Designer doesn't
know whether the versions in your two environments
are the same or have been changed (by you or by PeopleSoft).
In fact, it doesn't even know what the target
environment is. The situation is unknown.
Before doing any migration, run a Compare and Report
(Tools | Upgrade | Compare/Report). This operation
asks you to log on to the target database and then
does two things. First, it compares the object between
the current (source) database and the target, and
sets the items described above. Then it produces
a report of the differences.
I generally use the reports for PeopleCode objects only.
I find most of the other reports difficult and some
of them impossible to read. Just a personal opinion.
So I just automatically close them.
(The reports are still available for review or printing
later. Go to the menu and select File | Report From File.
The reports are stored in the "Upg" files. These must
be opened and/or printed from within App Designer.)
So why run the Compare/Report if you're not going to
read the reports? Because it also performs the very
important function of setting the migration options.
Look under the Upgrade tab again. Now an object might
be shown as Source=*Changed, Target=Unchanged, Action=Copy,
Upgrade=Yes, Done=No. If you then do the migration using
Tools | Upgrade | Copy, the object will be copied to
the target database and the Done checkbox will be checked.
Or, for example, the object may have been found to be
the same in the two databases. In this case, you will
see Source=Same, Target=Same, Action=None, Upgrade=No,
Done=No. App Designer won't bother copying this object
unless you tell it to.
If you want an object to be copied, three things must
be true: Action=Copy, Upgrade=Yes, and Done=No. You can
set these manually as needed. Even if the objects
compared the same and Action is set to None, you can
still force the copy. Click on the Action field and it
changes to a dropdown list from which you can choose
Copy. (If you find this necessary, refer back to the
discussion about clearing the cache. App Designer
might be confused, forcing you to override its
decisions.)
Now, I skipped one important step. There are certain options
that should be reviewed before any Compare/Report
or Copy. These are available either at Tools | Upgrade | Options,
or via an Options... button within the Compare/Report
and Copy dialogs. However you get to it, go to the
Compare Options tab. In the Target Orientation frame,
select "Keep Customizations." I said earlier that I'd
approach this from the point of view of someone who
is either migrating customizations or merging them
with delivered changes. As a client-side developer,
I would rarely if ever select "PeopleSoft Vanilla"
here. The effect of this option is very simple.
If you select "Keep Customizations," then a custom
object will be marked with Upgrade=Yes. If you
select "PeopleSoft Vanilla" (which is, unfortunately,
the default), then a custom object will be marked
with Upgrade=No. If you don't check the Upgrade
box, your carefully customized object won't be
migrated.
Some of the other options on this dialog can be a
little confusing. I'll discuss them next week.
And how should you set those 24 little checkboxes
under the Report Filter tab? I'll also try to
tackle that one. What's the difference between
"Changed" and "*Changed"? How can a customized
object be "*Unchanged"? What's the one migration
operation that App Designer is afraid to do?
And then there's the lesser-known
but very important option of the database compare...
|
