|Managing Objects||KEVIN RESCHENBERG|
What is an object?
While the term "object" has a well-defined meaning to programmers, today I'd like to discuss the handling of
PeopleSoft objects—specifically, how and when they should be modified and migrated.
Let's assume that you have at least three environments: development, testing and production. You probably have many more—possibly
dozens!—but that's a topic for another day. Let's also assume that you have one or more developers, plus functional analysts
and/or technically knowledgeable users. This is fairly typical, regardless of company size.
Under this scenario, you would most likely restrict access to objects via your policy and/or the use of PeopleSoft security mechanisms. The developers
would be responsible for maintaining the objects, while the functional users might be charged with system testing, user support and
Which objects are we talking about? A simple, first definition might be that an object is anything maintained by Application Designer. Examples
would be fields, records and pages. Allowing "just anyone" to modify one of these objects would pose obvious risks. To protect your system's
stability, it is critical to protect these objects from damage, including inadvertent changes. This is important not just in your production
environment, but also in any environment that is the source of migrated objects. Be sure
that all those who have access to objects and data understand the difference between a development database and a "sandbox" or "play" environment.
Translate values are an interesting example. While I believe that they are clearly objects that should be restricted to developers, I've noticed
that many less-technical users consider them fair game for modification. This is probably because translates serve two distinct roles: as a
list of valid values for a field, and as a source of descriptions. Some people naturally assume that it can't hurt to modify the descriptive
text; but then it's a small step to assume further that it can't hurt to add or delete values. Deleting translate values might be considered
risky by most people, but they may not realize that even adding new values can break code and corrupt data. I recommend that you restrict
access to translate values just as you would restrict access to a record definition.
In addition to those maintained by Application Designer, there are other objects that are maintained by another program but can be included
in a project and migrated by Application Designer. Message catalog entries and process definitions are examples of these objects.
Process definitions blur the line between objects and data. Look at the Notification tab. This would seem to be configuration data that
could be maintained directly within the production database. But then what happens if the process definition is modified in the development
environment and migrated? The process definition structure lies outside of the core PeopleTools tables, indicating that a process definition
is more like application data than a development object; but if the process definition is missing or incorrect, your user can't run that new report you
just wrote. That makes it sound more like an object.
Moving farther away from the obvious list of objects, we find other examples. Queries are objects that can be migrated. But should they be
restricted to developers? In many organizations, query design access has been rolled out to a large population of users. These users would
normally develop their queries in the production environment. This can lead to difficulties, including poorly designed or
inefficient queries that could affect production response times. Should queries be designed in a development or testing environment and migrated;
in the production environment; or in a separate reporting database? Each organization should consider the ramifications of each option and
set a standard.
Objects such as roles and permission lists present their own set of challenges. Do you have a security administrator who makes frequent
updates to these objects in production? Or are these objects maintained by developers and migrated? Are the delivered permission lists
used and modified, or do you have a separate set of them? What happens when PeopleSoft delivers new permission lists or modifications to
Even more unusual objects exist. Examples include URL definitions and trees. Where should these be maintained, and by whom?
There do not seem to be any definitive correct answers to many of these questions. Different objects may lend themselves to different methods
of management in your organization. But everyone should follow one consistent method for each type of object; the alternative leads inevitably to
data loss or system instability. Take the time to consider how best to
maintain and manage these objects, and then set a standard for each.