This chapter provides an overview and discusses:
The rules editor
Parts of a rule
How to create rules
The rules editor allows you define your own rules—the SQL statements that search for a changed definition. You can add new rules, modify existing rules, copy one rule to a new rule set, and delete rules.
Note. You must know your database thoroughly to know what rules to associate with specific definitions. You must also know how to use SQL statements to search for the impact of any definition change.
To open the rules editor, select Tools, Rules Editor. The Rules Editor page appears:
A rule comprises the following parts:
Type of definition that is changing. |
|
Type of definition that is affected by the changed definition. |
|
A grouping or subset of rules. |
|
The pillar, or application, for which this rule is written. The pillar is derived from the RELEASELABEL in the PSRELEASE table. The specific SQL statement is:
The RELEASELABEL value is converted to <pillar> x.xx and is the key to look up the value in the rules file. For example, RELEASELABEL CRM 8.00. Two core PeopleTools pillars provide rules that find the relationships between PeopleSoft metadata definitions, IDE and PPT. When rules are selected from the rules files, the IDE and PPT rules are always used in addition to your application's pillar, for example FMS or HRMS. |
|
Release version and used to determine the pillar value. |
|
The database platform for which this rule is written. Note. If you want to run rules against a specific (non-default) database platform, create a new rule in your own rules file, and add your rule for the specific platform. Rule selection will choose a specific platform rule over the same rule, but for the default platform. |
|
The database version for which this rule is written. |
|
These fields contain the database column names that identify the definition. The definition name is the internal name used by the rules engine. The definition print name is used when displaying the name to the user. These values are usually the same. For example, from the Field Impacting Record rule, RECNAME is one of the selected columns from the PSRECFIELD table. If the definition name and the definition print name is RECNAME. The rule is:
|
|
The Application Designer object ID for the definition. This field contains the template to create an Application Designer object ID for the impacted definition. Change Impact Analyzer uses this objectID to open the definition within Application Designer. For example, using the Field Impacting Record rule, the definition ID is 'RECORD'.RECNAME The elements of the name within single quotes (RECORD), are the literal string values of an Application Designer object ID class. If the RECNAME is Customer, then the Application Designer object ID is RECORD.Customer. |
|
The SQL select statement that is executed (or in the case of a Java rule, the name of a Java class). For example,
The parameter :1 refers to 1st element of the impacted definition name. In the case of PeopleCode impacting PeopleCode, the rule is implemented by the class as in:
Java rules can execute more complex code than SQL code, however, Java rules are not documented in this release. |
|
The action recommended for the definitions found. |
If you require rules that are not in the delivered rules files, you can add custom rules files. Oracle recommends that you clone an existing rules file. In this way, you can match key elements (rule set, database, database version, definition type, and so on) and then supply your own SQL code or Java program.
Make sure that you save your rules file with a new name and move it to a position above the existing rules file.
If you want to override a specific rule using your own rules file, make sure you
Use the same pillar as in the rule for which you want to override.
In the Select dialog (Configure, Rules Files), place the rules file that contains your new rule above the rules file to be overridden in the rules file list.
This rules file populates the Definition selection dropdown list in the New Workspace dialog page.
These rules use the fictitious type DefinitionSelection and an impacted definition type to search for the requested definition. For example, the rule DefinitionSelection impacts Record generates SQL that is used to populate the Definitions Matching Name area in the Impact Analysis Search Dialog (of a new workspace):
select RECNAME from PSRECDEFN where RECNAME like ':1%' ORDER BY RECNAME
The like ‘:1%’ supports partial name matching from the search dialog.