Monitoring Executions and Queue Runs

As an Operator, you use the Workflow Monitor to monitor Workflow Executions (instances of a Workflow that pass through defined states from planned to completed) and ensure that the Application deployment is being properly deployed.

Queue Runs are created when a queue is started and the contained Workflows are being executed. Within the Monitoring main page, you can manage Workflow Executions and Queue Runs. Queue Runs can be started, paused, resumed, or canceled. Also, you can change the order of Workflow executions within the Queue Run.

This page includes the following:

About Workflow Monitoring in CDA

In Continuous Delivery Automation you can monitor the details of any executed workflow, regardless of whether it is running or it has ended successfully or not. You can also monitor specifications of the workflow or one of its objects (as defined in the Workflow Designer) and take actions on a workflow or one of its objects.

Where you Can Monitor Workflows in ARA

You monitor workflows in CDA in the workflow monitor. Because the title of the window is the name of the workflow, you never see the words "workflow monitor" in ARA, but that is how it is referred to in all descriptions and instructions.

In the CDA web applications, the workflow monitor is part of the Deployment Manager application. If you only have that application or all of CDA installed, then you have the workflow monitor. You open it from the Monitoring list or if you are monitoring in a parent workflow that contains other child workflows in it, you can go directly to monitor the child. For details, see Opening the Workflow Monitor.

Screenshot displaying workflow in Workflow Monitor

What you Can Monitor

You can monitor any executed workflow or child object of an executed workflow that you are authorized to work with. Authorities and permissions are set in your user definition. For details, see the "User Management" information in the CDA Administration Guide.

What you Can See About the Workflow

Section/Information Description

Structure

You can see the structure of the workflow with all the tasks that are involved. This structure is defined in the Workflow Designer of ARA.

Status
  • The status of the overall workflow execution
  • The status of the individual object executions within the workflow

Details

You can view the details of the primary workflow or any task within the workflow.

Reports

If the workflow has any related reports, you can open and view them.

What you Can Do when Monitoring a Workflow

Besides monitoring the status of a workflow and its tasks and viewing information about them, you can also take actions on the current execution of the workflow. These actions do not affect other executions of the workflow or the workflow definition. For information about the actions that you can take on a workflow, see Workflow Monitor. For information about the actions that you can take on a task in a workflow, see Tasks in a Workflow.

Viewing Workflow Executions and Queue Runs

  1. Click the Monitoring tab in the Navigator pane.
  2. The Monitoring list is displayed, which shows all scheduled, started, or ended executions, with the most recent at the top.

    Note: Executions are also displayed in the Deployment Calendar.

  3. Click in the toolbar to view the queue runs.

    The Queue Runs page lists all scheduled, started or finished queue runs, with the most recent at the top. In the columns of the table, you see the following information:

Status Values for Executions

You see the status of an execution in the following locations:

An Execution can have one of the following status values:

  Status Description
Waiting states Waiting for approval The Workflow has been executed, but there are approvals pending, so the execution cannot run.
Waiting for start The Workflow has been executed, potential approvals have been made, but the planned start time has not passed yet.
Waiting for manual confirmation The Workflow has been executed with the option 'Manual confirmation required' - approvals have been made, the start time window is open but the execution has to be confirmed by a specified user or group.
Active state Active The execution is actively running.
Blocked state Blocked The execution is blocked (for example, due to a problem in an action).
Final states Finished The execution has ended successfully.
Canceled The execution has been canceled.
Failed The execution has failed.

Status Values for Queue Runs

You see the status of a queue run in the following places:

A queue run can have one of the following status values:

State Description
Inactive

The queue is stored but either not yet finished in its configuration or deactivated because of manual interaction.

In this state, the queue can be edited but no new executions can be added to it.
Active In this state, the queue is waiting for its execution. New Workflow executions can be added to the queue and it can be administrated without restrictions.
Processing

This state is entered when the queue starts executing. While there are executions left, the next execution is processed depending on approval and confirmation:

  • For executions that are approved and confirmed: CDA starts the execution and waits for its completion
  • For executions that are not approved, not confirmed or both: CDA waits for the approval and confirmation (identical behavior and timeout as for stand-alone executions)

You can interrupt this loop even when not all Workflow executions are finished.
Pausing after current

This is an intermediate state a queue can be in during execution processing: CDA waits for the running Workflow execution to complete. Once this has happened, the queue automatically pauses itself.
Paused

The queue is stopped and does not start the next scheduled Workflow executions. Currently running Workflow executions are stopped too.

Custom View for Executions

You can save your preferred table structure using Custom Views. See: Working with Custom Views

Opening the Workflow Monitor

