Stat 6.2 - User Guide

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.

NOTE: Access to the Patches tab is controlled by a user class right.

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.

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.

TIP: To check whether patch applications into a particular environment require approvals or not, see the Approval Required column in the environment table of the Target Environments window.

TIP: With proper security rights, you can also change the status of your own patch approvals.

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

IMPORTANT: A patch cannot be applied to an environment if just one approver rejects it, even if that user’s approval is not otherwise required. Before the patch can be applied, either the user or another user authorized to override patch approvals must change their approval status from Rejected to Approved or to Pending.

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.

NOTE: When scheduling requests, note the following • If the Oracle Agent is not running whenever you submit a request, Stat displays a warning message. When this is the case, re-start the agent and submit the request again. • Although you can apply patches and perform patch impact analyses on distribution environments, Stat processes these requests only on the distribution environment itself, not the distributed environments associated with it. • Before scheduling a request for a patch that has been associated with a CSR via the Undocumented Patch Tool, make sure the patch zip file targeting the appropriate platform has been uploaded to the Stat Repository. This information is displayed in the Files tab of the Edit Patch window. For more information on the Undocumented Patch Tool, see Object Tools and Wizards .

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:

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.

IMPORTANT: You must have “OraApp Patch - Apply” security right to schedule a Patch Cycle event

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

NOTE: For multi-node environments with shared appl_tops, Stat always starts only one agent on the Admin node; therefore it is mandatory to have the ssh utility enabled and thereby enabling adop to be run remotely on other nodes via adop remote invocation.

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