Chat now with support
Chat mit Support

Stat 6.2 - 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

Associating Patches with CSRs

After uploading a patch to the Stat Repository, you can then associate that patch with a CSR. Associating patches with CSRs enables you to apply them to environments and perform impact analyses. In order to associate a patch to a CSR, the CSR must have the Patches tab enabled. The enabling of the Patches tab is determined by CSR type.

You associate patches with CSRs the same way you associate objects, first by selecting the Patch Inventory environment and then the type of patch you want. The patches that you can add to a CSR are all active patches in Stat’s patch inventory.

2
In the Environment field select Patch Inventory.
4
Click Add Object.
5
Select File | Save, or click the Save toolbar button.

Approving Patches

Before you can apply a patch to an Oracle Applications environment, you may need to get the patch approved by users authorized to approve patch applications to that environment. Conversely, if you have been designated as a patch approver for a particular environment by your system administrator, other users may need your approval before they can apply a patch to that environment. Patch approvals are environment-specific. They provide a way for users (typically managers and development leaders) to monitor and control patch applications to environments containing sensitive information, such as object definitions that should not be modified or overwritten.

Approval lists can be either required or optional and can include individual users, entire user classes, or a combination of the two. Although system administrators can add any user or class to an approval list, be aware that only users that have access to an environment (as determined by system administrators in the User Maintenance table) will be able to approve a patch application into that environment or receive email notifications regarding their pending approval. If an approver does not have access to the environment, the patch cannot be approved until either the user is granted access to the environment or the patch’s approval requirements are overridden by another user with proper security rights.

When you click All Patch Approvals, the tab displays all the patches that are awaiting approvals from other users. With proper security rights, you can make patch approvals for other users.
2
Click in the Status column for each patch that you want to approve and select Approved. If you do not approve the patch, select Rejected.
3
Click Save.
If you selected Rejected, the approval record stays on the My Patch Approvals tab until you change it to Approved, or the patch approval is overridden.
c
Click Save.

You can also approve patches in the Approval List for Target Environment window.

2
In the approval list, double-click your name and in the pop-up menu select Approve if you approve the patch. If you do not approve the patch, select Reject.
5
Click OK or Apply to save your changes.
NOTE: With proper security rights, you can make approvals for other users. You can also unapprove all approvals by clicking Unapprove All. This allows you to deselect Ready to Migrate for the target environment. When you override another user’s approval, Stat records you as the approver, not the user originally assigned to make the approval.

If you want to notify users about patches that are still pending their approval, you can email a message predefined by system administrators. In the tree list of approvers, select the node representing the user or class that you want to notify and click Email. An email job request is sent to the Stat Central Agent, which processes the request and sends an email to the user you selected or to each member of the selected class. A “@” sign is displayed for that approver node in the Envelope field of the Approval List tab.

NOTE: The Email button is disabled once the approval requirements of a patch have been satisfied.

System administrators can also configure the Stat Central Agent to include links in the reminder message that the recipient can click to approve or reject the patch application. This sends an email back to the Stat Central Agent, which processes the response email and changes the approval status to Approve or Reject, depending on which link the approver selected.

NOTE: When an approval status is changed by responding to a reminder message, the Update Date field in the Approval List window will be automatically populated and the Update By field will display the value, Via Email.

Approval notification reminder messages can also be sent for workflow status transfers and migrations. For more information, see the book Stat System Administration, Chapter 7, “Email Configuration”.

Scheduling Patch Applications and Impact Analysis

In the Schedule Request window, you can configure the Oracle Agent to apply patches to selected environments or to perform impact analyses on patches. For both process request types, you can specify when you want the Agent to process the requests, either immediately or at some future date. For patch application requests, you can also define additional parameters, including how to handle approval requirements, the order in which to apply multiple patches, and, if necessary, whether to stop and start the four service partitions defined for the server of the targeted environment.

You can open the Schedule Request window either from the Patches tabs of the CSR window or from the Patch Inventory tab of the Oracle Applications Management Console. To open the Schedule Request window, select one or more patches and click Schedule.

If you are opening the Schedule Request window from the Management Console, you can only select patches that are already associated with a CSR. Also, if you want to process multiple patches, each patch must be associated with the same CSR.

Patching R12.2 Environments

In R12.2 environments, the Application Tier file system maintains 2 copies of all files, both of which are used in Stat: a Run Edition File System, and a Patch Edition File System. Stat archives files from the current Run Edition, and migrates to both editions, depending on which option the user selected.

Patching for R12.2 environments is done through a patching cycle. There are 5 phases in a patching cycle: prepare, apply, finalize, cutover, and cleanup. After the cutover stage is run, the Run Edition and Patch Edition file systems are swapped.

If there is at least one active R12.2 environment or higher (meaning that there is an “AD” record in the list of imported products with code level of “C” or higher), a Patch Cycle button is displayed on the Patch Inventory tab on the Oracle Apps Management Console window. For these environments, patching is done on the Patch Edition of the environment. A utility called adop is used to manage patch cycle phases, apply patches, and run impact analyses. The Patch Cycle button is used to schedule any phase of a patch cycle but cannot be used to schedule Apply Patch or Patch Impact requests (which are scheduled the same way as other environments through the Schedule button.)

In the Oracle Apps Management Console, both the Patch Cycle button and the Schedule button open the Schedule Request window. The Patch Cycle button is only displayed if there is at least one active R12.2 or higher environment.

In the Schedule Request window, the Environment field lists all active environments. If you select a R12.2 environment, the Process Type field includes the patch cycle options prepare, finalize, cutover, cleanup, and status. Depending on whether the window was opened from the Patch Cycle button or the Schedule button, The Process Type field displays additional options:

If opened from the Patch Cycle button, the Process Type field displays additional phases including Abort, fs_clone, and actualize_all.
If opened from the Schedule button, the Process Type field displays the Apply patch and Impact Patch options, as well as the patch cycle options prepare, finalize, cutover, cleanup, and status.

The window displays different input fields based on the option selected in the Process Type field. The Dependent Event fields allows scheduling the patch cycle request as a dependent event. In the adop options field, you can overwrite any adop parameters specified in the New Patch window.

NOTE: The Maintenance Mode option is not supported for R12.2 and higher and is not displayed if the environment is R12.2 or higher.

For a multi-node instance, there are 2 ways to apply the patch to all nodes.

In a Multi-node environment, by default we assume that ssh utility is running between the Admin node and all other nodes. To override this use the following stat.conf parameter: <env>.env.ssh_disabled:n

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen