|Custom Run Control||KEVIN RESCHENBERG|
Here is an idea taught to me years ago by a talented
independent consultant during my first assignment with PeopleSoft
Consulting. I've used it ever since, making little modifications
over time. The idea is a very simple one: Create a "standard"
custom run control record and page, and use it whenever possible.
By doing this, you can save time, avoid bugs, and give your users a
more consistent "look and feel" and a run control table that carries
their previous entries from one report or process to the next.
The best time to do this is when you are creating a custom process
or report. You will need to create a run control table, so why
not make it reusable? This might be a good project for someone who
has just returned from PeopleTools training or who is just learning
on the job.
You could do this right now, without the explanation that follows, but
there are a few tips that I've learned through experience and that
might help you.
(Note that PeopleSoft already delivers some shared run
control tables, such as RUN_CNTL_HR, but they tend to be module-specific
and you will find that they don't include all of the commonly used fields.
Rather than customize these tables, it is probably better to create a
new table from scratch.)
First, create a custom run control table using your standard naming
convention. If your
unique identifier for objects
is "X", for example,
you might call the record X_RUN_CNTL. Look at an existing run control
table for the pattern. All of them will have OPRID and RUN_CNTL_ID fields.
Remember to add the one-line PeopleCode program behind OPRID.RowInit.
Which other fields should be included? Think about the custom processes
and reports you have written in the past. If you have a PeopleSoft HRMS/HCM
system, you probably used ASOFDATE or FROMDATE and THRUDATE. If you run
North American Payroll, you have certainly used PAY_END_DT frequently.
How about COMPANY, DEPTID, LOCATION, and BUSINESS_UNIT? Try to come up with a list
of 10-20 fields that are commonly used. This list might include a few custom
fields that are important to your users.
If you include ASOFDATE, do not default it to the current date (%Date)
on the record definition.
Once the record definition is finished, create your page. Once again, look
at (or clone) an existing run control page. Don't include a frame around
the main parameter area. If you cloned a page that includes this frame,
delete it now. In the page properties, check the "adjust layout for
hidden fields" checkbox.
Add each field to the page. Just arrange them vertically. If two fields
logically occur together (from- and through-dates, for example), put them
on the same line; but for all others, give each field its own line.
It's a good idea to add a few description fields located on derived
records. One should be placed next to the ASOFDATE field. Put another one—
DESCR200, maybe—at the bottom of the page. These will contain instructions
or useful information for the user.
Now go through all of the fields on the page (except for those in the
header, such as OPRID and RUN_CNTL_ID), and make them invisible
through PeopleCode. Put this code into the OPRID.RowInit event.
The idea is to have the component for each process or report "switch on"
only the fields that it needs.
If you are currently developing a custom process or report, test your
run control now. Create the table. Create a component for your new
program. Decide which fields you need. With the component open in
Application Designer, select View | PeopleCode. Find your custom
run control record and open the RowInit event. Now simply set each
field's Visible property to TRUE.
Why not use the normal record PeopleCode for this? I have found through
experience that this leads to some problems. First, your code will contain
a number of component-specific sections. This can make migrations
difficult to manage, as multiple projects all try to include the same PeopleCode
program. Also, developers will get "lazy" and piggy-back on a similar
component's code. This is fine until one person decides to change the
field list for one component without realizing that others will be
affected. In summary, this is an ideal use for
Those are the basics. Next week I'll have a few more suggestions on
specific fields and on using this run control in SQR.