August 1, 2005

Change Control in Application Designer

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.

Until next time...