When a Workflow has been started, you can monitor its active or final status and can see details for the execution. For active executions, you can also influence the execution with various actions. You do all this in the Workflow monitor window, which you can open from the Execution List or the execution task itself.

You can also execute application deployment Workflows from the Deployment / Workflows page of the related Application.

The steps here describe the various ways that you can open the Workflow monitor for an executed Workflow or a child Workflow within an executed Workflow.

There are multiple places from which you can open the Workflow monitor:

Creating Executions and Queue Runs

When you trigger the execution of a Workflow, a so-called Execution is created. Application Workflows and General Workflows may be executed on their own; however, Component Workflows are only executed as part of Application Workflows.

Important! Creating Executions requires fully specified dynamic properties for the deployment.

To Create an Execution

  1. Open the Release Automation perspective.
  2. Click the Workflows accordion tab and select a Workflow. You can also access a Workflow from the Application Dashboard.
  3. Click Execute to display the Schedule Workflow Execution dialog.

  4. Provide the following information:

    • Deployment Profile

      The deployment profile you want this Workflow to be executed with. The profile that is used in the previous execution is selected by default. (Only for Application Workflows).

    • Deployment Package

      The deployment package you want this Workflow to be executed with. The package with the latest creation date is selected by default. (Only for Application Workflows).

    • Planned Start: the planned start time. Can be one of the following:
      • Now (default)
      • At... - if selected, you have to specify the planned start time
      • In queue... - if selected, you have to specify the queue
    • Manual confirmation required
      • When executing a Workflow, you can choose if manual confirmation is required for the execution (default: NO).
      • Set the user or group who has to confirm the start of the execution manually.
      • When all approvals have been made and the start time has been reached, the execution stays in the Waiting for manual confirmation state until the defined user confirms the execution.

        Notes:

        • Users without read permissions on a Workflow cannot approve or reject an execution. Therefore, approval requests will not be sent to them.
        • The technical execution is started by the user who created the Workflow execution, not by the one who confirmed it.

    • Installation mode

      You can specify whether you want already successful installations of Components to be overwritten (Overwrite existing Components) or skipped (Skip existing Components - default).

      Note: when executing the Workflow with the option Skip existing Components the following applies:

      • The decision whether a component is installed or skipped is based on the installation records, which are automatically created during all deployments.
      • If Artifacts have been assigned to one or more Application Components, the system checks the Artifact versions. If the versions match, the Component Workflow is not executed.
      • Artifact versions are ignored when deploying a Patch Package. In this case, the Component Workflow is triggered as a "new" installation.

    Tip: Click Evaluate Properties to review the outcome of the dynamic properties that are defined for the Application Components

  5. Click Evaluate Properties to check if the dynamic properties are defined correctly and avoid errors that could arise during deployment. See: Evaluation Settings

Executions are not always started at their planned time. If the execution requires approval, it can only be started after it gets all necessary approvals (see: Working with Approval Requests). The same goes for execution with manual confirmation. Without the necessary approvals or confirmations, executions stay in state Waiting for Approval or Waiting for Confirmation. However, there is a limit for the time execution to stay in their state.

Pending approval requests are revoked automatically one hour after the planned start time. The state of the execution is set to Failed.

Note: This time out - also called grace period - is configurable. An administrator can change the value for the key GracePeriod in the ApprovalSystem section of the customer.config file (Automic\Release.Manager\WebUI\customer.config).

Re-scheduling Workflow Executions

You can use this feature if you have the permissions for creating and canceling Workflow executions.

Only Workflow executions with the start mode Planned at.. that have not already been started can be rescheduled to a new, future date. This includes the following states:

Important! If a Workflow execution which requires approvals is rescheduled, then all possibly existing approvals are invalidated (revoked) and the approval process starts all over again.

Note: If the requester has rescheduled the execution himself, he does not receive a revocation notification.

To Re-schedule and Execute a Workflow

  1. Go to the Monitoring List.
  2. Select the execution you want to reschedule.
  3. Click the Re-execute button in the toolbar.
  4. Select a new starting time.
  5. Click Execute.

Changing Properties of Executions and Queue Runs

To change the properties of an Execution or Queue Run you can use one of the following:

You can change the following properties:

Executions of General/Application Workflows

Queue Runs

Defining the Execution Order in Queue Runs

You can re-order, cancel, or archive executions in a queue run for all executions which have not been started yet.

