OTN Home > Oracle WebLogic Server 12.2.1.4.0 Documentation > Administration Console Online Help > Create a patching workflow for domains, clusters, or servers

Administration Console Online Help

Previous Next Open TOC in new window
Content starts here

Create a patching workflow for domains, clusters, or servers


You can create a patching workflow to patch a domain, one or more clusters, or one or more servers. The patching workflow can be for rolling out a new Java version, rolling out a new patched Oracle Home, rolling out one or more updated applications, or any combination of these. You can also create a patching workflow to roll back to a previous Oracle Home.

Prior to creating a workflow, ensure that you are familiar with all restrictions and have properly prepared for the workflow. See Preparing for Zero Downtime Patching for more information.

To create a patching workflow:

  1. In the Administration Console, click on the domain name under Domain Structure.
  2. On the Settings for domain_name page, select the ZDT Control page.
  3. Select one of the following pages:
    • Domain: Select this page if you want to create a workflow for all servers in the domain.
    • Clusters: Select this page if you want to create a workflow only for servers in specific clusters.
    • Servers: Select this page if you want to create a workflow only for specific servers. Typically you should select this page only if you are updating the Administration Server. For more informaition, see .Creating a New Patching Workflow for a Domain, Cluster, or Server
  4. If you selected the Clusters page, select the clusters to include in the workflow.

    If you selected the Servers page, select the servers to include in the workflow.

  5. Click Patch to configure the workflow tasks.
  6. Select the type of rollout or rollback you want to perform:
    • Java Home: Select if you only want to change to another Java version.
    • Oracle Home: Select if you only want to roll out a new Oracle Home or roll back to a previous Oracle Home.
    • Application: Select if you only want to roll out one or more updated applications or roll back to one or more previous application versions.
    • All Combinations: Select if you want to roll out or roll back any combination of Java Home, Oracle Home, and application updates.
  7. Click Next.

    The displayed fields and options depend on the type of rollout or rollback you are performing.

  8. If you are changing the Java Home, in the Java Home field, enter the full path to the Java Home to change to. For example:

    C:\jdks\jdk1.8.0_40 (Windows) or

    /jdks/jdk1.8.0_40 (UNIX)

  9. If you are rolling out a new Oracle Home or rolling back to a previous Oracle Home:
    1. In Rollout Oracle Home, enter the full path to the archive or local directory that contains the Oracle Home to change to.
    2. In Backup Oracle Home, enter the full path to the directory in which you want to back up the current Oracle Home.
    3. If you are rolling back to a previous Oracle Home, select the is Rollback check box.
  10. If you are rolling out one or more new application versions, in the Application Properties field, enter the full path to a JSON-formatted text file that conains the information needed to upgrade the applications. For more information, see Creating an Application Update JSON File.
  11. If you only want to evaluate the patching workflow before executing it, select the Dry Run check box.
  12. By default, the Auto Revert on Failure check box is already selected. This will cause the patching operation to automatically revert everything if there is a failure while the workflow is executing. If you clear this check box, the patching operation will not automatically revert if there is a failure; the operation will stop and wait for you to resume it.
  13. If you want to migrate singleton services, such as JTA or JMS, during the rollout, in the Migration Properties field, enter the full path to a JSON-formatted file that contains the migration information. For more information on creating this file, see Preparing to Migrate Singleton Services.
  14. The Session Compatibility option determines whether or not the very last server being updated on a cluster will wait for sessions to complete on that server.
    • If not selected, the last server on a cluster waits for sessions to complete.This ensures that a compatible server is available in the cluster to handle sessions that must be served by a Managed Server that is still running on the existing version.
    • If selected, this indicates that the session state in servers is 100% compatible between the existing version and the new version. Therefore, the last Managed Server in the update sequence in a cluster will shut down without waiting for all existing sessions to complete.

    Oracle recommends that you not select this option unless you are absolutely sure that the session state is practically identical. This may cause the rollout to take longer due to the wait for session completion. Note that WebLogic Server serialization/deserialization differs slightly from Java serialization/deserialization. Therefore, additional fields on classes may result in a session being incompatible with servers on the new version, requiring that they be served by a server on the existing version. For example, a User class that adds a field such as Information will cause that session to be incompatible between versions.

  15. Click Finish to initiate the patching workflow.

Result

The workflow will be added to the Workflow Progress table.

After you finish

For related information, see the following topics:


Back to Top