This chapter describes how to configure and monitor a patching workflow that moves Managed Servers to a patched Oracle Home, updates the Java version on your Managed Servers, updates the applications on your Managed Servers, or any combination of these update tasks. You can use WLST to create and monitor the workflow or you can create and monitor the workflow via the WebLogic Server Administration Console.
Notes:
Prior to initiating the update process, you must have completed all appropriate preparation steps for the type of update you are doing, as described in Chapter 2, "Preparing for Zero Downtime Patching."For Windows-based domains, prior to initiating a workflow to update an Oracle Home, on each node, ensure that there are no locked directories or files in the Oracle Home being updated as this can prevent the Oracle Home from being moved to the specified backup directory. A directory can be locked by something as simple as having a DOS command window open to that directory. A file can be locked by having it open in an application.
This chapter contains the following sections:
When rolling out a new Oracle Home using either WLST or the Administration Console, the patched Oracle Home must be rolled out to the Administration Server first. There are two approaches you can take to do this:
Use one workflow to roll out the patched Oracle Home to the Administration Server, then use a second workflow to roll out the patched Oracle Home to your clusters. Oracle recommends using this approach, but it is not required.
In this scenario:
If using WLST, you would execute either the rolloutOracleHome or rolloutUpdate command, and specify AdminServer as the target. You would then execute rolloutOracleHome or rolloutUpdate again, and specify cluster targets.
If using the Administration Console you would create one workflow from the Servers tab and select your Administration Server as the target. Once that workflow completes, you would create a second workflow from the Clusters tab and select the clusters to include.
Use only one workflow to roll out the patched Oracle Home to the entire domain. The workflow will automatically roll out the patched Oracle Home first before rolling it out to the target clusters.
In this scenario:
If using WLST, you would execute either the rolloutOracleHome or rolloutUpdate command, and specify the domain name as the target.
If using the Administration Console, you would create one workflow from the Domain tab.
If the Administration Server will be included in a workflow, you must use Node Manager to start it before initiating the workflow.
Note:
If the Administration Server is currently running and was started using Node Manager, there is no need to perform these steps.To start the Administration Server using Node Manager:
If the Administration Server is currently running and was started using the startWebLogic script in the domain home, use the stopWebLogic command to shut it down:
UNIX
cd domain_home/bin
./stopWebLogic.sh
Windows
cd domain_home\bin
stopWebLogic.cmd
Ensure that Node Manager is running on the Administration Server.
Start WLST. See "Invoking WLST" in Understanding the WebLogic Scripting Tool,
Use the nmConnect command to establish a Node Manager session. For example, to connect to the domain mydomain located in /domains/mydomain using SSL, where the NodeManager port is 5556:
wls:/myserver/serverConfig> nmConnect('username', 'password, 'localhost',
'5556', 'mydomain', '/domains/mydomain','ssl')
After successfully connecting, run the nmStart command. For example, if the Administration Server is called AdminServer and the domain is located in /domains/mydomain:
nmStart('AdminServer', '/domains/mydomain')
For more information, see "Starting the Administration Server Using Node Manager" in Administering Node Manager for Oracle WebLogic Server.
This section describes how to initiate and monitor rollout workflows for applying a patched Oracle Home to the nodes in your domain. You can use this approach only if the workflow is applying a patched Oracle Home. If you want to include a Java version update or application update in the workflow, you must use WLST or the Administration Console.
Note:
When using OPatchAuto to initiate a workflow, you must use the Administration Console to monitor the progress of the workflow. See Monitoring and Managing Workflows.Use the following commands to initiate a workflow using OPatchAuto:
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh apply -plan wls-zdt -image-location path -wls-zdt-host adminserver:port -wls-zdt-target target -wls-zdt-remote-image path -wallet path -walletPassword password
The following table describes the parameters in this command:
| Parameter | Description |
|---|---|
-plan |
Indicates the type of operation to be performed by opatchauto apply. For rolling out a patched Oracle Home for ZDT, always specify wls-zdt as the value for this parameter. |
-image-location path |
Specify the full path and file name of the image JAR file that contains the patched Oracle Home to use for the rollout. For example:
|
-wls-zdt-host adminserver:port |
Specify the Administration Server hostname and port number for the domain you are rolling out the patched Oracle Home to. |
-wls-zdt-target target |
For target, specify the target for the rollout. This can be:
When rolling out the archive, you must specify the same target as you specified when you distributed the archive you are using for the rollout. |
-wls-zdt-backup path |
The full path to the directory and file to use for backing up your existing Oracle Home. For example:
|
-wls-zdt-remote-image path |
The full path to the archive file you want to create on each node to be included in the ZDT rollout. This does not have to be the same file name as the original archive. For example:
|
-wallet path |
The full path to a wallet directory that was created using configWallet.sh or configWallet.cmd. For example:
|
-walletPassword password |
The password for the specified wallet, if needed. For example:
|
You can use OPatchAuto to revert a rollout that has failed or stopped, as well as to revert a completed workflow. If the rollout has failed or stopped, OPatchAuto will revert it starting with the last successfully completed step. If the rollout has completed, OPatchAuto will initiate a new rollout, using the backed up Oracle Home as the Oracle Home to roll out.
Use the following commands to revert a rollout:
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh rollback -session workflow_id -walletPassword password
The following table describes the parameters in this command:
| Parameter | Description |
|---|---|
-session -workflow_id |
Specify the workflow ID of the workflow to roll back. |
-wallet path |
The full path to a wallet directory that was created using configWallet.sh or configWallet.cmd. For example:
|
-walletPassword password |
The password for the specified wallet, if needed. For example:
|
If an Oracle Home rollout failed and you want to resume it, use the following commands:
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh resume -session workflow_id -walletPassword password
The following table describes the parameters in this command:
| Parameter | Description |
|---|---|
-session -workflow_id |
Specify the workflow ID of the workflow to roll back. |
-wallet path |
The full path to a wallet directory that was created using configWallet.sh or configWallet.cmd. For example:
|
-walletPassword password |
The password for the specified wallet, if needed. For example:
|
This section describes the WLST commands that you can use to initiate workflows to update your Managed Servers and provides sample WLST scripts demonstrating various workflow (rollout) scenarios.
Note:
When using the WLSTrolloutOracleHome or rolloutUpdate commands to initiate a rollout of a new Oracle Home for a Windows-based domain, you cannot run WLST from any Oracle Home that will be updated as part of the workflow. For more information, see ZDT Patching Restrictions.The following WLST commands are used for performing automated rolling updates of your servers. These commands must be executed from the Administration Server for the target domain.
rolloutOracleHome—Rolls out a patched Oracle Home to your Managed Servers or reverts your Managed Servers to a previous Oracle Home. The patched Oracle Home archive you use in this command can be one that was created either using opatchauto or copyBinary and pasteBinary.
rolloutJavaHome—Updates your Managed Servers to use a new Java version.
rolloutUpdate—Updates your Managed Servers to use a patched Oracle Home and a new Java version. The patched Oracle Home archive you use in this command can be one that was created either using opatchauto or copyBinary and pasteBinary.
rolloutApplications—Updates specified applications that are running on your Managed Servers.
Note:
When specifying paths for Windows in rollout commands, you must use backslashes instead of forward slashes. To avoid undue errors, ensure that the backslashes are escaped, for example,C:\\myhome\\files\\apps.json. For more information, see "Syntax for WLST Commands" in Understanding the WebLogic Scripting Tool.When executing one of these WLST commands, the command determines which servers need to be updated and in which order, and creates a patching workflow that will update them safely. This includes:
graceful shutdown of Managed Servers on a node one at a time. This does not include Managed Servers that are currently in ADMIN or STANDBY mode. This includes migration of singleton services if the migrationProperties option is included in the rollout command.
replacing the Oracle Home directory (if applicable)
replacing the Java Home directory (if applicable)
replacing application directories (if applicable)
restarting the Node Manager on the node
restarting the Managed Servers on the node
Table 3-1 Arguments for WLST rollout Commands
| Argument | Description |
|---|---|
|
|
Required for all Specifies which Managed Servers will be included in the update. domain_name—Specify a domain name as the target if you want the Administration Server and all Managed Servers in that domain to be updated. clusters—Specify a cluster name or a comma-separated list of cluster names if you want to update all Managed Servers in the specified cluster or clusters, but not Managed Servers in other clusters. servers—Specify a server name or a comma-separated list of server names if you only want to update those Managed Servers. Note that the servers you specify must still be part of a cluster; they cannot be unclustered servers. Note: Typically, you should specify a server target only when updating the Administration Server. Oracle recommends that you not update individual Managed Servers in most cases as sessions may not be preserved and downtime for users may not be avoided. One situation, for example, in which you can safely specify Managed Server targets is if you have added one or more new Managed Servers and they are not at the same Java version as your other Managed Servers. |
|
|
Applies only to and is required for the Specifies the location of the Oracle Home archive (JAR file) or local Oracle Home directory to roll out, thereby replacing the existing Oracle Home. |
|
|
Applies only to and is required for the Specifies the full path of the directory to which the existing Oracle Home will be moved. This effectively renames the original Oracle Home. For example, if your original Oracle Home is /u01/Oracle_Home and you specify /u01/Oracle_Home_backup for this parameter, /u01/Oracle_Home will be moved (renamed) to /u01/Oracle_Home_backup. |
|
|
Optional. Applies only to the |
|
|
Applies only to and is required for the Specifies the location of the new Java home to use. |
|
|
Applies only to and is required for the The full path to the JSON file that defines one or more application names, application archive locations, and application backup locations. |
|
|
The following options can be included in
|
You can also use WLST to monitor the progress of a workflow. For more information, see Monitoring Workflow Progress.
Use the rolloutOracleHome command if you only want to do one of the following tasks:
Update your Administration Server to use a patched Oracle Home.
Update your entire domain (Administration Server and clustered Managed Servers) to use a patched Oracle Home.
Update clustered Managed Servers to use a patched Oracle Home.
Revert your Administration Server, clustered Managed Servers, or domain to use the previous unpatched Oracle Home.
rolloutOracleHome has the following syntax:
rolloutOracleHome(target, rolloutOracleHome, backupOracleHome, [isRollback], [options])
This command supports the isDryRun, autoRevertOnFailure, and isSessionCompatible options.
Example 3-1 shows how to roll out a new Oracle Home to the domain mydomain. The JAR file for the patched Oracle Home is located at /net/wls/wls_patched.jar. The original Oracle Home will be moved (renamed) to /u01/Oracle_Home_backup. The process will not automatically revert if it fails.
Use the rolloutJavaHome command if you only want to do one of the following tasks:
Update your Administration Server to use a new Java version.
Update your entire domain (Administration Server and Managed Servers) to use a new Java version.
Update your Managed Servers to use a new Java version.
Revert your Administration Server, Managed Servers, or domain to use the previous Java version.
rolloutJavaHome has the following syntax:
rolloutJavaHome(target, javaHome, [options])
This command supports the isDryRun and autoRevertOnFailure options.
Example 3-2 shows how to roll out a new Java Home to the cluster Cluster1. The new Java Home location is /u01/jdk1.8.0_50. The autoRevertOnFailure option is not included, therefore the workflow will automatically revert if the process fails.
Use the rolloutUpdate command if you only want to do one of the following tasks:
Update your Administration Server to use both a patched Oracle Home and a new Java version.
Update your entire domain (Administration Server and clustered Managed Servers) to use both a patched Oracle Home and a new Java version.
Update your Managed Servers to use both a patched Oracle Home and a new Java version.
Revert your Administration Server, Managed Servers, or domain to use the previous Oracle Home and previous Java version.
rolloutUpdate has the following syntax:
rolloutUpdate(target, rolloutOracleHome, backupOracleHome, [isRollback], {javaHome], [options])
This command supports the isDryRun, autoRevertOnFailure, and isSessionCompatible options.
Example 3-3 shows how to roll out a new Oracle Home and a new Java Home to the Administration Server. The JAR file for the patched Oracle Home is located at /net/wls/wls_patched.jar. The original Oracle Home will be moved (renamed) to /u01/Oracle_Home_backup. The new Java Home location is /u01/jdk1.8.0_50. The autoRevertOnFailure option is not included, therefore the workflow will automatically revert if the process fails.
Use the rolloutApplications command if you only want to do one of the following tasks:
Update your Managed Servers to use a new version of one or more applications
Revert your Managed Servers to use the previous version of one or more applications.
rolloutApplications has the following syntax:
rolloutApplications(target, applicationProperties, [options])
This command supports the isDryRun, autoRevertOnFailure, and isSessionCompatible options.
Example 3-4 shows how to roll out the applications defined in the JSON-formatted application properties file /u01/scratch/app_update.json to all servers in Cluster1.
Use the rollingRestart command if you want to initiate a rolling restart of all servers in a domain or all servers in a specific cluster or clusters.
rollingRestart has the following syntax:
rolloutRestart(target, [options])
Example 3-5 shows how to perform a rolling restart of all servers in Cluster1 and Cluster2.
Each rollout command returns a WorkFlowTaskRuntimeMBean that you can use to poll the current status of the workflow. To monitor the progress of a rollout, use a rollout command in the following format:
progress=rollout_command
For example, if rolling out a new Oracle Home:
progress=rolloutOracleHome(DomainA, '/net/patched/wls1221p.jar', '/net/backups/wls1221', autoRevertOnFailure=FALSE)
You can then use the methods of the WorkTaskRuntimeMBean to return information about the workflow. For more information, see WorkTaskRuntimeMBean in the MBean Reference for Oracle WebLogic Server. Here are some examples:
progress.getWorkflowId()
Returns the ID of the workflow.
progress.getProgressString()
'Workflow wf0011 Running: 13/36'
Returns a human-readable message containing information about the current workflow progress. In this example, workflow wf0011 is current running and has completed 13 of the 36 workflow commands.
progress.getStatus()
STARTED
Returns the current status of the workflow, which can be STARTED, SUCCESS, RETRY, REVERTING, FAIL, REVERTED, REVERT_FAIL, CANCELED, or REVERT_CANCELED.
The following Python script segment demonstrates one way to use the progress object to monitor a workflow and output the progress of a rollout task. Sample output is shown after the script.
Example 3-6 Monitoring and Outputting the Progress of a Rollout Task
# Print the starting information
rolloutName = progress.getName()
startTime = progress.getStartTime()
print "Started rollout task \"" + rolloutName + "\" at " + str(startTime)
# Check the state every 2 minutes
while not (progress.isComplete()):
progressString = progress.getProgressString()
print progressString
time.sleep(120)
# Print the ending information
endTime = progress.getEndTime()
state = progress.getState()
print "rollout \"" + rolloutName + "\" finished with state
Output
Started rollout task "Domain1Rollout" at 2014-07-22 07:29:06.528971
Running step 1 of 9
Running step 2 of 9
Running step 3 of 9
Running step 4 of 9
Running step 5 of 9
Running step 6 of 9
Running step 7 of 9
Running step 8 of 9
Running step 9 of 9
rollout "Domain1Rollout" finished with state "SUCCESS" at
2014-07-22 07:47:15.538299
A workflow can stop in either the executing or reverting direction for the following reasons:
The workflow failed while executing, with the autoRevertOnFailure option set to FALSE
The workflow was manually canceled
An unrecoverable error occurred during a revert operation.
When a workflow is stopped, you have the opportunity to resolve any errors manually and then continue to execute or revert the workflow. To do so, use the following methods on RolloutService:
| Method | Description |
|---|---|
executeWorkflow(WorkflowTaskRuntimeMBean) |
Takes a progress object that is eligible to be resumed and resumes it in the execute direction. If the last successful operation on the workflow was an execute, then the execute will resume with the next execute step. If the last successful operation on the workflow was a revert, then the execute will resume by executing that revert step. |
revertWorkflow(WorkflowTaskRuntimeMBean) |
Takes a progress object that is eligible to be resumed and resumes it in the revert direction. If the last successful operation on the workflow was an execute, then the revert will resume with that step. If the last successful operation on the workflow was a revert, then the revert will resume by reverting the next step in the revert sequence. |
canResume(WorkflowTaskRuntimeMBean) |
Returns true if the workflow stopped before it was completed and is not currently running in either direction. A workflow in this state is eligible to be resumed in either the execute or revert direction. |
This section describes several WLST commands that you may find useful.
To get a list of completed workflows:
wls:/domain_name/domainRuntime/RolloutService/rollout-service> completeWfs=
cmo.getCompleteWorkflows()
To get a list of active workflows:
wls:/domain_name/domainRuntime/RolloutService/rollout-service> activeWfs = cmo.getActiveWorkflows()
To look up a workflow by ID and retrieve its status:
wls:/domain_name/domainRuntime/RolloutService/rollout-service> progress=cmo.getWorkflowTask('workflow_id') wls:/Domain1221/domainRuntime/RolloutService/rollout-service> progress.getStatus()
To cancel a running workflow:
wls:/domain_name/domainRuntime/RolloutService/rollout-service> progress=cmo.getWorkflowTask('workflow_id') wls:/domain_name/domainRuntime/RolloutService/rollout-service> progress.cancel()
To delete a completed workflow:
wls:/domain_name/domainRuntime/RolloutService/rollout-service> cmo.deleteWorkflow('workflow_id')
This section contains a sample WLST script that illustrates how to perform a rolling restart of all servers in a cluster called cluster1 with single service migration. In this script, the following arguments are defined:
username—The WebLogic Server administrator user name
password—The WebLogic Server administrator password
adminURL—The hostname and port number of the domain's Administration Server
target—The target or targets for the operation. See Table 3-1.
options—The rollout option or options for the operation. See Table 3-1
Example 3-7 Sample WLST Script for a Rollout Operation
import sys, socket
import os
import time
from java.util import Date
from java.text import SimpleDateFormat
argUsername = sys.argv[1]
argPassword = sys.argv[2]
argAdminURL = sys.argv[3]
argTarget = sys.argv[4]
argTarget = sys.argv[5]
try:
connect(argUsername, argPassword, argAdminURL)
progress = rollingRestart(argTarget, argTarget)
lastProgressString = ""
progressString=progress.getProgressString()
# for testing progressString="12 / 12"
steps=progressString.split('/')
while not (steps[0].strip() == steps[1].strip()):
if not (progressString == lastProgressString):
print "Completed step " + steps[0].strip() + " of " + steps[1].strip()
lastProgressString = progressString
java.lang.Thread.sleep(1000)
progressString=progress.getProgressString()
steps=progressString.split('/')
if(len(steps) == 1):
print steps[0]
break;
if(len(steps) == 2):
print "Completed step " + steps[0].strip() + " of " + steps[1].strip()
t = Date()
endTime=SimpleDateFormat("hh:mm:ss").format(t)
print ""
print "RolloutDirectory task finished at " + endTime
print ""
state = progress.getStatus()
error = progress.getError()
stateString = '%s' % state
if stateString != 'SUCCESS':
#msg = 'State is %s and error is: %s' % (state,error)
msg = "State is: " + state
raise(msg)
elif error is not None:
msg = "Error not null for state: " + state
print msg
#raise("Error not null for state: %s and error is: %s" + (state,error))
raise(error)
except Exception, e:
e.printStackTrace()
dumpStack()
raise("Rollout failed")
exit()
To execute this script, save it in a Python (.py) file and then enter commands similar to this. If running WLST on Windows, see ZDT Patching Restrictions, for important information about using WLST on Windows.
$ORACLE_HOME/oracle_common/common/bin/wlst.sh /u01/scripts/rollout/RollingRestart.py username password t3://hostname:port cluster1 "migrationProperties=/u01/json/mig.txt"
This section describes how to create and monitor a patching workflow that rolls out a patched Oracle Home, a new Java version, new application versions, or any combination of these tasks. It contains the following sections:
To access the ZDT workflow functions in the Administration Console:
In the Administration Console, click on the domain name under Domain Structure.
On the Settings for domain_name page, select the ZDT Control tab.
This displays the four tabs (Domain, Clusters, Servers, and Workflow Progress) from which you can manage all workflow-related tasks.
You can create a workflow to roll out an update to all servers in a domain, all servers in one or more clusters, or only selected servers. The 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, Java Home, or application versions, or create a workflow to perform a rolling restart of servers.
Prior to following this procedure, access the ZDT Control tabs as described in Accessing ZDT Workflow Functions in the Administration Console.
To create a new workflow:
Select one of the following tabs:
Domain—Select this tab if you want to create a workflow for the Administration Server and all clustered servers in the domain.
Clusters—Select this tab if you want to create a workflow only for servers in specific clusters.
Servers—Select this tab if you want to create a workflow only for specific servers. Typically, you would want to select this option only in the following situations:
The Administration Server is the only server that will be included in the workflow.
A situation exists in which a Managed Server is out-of-sync with other Managed Servers that were already updated. For example, you may have added a new server to a cluster, but that server is using an older version of Java than the other Managed Servers in the cluster.
Note:
Oracle recommends that you not use the Servers tab to perform updates to individual Managed Servers unless it is absolutely necessary. When updating individual Managed Servers, there is no guarantee that sessions will be preserved and downtime will be avoided.If you selected the Clusters tab, select the clusters to include in the workflow. All servers in the selected clusters will be included in the workflow.
If you selected the Servers tab, select the servers to include in the workflow.
Click Patch to configure the workflow tasks.
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.
Rolling Restart—Select if you want to perform a rolling restart of the selected targets.
Click Next.
The displayed fields and options depend on the type of rollout or rollback you are performing.
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:
UNIX
/jdks/jdk1.8.0_50
Windows
C:\jdks\jdk1.8.0_50
If you are rolling out a new Oracle Home or rolling back to a previous Oracle Home:
In Rollout Oracle Home, enter the full path to the JAR archive or local directory that contains the Oracle Home to change to.
In Backup Oracle Home, enter the full path to the directory in which you want to back up the current Oracle Home. For example, if your original Oracle Home is /u01/Oracle_Home and you specify /u01/Oracle_Home_backup for this field, /u01/Oracle_Home will be moved (renamed) to /u01/Oracle_Home_backup.
If you are rolling back to a previous Oracle Home, select the is Rollback check box.
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 contains the information needed to upgrade the applications. For more information about creating this file, see Creating an Application Update JSON File.
If you only want to evaluate the patching workflow before executing it, select the Dry Run check box.
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 about creating this file, see Preparing to Migrate Singleton Services.
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 or revert it.
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 in 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. The default session timeout value is one hour.
Note:
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.Click Finish to initiate the patching workflow.
The workflow will be added to the Workflow Progress table.
Once the workflow has started, you can monitor and manage its progress from the Workflow Progress page as described in Monitoring and Managing Workflows.
This section describes how to monitor and manage the progress of all running or completed workflows.
Prior to following this procedure, if you have not already done so, access the ZDT patching tabs as described in Accessing ZDT Workflow Functions in the Administration Console.
To monitor and manage workflows, select the Workflow Progress tab. This page contains two tables:
The Workflows in Progress table shows all workflows that are not yet completed (active), that is, they are in an executing, reverting, stopped, canceled, or failed state. Depending on its status, you can perform various actions on an active workflow:
You can Cancel any workflow that is in a STARTED, REVERTING, or RETRY state.
To cancel one or more workflows, select the check box for each workflow that you want to cancel, then click Cancel. You can then revert the workflow by clicking Revert or resume it by clicking Execute.
You can Execute any workflow that is in a CANCELED, REVERT_CANCELED, FAIL, or REVERT_FAIL state.
To execute one or more stopped (cancelled) workflows, select the check box for each workflow that you want to resume, then click Execute. The workflow will continue executing, starting with the step after the last successfully completed step.
You can Revert any workflow that is in a CANCELED, REVERT_CANCELED, FAIL, or REVERT_FAIL state.
To revert one or more stopped (cancelled) workflows, select the check box for each workflow that you want to revert, then click Revert. The workflow will revert, starting with the last successfully completed step.
You can Delete any workflow that is in a CANCELED, REVERT_CANCELED, FAIL or REVERT_FAIL state. You can delete only one active workflow at a time.
To delete a workflow, select the check box for each workflow that you want to revert, then click Revert. The workflow will revert, starting with the last successfully completed step.
The Completed Workflows table shows all workflows that have completed. This table is sorted based on when the workflow completed, with the most recently completed workflow at the top of the table.
To delete completed workflows, select one or more of them and click Delete.
From these tables, you can also view additional details about the status of a workflow. To do so, click on the workflow ID in the Workflow ID column. For more information, see Viewing Workflow Details. For information about workflow statuses, see Workflow Statuses.
This section describes how to view the details of an active or completed workflow, and also describes the information that is displayed for the workflow.
To view the details for a workflow, click on the workflow ID (for example, wf00071) in the Workflow ID column of either the Workflows in Progress or Completed Workflows table on the Workflow Progress page. A page is displayed with the information described in Table 3-2.
Table 3-2 Workflow Progress Details Fields
| Field | Description |
|---|---|
|
Workflow ID |
The workflow that was automatically assigned when you created it. |
|
Type |
The type of workflow, which can be:
|
|
Target |
The servers to which the workflow is targeted, which can be:
|
|
Status |
The current status of the workflow. See Workflow Statuses, for more information. |
|
Can Resume |
Indicates whether or not the workflow can be resumed or reverted. If false, you will not be able to use the Execute or Revert functions on the workflow. |
|
# of Completed Commands |
The number of workflow commands that have currently been completed. |
|
# of Total Commands |
The total number of commands in the workflow that need to be executed to complete the workflow. |
|
Progress String |
A detailed message about the progress of the workflow, such as: Workflow wf0008 finished successfully. 36 steps completed. |
|
Next Execute Step |
If the workflow is still active and is not reverting, this field shows the next command that will be executed once the current command completes. |
|
Next Revert Step |
If the workflow is still active and is reverting, this field shows the next command that will be executed in the revert process once the current command completes. |
|
Begin Time |
The time at which the workflow was started. |
|
End Time |
If the workflow has completed, this field displays the time of completion. |
|
Exception |
If the workflow failed, this field displays the exception that occurred when it failed. |
|
Advanced |
Click the arrow to expand the Advanced section, which shows all steps that have been executed for the workflow up to the current time. If the workflow has completed, this section lists all commands that were completed by the workflow. |
From the Servers page, you can view the current status of all your servers before and after running a workflow and also while workflows are in progress. When you click the Servers tab, you can view the workflow-related information about each server in your domain. For information about the columns in the Servers table and additional columns that you can add to the table, see .
When a workflow is running, you can monitor and refresh the information on this page to get up-to-date status for each server.
From the Clusters page, you can view information about all clusters in your domain before and after running a workflow and also while workflows are in progress. For information about the columns in the Clusters table and additional columns that you can add to the table, see .
When a workflow is running, you can monitor and refresh the information on this page to get up-to-date information for each cluster.
An active workflow can have any of the statuses listed in the following table.
Table 3-3 Workflow Statuses for Active Workflows
| Status | Description |
|---|---|
|
STARTED |
The workflow has started and is currently running. |
|
RETRY |
A stopped workflow has been resumed. |
|
REVERTING |
A workflow that failed or was stopped is reverting. |
|
FAIL |
The workflow has failed to execute completely. This status appears only if the Auto Revert on Failure option was not configured for the workflow when it was started. |
|
REVERTED |
A workflow that was either automatically or manually reverted has successfully completed the revert process. |
|
REVERT_FAIL |
A workflow that was either automatically or manually reverted failed to revert successfully. |
|
CANCELED |
The workflow was canceled (paused). |
|
REVERT_CANCELED |
A workflow that was either automatically or manually reverted was canceled (paused). |
A rollout consists of a series of steps. Each step logs a message to the Administration Server log when it starts and when it finishes. Messages are also logged if a step reverts, fails, or retries. The Administration Server log is located at:
domain_home/servers/AdminServer/logs
The workflow ID is included in every log message related to a given workflow, making it easy to filter the Administration Server log file for messages related to a given workflow. If you initiated the workflow from the Administration Console, you can get the workflow ID from the ZDT Control > Workflow Progress tab. From WLST, you can use the following command to get the workflow ID:
progress.getWorkflowId()
To filter the log file, enter the following command:
fgrep domain_home/servers/AdminServer/logs/AdminServer.log
The following table shows the format of log messages for ZDT patching.
Table 3-4 Log Messages Format for ZDT Patching
| Message Type | Message Format |
|---|---|
|
A step begins executing |
|
|
A step is complete |
|
|
A step is being reverted |
|
|
A step has successfully reverted |
|
|
A step is being retried |
|
|
A step could not be completed successfully |
|
|
A step could not be completed successfully due to an exception |
|
|
A step could not be reverted successfully |
|
|
A step could not be reverted successfully due to an exception |
|