Runs can be accessed:

  • The execution order can be changed:

    • Note: The new position cannot be before executions that have already been started.

    Postpone to a later queue run

    You can move the selected execution to the later run.

    Note: Executions can be postponed only when they have not been already started.

    Move to current (for Later Run only)

    Moves the selected execution from the later to the current run.

    Re-Execute

    Opens the Workflow execution dialog, with the properties from this execution, which you can change for the new execution.

    Deleting Queue Runs

    Note: You may only delete the entity when you have the appropriate permission on the containing folder (see Security Concept in CDA) and all of the listed conditions are met.

    Conditions to delete entities of type QueueRun

    Audit with Execution Reports

    CDA provides a central view and enables to audit the complete process history for retrospective analysis and audits.

    A history is automatically tracked for all workflow executions and on changes of properties of CDA objects. These include creation, property changes or status changes and attempted runs for the executions. Details of each history record include updated components and variable values.

    The execution history includes the complete deployment parameters.

    The audit trail for executions includes the downloadable execution report.

    Download an Execution Report

    You can download and view reports for workflow executions in a final state in two ways:

    Execution Report File Structure

    The report file includes the following sections:

    Header

    The header section provides general information for the execution.

    --- HEADER --------------------------------------------------------

    Workflow: <Workflowname>

    Application: <Applicationname>

    Package: <Packagename>

    Profile: <Profilename>

    Environment: <Environmentname>

    Start time: <Starttime>

    End time: <Endtime>

    Requested by: <User name>

    Status: <Status>

    -------------------------------------------------------------------

    Example:

    --- HEADER --------------------------------------------------------
Workflow: AraDeploy
    Application: ARA51
Package: Load_c53502ac-93c2-453a-a457-19ddecc96825
Profile: QAtest1
Environment: QAtest1
    Start time: 2014-06-02T13:31:39Z
End time: 2014-06-02T13:32:29Z
    Requested by: 4/ARA/ARA
    Status: Finished
--------------------------------------------------------------------

    Approvals

    This section lists all approval requests of the respective execution.

     --- APPROVALS -----------------------------------------------------

    <all approval requests on this execution, sorted by date ascending>

    -------------------------------------------------------------------

    Example:

    --- APPROVALS -----------------------------------------------------
2014-06-02T10:09:32Z    Approved by 4/ARA1/ARA
-------------------------------------------------------------------

    History

    The execution history section consists of all history records on the execution.

    --- HISTORY -------------------------------------------------------

    <all history records on this execution, sorted by date ascending>

    -------------------------------------------------------------------

    Example:

    --- HISTORY --------------------------------------------------------
2014-06-02T13:31:33Z     Execution "AraDeploy" was created by 4/ARA/ARA.
2014-06-02T13:31:33Z     The workflow execution "AraDeploy"
			  was scheduled for "2014-06-02 13 by 4/ARA/ARA.
2014-06-02T13:31:33Z     The status of execution "AraDeploy" 
			  was changed to "Active".
2014-06-02T13:31:43Z     The workflow "AraDeploy" was executed 
			  by 4/ARA/ARA with run ID 137376276.
2014-06-02T13:34:01Z     The status of execution "AraDeploy" 
			  was changed to "Finished".
--------------------------------------------------------------------

    (line breaks for formatting purposes only)

    Deployment XML

    The deployment XML section consists of the plain XML data related to the deployment.

    --- DEPLOYMENT XML ------------------------------------------------

    <deployment XML>

    -------------------------------------------------------------------

    Note: Password variables are displayed as ****

    Overview

    The overview section consists of workflow or action name, run id and the state of the workflow/action.

    Important! Run id and execution id refer to different concepts. The run id is generated by the Automation Engine when the execution starts. The execution id is the key that uniquely identifies a deployment in CDA.

    --- OVERVIEW ------------------------------------------------------

    <NAME> | <RUNID> | <STATUS>

    ...

    -------------------------------------------------------------------

    Reports

    The reports section consists of all detail reports for each workflow or action of this workflow.

    --- REPORTS ------------------------------------------------------

    RunID: <RUNID> (<NAME>)

    Type: <WORKFLOW> or <ACTION>

    Status: <STATUS>

    Started: <STARTTIME>

    Ended: <ENDTIME>

     

    <REPORTTYPE>:

    <FULLREPORT>

    ------------------

    ...

    -------------------------------------------------------------------

    Example:

    --- REPORTS --------------------------------------------------------
RunID: 137376276 (RM.AUTOMIC.ARADEPLOY.DEPLOY1)
Type: WORKFLOW
Runbook: RM.AUTOMIC.ARADEPLOY.DEPLOY1
    Status: ENDED_OK - ended typically
Started: 2014-06-02T11:32:00Z
Ended: 2014-06-02T11:33:00Z
--------------------------------------------------------------------
RunID: 137376395 (IIS_TO_IISTARGET14)
Type: WORKFLOW
Runbook: IIS_TO_IISTARGET14
Status: ENDED_OK - ended typically
Started: 2014-06-02T11:32:00Z
Ended: 2014-06-02T11:32:00Z
--------------------------------------------------------------------