| Configuration for Custom SQR | KEVIN RESCHENBERG
06-14-2004 |
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.
|
