|
Kevin Reschenberg
has over 20 years of experience in IT and holds an MS in
computer science. A former senior consultant and
process specialist with PeopleSoft Inc., he now works
with PeopleSoft customers as owner of Orange County,
California-based SparkPath Technologies, Inc. |
Configuration for Custom SQR
In
the last two posts I've discussed the naming of new
custom objects, and whether to create a new object
(clone) or simply modify existing objects. Last week we
dealt with the objects stored within the database. I
noted that the procedure is different for SQR. What is
the difference, and how can we best handle customization
of SQRs?
Unlike all other objects, SQR gives us the flexibility
to store versions of programs in multiple places and
have the system select the correct one. We can specify
up to four search paths. This is the major difference,
and it will help us keep control over our customization
while simplifying upgrades--that is, if we use this
flexibility to our advantage.
There are several ways that we could handle SQRs. Rather
than go through a long list of options, I'll just
recommend a configuration that seems to be common among
PeopleSoft installations and works well.
Create a folder for the delivered files (called SQR--it
will be created during the initial installation) and
another folder for custom files (generally called USER\SQR).
In the Process Scheduler configuration, list the custom
folder first and the delivered folder second. The other
two path entries will remain unused.
The SQR folder will contain all of the delivered SQRs
and SQCs. No custom changes should ever be made to
any of these files. Changes due to patches and
upgrades, however, are made directly to these files.
All custom code will be placed into the USER\SQR folder,
whether you are modifying an existing file or creating a
new one. For example, suppose that your unique
identifier is "X_" and you are creating a new report.
You might call it X_RPT1 and place it into the USER\SQR
folder. On the other hand, suppose that you need to
modify existing program PAY003.SQR. Under the
recommendations given earlier, you would want to keep
the same name. In this case, simply copy
PAY003.SQR from the SQR folder to USER\SQR and customize
the copy. The Process Scheduler will look for the
program in USER\SQR first and will run the customized
version. Note that we do not move the program.
The original version remains in the SQR folder so that
we can compare the two versions easily.
(Since we will always copy the program first and never
modify it in place, in some sense we always "clone" an
SQR or SQC. However, in many cases we keep the same
name, as discussed last week.)
The same procedure applies to SQC files. The Process
Scheduler configuration determines the search order for
SQCs as well (USER\SQR first, then SQR). When running
under SQRW or the debugger, we use the -I command-line
parameter to specify this search order.
For development and testing purposes, you might want to
consider creating another folder and placing it first in
the search order. This folder will contain very few
files. It is for "overriding" the other code
temporarily. For example, you might wish to have another
version of SETENV.SQC purely for development purposes,
because the environment settings needed for your local
client machine (file prefix locations, etc.) are
different from those used on your server. Rather than
modifying the shared copy of SETENV, or making
"temporary" changes to your SQR that might accidentally
become permanent, it is better to store a modified copy
in another folder and then place it first in the search
path. You then have control over the settings wihout
worrying about affecting other users. This technique is
normally used for testing under SQRW, but it can be used
in your main development environment as well. This helps
you avoid the need to change any code during refreshes.
The two-folder structure recommended above applies to
all environments, from development to production. This
means that there will be several identical copies of the
SQR folder and several almost-identical copies of USER\SQR.
This is fine. Don't try to save a little disk space by
sharing these folders between the various environments.
This would make it impossible to do upgrades, apply
patches, or perform customization without affecting
multiple environments simultaneously.
SQRs are the most heavily customized objects in many
installations. Separating your custom and delivered
files as recommended here can help you maintain control
over your development/testing environments and
migrations, simplify patches and upgrades, and avoid
risk to your production system.
Until next time...
 Email: kevin@sparkpath.com |
