Tech Talk

LIGHTLY TECHNICAL OBSERVATIONS ON PEOPLESOFT, SQR, AND RELATED AND UNRELATED TOPICS

Archives

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 component PeopleCode.

Those are the basics. Next week I'll have a few more suggestions on specific fields and on using this run control in SQR.