Stat 6.3 - User Guide

State-Based and Activity-Based Reports

Updating the Stat Repository by documenting environment refresh events allows you to run state-based reports. A state-based report takes into account changes made to an environment due to a refresh event. It shows the objects and archive sets that exist in an environment at a particular moment in time. This is in contrast to activity-based reports that show the history of activities that have occurred within an environment, such as migrations and upgrades. Stat supports both types of reports for your environments, even those that have been refreshed. If an environment has been refreshed, however, an activity-based report may not accurately reflect the state of the environment as it exists after being refreshed. State-based reporting of environment refresh events is supported in the Migration History Wizard, the Oracle Apps Patch Level Compare feature, and the Stat Report Library.

To illustrate the differences between state and activity-based reporting, suppose you migrated an archive set into your Test environment and then later refreshed that environment with another environment named Production. A state-based report run after the refresh event would accurately show that the archive set no longer exists in Test, since this data would have been overwritten when Test was refreshed with Production. An activity-based report, however, would show that the archive set had been migrated into Test, which would be accurate in an activity-based sense but would not take into account the fact that after the migration the environment had been refreshed, thereby creating the false impression that the archive set still existed in Test.

Patches - PeopleSoft and Generic Applications

For PeopleSoft and generic applications, the Patches tab displays general information about patches, such as its name or ID, a brief description, and comments. More specific patch information is displayed in the Patch window, including the incidents addressed by the patch and any dependencies that must be resolved before the patch can be applied.

The ability to add, edit, or delete patches is controlled by user class security rights.

System administrators associate the Patches tab with certain CSR types. Whenever a user selects one of these associated CSR types, the Patches tab is displayed in the CSR window.


	NOTE: Access to the Patch tab, as well as the ability to add, edit and delete patches, is controlled by security rights. If you only have access rights, you can view patch definitions, but you cannot edit them in any way.

For PeopleSoft version 8 and higher, you can use the Read Project Wizard to read in the objects of a PeopleSoft patch (defined in the form of a maintenance project). This way, Stat automatically populates the Patches tab with the information contained in the project. For more information on using the Read Project Wizard to read in PeopleSoft patches, see Object Management (PeopleSoft) .

Although the Read Project Wizard works only in conjunction with PeopleSoft, you can manually document a patch (including incidents and dependencies) for any application.

To document a patch:

In the Patches tab, click New. Stat opens the New Patch window.

In the General tab, you assign the patch a name or ID and, optionally, enter a brief description and any additional comments.

In the Patch ID field, enter a name or ID that uniquely identifies the patch and, optionally, enter a brief description and comments in the remaining fields. Then, optionally, click the Incidents tab.

The Incidents tab displays a separate record for each incident addressed by the patch. Documenting incidents is optional.

Click New. Then in the Incident ID field, type the name or ID of the incident. To delete an incident record, select it and click Delete.

(Optional) Click the Dependencies tab.

The Dependency tab displays a list of incidents that are addressed in other patches and must be resolved before the current patch can be applied. When you click Calculate, Stat identifies which patches and CSRs, if any, were used to resolve the specific dependencies. The results may include patches and CSRs in other service domains since dependencies are not service domain-specific. Using the Dependency tab is optional.

Click New. Then in the Incident ID field, enter the ID that uniquely identifies the incident addressed in another patch. To delete a dependency record, select it and click Delete.

(Optional) Click Calculate.

Stat searches for the incident ID on CSRs documenting patches already within the system. If the incident is located, the name of the CSR and patch ID are displayed in their corresponding fields.

(Optional) For PeopleSoft patches, click the Dependency Application tab.

The Dependency Application tab is only displayed for PeopleSoft patches of version 8 and higher. It shows whether each incident listed on the Dependency tab has been applied to each PeopleSoft database on the migration path. For each applied incident, the tab also displays the date it was applied, the IDs of the user who defined the incident and applied it, and general information about the release date and label of the patch. When you click Calculate, Stat creates/updates the information displayed on the tab.


	NOTE: The Dependency Application tab is populated using information taken from the maintenance log of each PeopleSoft environment on the migration path.

(Optional) Click Calculate to create or update the display.

Click OK to save your work and close the Patch window.

CSR Workflows

Workflows are based on a combination of service domain and CSR type. They regulate the sequence and conditions by which CSRs can change from one status to another.

Workflow Rules

In addition to the sequence of status changes enforced by the template diagram, workflows can include rule definitions that stipulate conditions which must be met before you can change a CSR from one status to another. For example, before you can change a CSR to a closed-type status, a workflow rule can require that all the tasks associated with an activity be completed or that a migration to a specific environment take place. Workflow rules consist of transfer rules and status rules.

For more information on workflow rules, see the Stat System Administration Guide, Chapter 5, “Service Domain-Specific Maintenance.”

Please select your product:

To serve you better, please complete the Purpose of your Chat:

Recommended Solutions for Your Problem

Stat 6.3 - User Guide

State-Based and Activity-Based Reports

Patches - PeopleSoft and Generic Applications

CSR Workflows

Workflow Rules