| Custom Run Control (part 2) | KEVIN RESCHENBERG
08-30-2004 |
Last week we built a shared custom run control record (table)
and page. Today I'll give a few more tips on using it.
First, a clarification: After adding the fields to the page, we
need to make them all invisible, as I mentioned last time. However,
I did not make it clear that this should be done through PeopleCode.
(The correction has been made.) We can put this into the OPRID.RowInit
event and simply hide each field or set Visible to FALSE, depending
on which PeopleTools version you are using and which type of
syntax you prefer.
Be sure to include a good selection of fields. It's better to have
some fields that are never used than to find it necessary to go back and add
more later.
ASOFDATE is a useful field and I recommend that you include it. This
field should be used a little differently from the other fields.
In many cases, we will provide an as-of date for the users, but assume
that the process will usually be run as of the current date (today).
Now, most developers would probably want to default ASOFDATE to %Date
in the record definition, or set it to the current date in PeopleCode
using %CurrentDateIn, SYSDATE, or
GETDATE(). Don't do this. Don't default ASOFDATE
to anything. Here's why. If we default it, the default occurs once
and the date is saved in the run control table. That means tomorrow's
run will see today's date—obviously not what was intended by the
default.
Instead of defaulting the date, I suggest that you leave it empty
but assume (within your process) that a NULL value for ASOFDATE means
"today". Put a DESCR-type field on the run control page next to
ASOFDATE, prompting the user to leave the date blank if the current
date is to be used. Whenever you unhide ASOFDATE, also unhide this
description field. An alternative would be to leave the value of
the description field blank in the record definition and fill it in
using PeopleCode.
Many of the processes that use the custom run control will probably
be SQRs, so we should create a standard SQC file to read the run
control table. Don't worry about which fields apply to each process.
In the SQC, simply read all of the fields from the run control
table. We could then just use the &variables that we need. However,
because of the way we are handling ASOFDATE, I suggest that you
code the SQC to create a $variable for each field instead. For example,
set $AsOfDate to the value of &asofdate if the ASOFDATE field contains
a value, and set it to the current date if ASOFDATE is NULL.
(You can set it to $AsOfToday to get the current date.)
Now you're ready to use this. The next time you write a new
report or process, you don't need to create a new record definition,
build the table, create a page, write new code to access the
table, etc. Simply write a few lines
of PeopleCode in the RowInit event for your run control table
under your new component (using component PeopleCode,
not record PeopleCode).
This code just unhides a few fields. If the new process is an
SQR, you simply #INCLUDE the SQC and call the procedure, then
use $AsOfDate or other variables.
Here are some suggestions for additional enhancements:
Edit the run control entries. If you included, for example,
FROMDATE and THRUDATE fields, then you might write standard
record PeopleCode to check them to be sure that FROMDATE <= THRUDATE.
Another idea is to create PeopleCode &variables that will flag
which fields are required. These flags are set by your
component PeopleCode, and then checked in the record PeopleCode SaveEdit event.
If a "required" flag is set, but the corresponding field is
blank or NULL, you can then trigger an error message for the user.
Report the entries. Your SQC could produce a standard
listing of the run control input in the log using SHOW statements. However, be aware that fields
you are not using may also contain values from previous runs of
other processes. Therefore, you would need to communicate which
fields are in use. This can be done by setting flags in your
component PeopleCode. Don't just clear out all of the other fields,
because this means that the user's run control won't retain
values from one process to the next.
Use fields for different purposes. If a field on your
run control table is almost the one you need, you could
use it and just set its Label property appropriately instead of
adding another field to the table.
Next week I'll take a break from PeopleSoft and tell you
about a little bug that may be sitting in your email right now,
courtesy of Microsoft. It has something to
do with MS Word, the state of Washington, and giant lava lamps.
|
