| Change Control in Application Designer | KEVIN RESCHENBERG
08-01-2005 |
If you are the only developer for your PeopleSoft system, this item
probably doesn't apply to you. For the rest of us, working in environments
with other developers, change control is an important topic.
The term "change control" can refer to many things. Today I'm talking only
about the control over physical changes to PeopleSoft objects. Application
Designer includes a change control feature that can be enabled or
disabled. This feature supports object locking, change history, and
object stamping. Stamping refers to the user ID and timestamp information
that is saved with each object when we change and save the object.
This is always "on." The history feature stores basic change information
and an optional comment entered by the developer. This can be useful
documentation if it is used consistently. Today, though, I'd like to concentrate on the locking
feature.
When multiple developers are working on multiple projects, it is easy
to introduce bugs. One developer could change objects A and B while
another developer modifies objects B and C. When the first project
is migrated, objects A and B are copied to the next database. Now
only half of the changes needed for the second project have been
migrated. This can easily crash the system.
One solution is to lock each object before changing it. This is
done "logically," not using the database's locking mechanism.
Before changing an object you request a lock or reservation. If nobody
else already has a lock on the object, you "own" it and can make
your changes. You will then keep this lock until the object has
been migrated (preferably all the way to production) or you decide to
reverse your changes.
With locking enabled in App Designer, you can't modify an object unless
you own the lock. Each time you open an object, App Designer will do
one of three things. If you already have the lock, the object opens
normally. If another person has the lock, a message box informs you of
this and asks if you would like to open the object in read-only mode.
(I'm not sure why you wouldn't.) If nobody has a lock on the object,
a message box informs you of this and again asks if you would like to
open the object in read-only mode. (Again, I'm not sure why not.)
These messages are annoying but after a while you learn to dismiss
them quickly.
This system applies to objects that can be modified in
App Designer. Objects that cannot be modified in App Designer but
can be attached to a project and "upgraded" (i.e., migrated using
Upgrade|Copy) cannot be locked by a developer but can be locked
by an administrator. Process definitions are an example of this type
of object. I don't fully understand the logic behind this security
restriction, but no matter—locking of these objects is generally
less important anyway.
This system has a few unfortunate aspects. First, it is not always
obvious when changes are or are not allowed. You could be typing
changes into the PeopleCode editor only to find out that they cannot
be saved. Even if you have the rights to save them, you sometimes cannot save them
within the PeopleCode editor. For example, when changing Page
PeopleCode, the "save" button does not become active until you
close the editor and return to the page. This seems
counterintuitive to me.
The biggest problem, though, relates to the "granularity" of
what App Designer considers a lockable object. For example, to
change one Component PeopleCode program, you are required to lock
the entire component. A component could include dozens
of PeopleCode objects. No other developer will be able to modify
any of them while you have the component locked, even though it
is easy to imagine cases in which this would be necessary. Since
only the developer who has the lock, or the administrator, can
release a lock, prepare to make many urgent calls to ask for
locks to be dropped. Of course, that then defeats some of the purpose
of the system. It is important for all developers to understand that
a lock should be retained if possible until the object has been migrated. The
purpose of a lock is not simply to prevent simultaneous
changes. Locks should not be dropped without considering the
possible effects. Of course, even though you might want to keep
a lock, it is not always possible to do so due to the low granularity
described above.
I wish that App Designer change control didn't have these limitations. Installations
that have a product such as Quest Software's Stat! can use other
locking mechanisms instead, although these may involve an element
of "discipline" among developers to be effective.
|
