サポートと今すぐチャット
サポートとのチャット

Stat 6.3 - User Guide

Introduction to Stat Connecting to Stat Change/Service Requests Stat Consoles Tasks and Time Entries Stat Projects Search Engines Reports and Graphs Personal Rules Object Tools and Wizards Change Management for PeopleSoft
Object Management (PeopleSoft) Object Archives (PeopleSoft) Object Migrations (PeopleSoft)
Change Management for Oracle Applications
Object Management (Oracle Applications) Patch Management Object Archives (Oracle Applications) Object Migrations (Oracle Applications)
Change Management for Generic Applications
Object Management (Generic Applications) Object Archives (Generic Applications) Object Migrations (Generic Applications)
Appendix: Troubleshooting Chart Appendix: Migration Options Appendix: User-Specific Parameters Appendix: Supported PeopleSoft Proprietary Objects Appendix: Stat Reports

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.

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.

1
In the Patches tab, click New. Stat opens the New Patch window.
2
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.
3
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.
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.
5
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.
6
8
(Optional) Click Calculate to create or update the display.
9
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.”

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択