| Good Ideas that Sometimes Aren't | KEVIN RESCHENBERG
09-19-2005 |
"Everybody knows" you should do the things listed in this
column. Just look at your own company's PeopleSoft
development standards manual and you'll probably see
them listed there. These are, in fact, good practices
and features—some of the time, anyway...
The message catalog. The message catalog
consists of two tables containing text (in long and/or
short versions) keyed by two numbers. These snippets
of text can show up on pages or in error messages.
There are very good reasons to use them, but if they are
not used properly they can cause headaches. I could
do an entire column on the use of the message catalog.
In fact, that's what next week's topic will be.
(I started to write about it for this week
but it just got to be too long!)
For now, let me point out what is probably the most
important function of the message catalog: Support
for multiple languages in your PeopleSoft system.
More on that in a moment. But for fixed text on
pages and in error messages, in single-language
systems, consider whether use
of the message catalog will help or will just
waste time or, in fact, lead to bugs.
Now, you may object to the "single-language" aspect
of this advice. How can we be sure that we'll never
need to support multiple languages? Only you can
answer that question for your own organization. But
if I were supporting the Anytown School
District HR Department, I think I'd know the answer.
If you're not licensed for multiple languages and
it's very unlikely you will ever need them, why
worry about it? On the other hand, if you do
support multiple languages, proper use of the message
catalog can help you avoid problems with the
next item...
Language-specific pages. Every page can exist
in one or more language versions. The ".ENG" in
a page name indicates that this is an English page
(or, more generally, for the "base" language, which
should always be set to English). ".ESP" indicates
Spanish, and so on. Now suppose that you support
English, Spanish and French, and you are designing
a new page. Should you create three pages? Usually
not. It's better to create one page (as .ENG)
containing no hard-coded text. Instead of
hard-coded text for the page heading, instructions, etc.,
use message catalog items. PeopleSoft will then
automatically serve up the correct strings for each
language.
Language-specific pages should be used only when there
are alignment issues applying to a particular language.
For example, German text tends to be rather long,
while Japanese text occupies less space. Of course,
you might want certain fields to appear only for
certain countries, but remember that this is more
of an issue for the "flags" (the country-specific
sections of a page) rather than for languages. There
is no reason that a French-speaking user couldn't live
in Spain.
Custom menus. Many installations place all of
their custom reports, processes and pages under one
menu. This helps the developers centralize the
custom features. It also reduces or eliminates changes
to the delivered menus—and we know that migrating
menus can be tricky.
But here's the problem: The users need to know which
programs are custom and which are delivered. But why
should they care? If they want to run a particular
benefits report, wouldn't they expect it to be on the
benefits menu? Also, if you migrate menus (many
customers don't), be careful with the custom menu
because it will change frequently and unfinished
features could be carried along into production.
Cloning. "Clone, clone, clone!" is what PeopleSoft
taught when I was going through training. "Always
clone!" is what many development standards manuals say.
This is often a great idea. Sometimes, though, it is
a very bad idea that can complicate upgrades
and increase the risk of bugs. See
Modify or Clone?.
Separate custom records. Most developers are
afraid to add a field to a delivered "record" (table)
definition. They create a new, parallel record
definition instead. This new record contains all of
the keys of the other table. It's not a child but rather
a sibling of the other table.
Doing this avoids modifying a delivered record
definition. But is that important? Every time you
change a default value, a prompt table reference,
or some other attribute of a record definition, you're
modifying the record.
The only situation I can think of in which this would
be important is where the system uses a COBOL program
to INSERT rows into the table. These situations are
pretty rare, affecting a handful of tables among the
many thousands in your system. If you happen to run
into this situation, believe me, you'll know. The
COBOL program will stop on an error.
So why would anyone not create a new parallel
record? The problem is one of data integrity.
Suppose that you need a new JOB-like table and you
create one called X_JOB. Your custom programs will
then probably join JOB and X_JOB to get data from
X_JOB. They will assume that for every JOB row, there
is a corresponding X_JOB row. To make that true, you
need to do three things. First, every component that
inserts rows into JOB must be modified to include
X_JOB. Every process that inserts into JOB (a custom conversion
or retro processing program, for example) must be
modified. Then you must create the initial set of
rows corresponding to your existing JOB rows. If
you miss any of these steps, then joins on the
two tables could fail. This would not cause a SQL
error, of course, and your reports might mysteriously
drop data.
Application Engine. Yes, I've already written
enough about that one here
and here.
It's easy to write programming standards. It's harder
to make them realistic and effective. If a standard
leads to practices that waste time or cause bugs,
shouldn't it be reviewed?
|
