| Documenting Object Attributes | KEVIN RESCHENBERG
10-24-2005 |
Suleiman has a little problem. He's been assigned
to go manually into App Designer and document the properties
of several thousand objects. As fun as that sounds, he's
wondering if there are any alternatives—a table,
maybe. I can think of two good approaches.
The first suggestion is to find out exactly what the users
are looking for and why. If you've been working
in this field for a while, you've
probably had a few cases in which you worked for
hours or days to produce a report or
detailed document, only to find later that the person who requested
it had just had a passing curiosity about something and didn't really
need all that detail. So do a little probing. What is the
documentation going to be used for? There are many possibilities,
and each one may lead to a different way of satisfying the request
—if in fact it needs to be satisfied at all.
But let's assume that we really do need a list of objects and
their attributes. Yes, these are stored in the database, and
it turns out that (which one exception) they are fairly easy
to retrieve.
Each PeopleSoft object is defined by one or more tables.
For fields, look at table PSDBFIELD. For "records" (tables,
views and work records), look at PSRECDEFN. That table defines
the record itself. For the fields within that record, look at
PSRECFIELD.
In App Designer, do File|Open... for object type Record
and type Table. In the name field enter "PS" to get a list of
all of the basic PeopleTools tables. (Only the oddly named
XLATTABLE will be missing.) There are about 400 of these
tables. Scroll the list and you will see that they are named
very well—you should be able to guess the purpose of
most of them from their names. Be aware, though, that pages
are still referred to as "panels" (as in PSPNLDEFN) and that
components are still called "panel groups" (as in PSPNLGROUP).
Just go into Toad, Query Analyzer, or whatever SQL tool you
use and explore these tables. You will see that they are
fairly easy to use. However, there is one big exception...
On the PSRECFIELD table is a field called USEEDIT. This is
a number that contains within it many attributes of record
fields. For example, it indicates whether a field is a key,
whether it's audited, required, a list box item, etc.
USEEDIT is
a bit map. Each binary bit indicates whether a particular
attribute is on/true/yes or off/false/no. For example, when the
lowest-order bit is set, this indicates that the field is
a key. This means that every key field will have an odd USEEDIT
and every non-key field will have an even USEEDIT.
There are, as they say, 10 types of people: those who understand
binary and those who don't. If you don't understand binary,
don't worry. Do a Google search on "USEEDIT" and you will
find many good writeups on this field and how to unpack
it using SQL or SQR.
|
