Working with Workflows

As an Application Developer, you create, design, and execute Workflows. As an Operator, you might need information about executing Workflows in support cases.

In the CDA Deployment Model, Workflows define the sequence in which the Application Components are deployed to their designated endpoints (Deployment Targets). As your Application consists of different Components, the top level of the Workflow (Application Workflow) represents your Application architecture. The Subworkflows (Component Workflows) are used to deploy the individual Components. Each Component has a Workflow that contains the sequence of Actions that are required to deploy that Component. You can quickly define your Component Workflows with pre-defined Actions.

Important! The actions that you can perform depend on your folder permissions. See: Assigning Release Automation Permissions.

This page includes the following:

Viewing Workflows

Workflows are managed and displayed within the Workflows main section.

The Workflows list displays the following information in a table:

Tip: For more information about how search for entities and narrow down the results, see Advanced Search.

Creating Workflows

Recommended Design Sequence

The order in which your Workflow should be designed is as follows:

  1. Create the Application Workflow, which is the top-level object controlling the deployment of a single Application. Application Workflows orchestrate the deployment of Application Components via Component Workflows. At this level, there is no access to the static or dynamic properties of anything other than the Workflow itself. See Creating an Application Workflow.
  2. Add the Component Workflows to the Application Workflow. See Adding Component Workflows
  3. Define the properties for the Components. See Defining Properties of Component Workflows and Actions
  4. Add the actions to the Component Workflows. See Adding Actions to Component Workflows

Creating an Application Workflow

  1. You can create Workflows from:
  2. Click the Create button in the toolbar. The Create Workflow is displayed.
  3. Provide the following information:

    • Name: Enter a name for the Workflow. If you are creating the Workflow from the Applications section, it is prefixed with the Application name.

      Note: Workflow names are rendered to the folder name containing the Workflow. The names 'C 2', 'C_2' and 'C-2' would lead to the same name of the AE Workflow object 'C_2'. You can improve readability when you avoid names where the only distinction is a special character.

    • Type

      Already filled in if you are creating the Workflow from the applications section. After creating a Workflow, you cannot change its type. 

      The list contains all custom workflow types that are defined in your system. The delivered types are: General, Install, Uninstall, and Provisioning.

      Note: Provisioning Workflows enable the execution of Application Workflows without the context of a Deployment Profile (Environment and Deployment Targets). These entities are created by the Workflow in a full stack scenario.

      Custom types can be one of two base types:

      • Application (Install, Uninstall, Provisioning types). These types apply to anything that is system-based (server or file system, for example).
      • General (all other types). General workflows are available as an option for more generic tasks (as the name implies), such as a single start-point for larger-scale process automation, maintenance tasks, or for anything that does not require access to the Continuous Delivery Automation object model. They are used for generic Continuous Delivery Automation processes only (like checking an internal Continuous Delivery Automation resource). Typically, this would mean that any actions outside of a deployment would be executed here.
    • Application: Select the Application of the Workflow. This applies only to Application-type Workflows. If you choose a Type that has a "general" base type in its type definition, the Application box disappears.
    • Folder: The folder of the Workflow. If the type is an Application Workflow, the folder of the Application is used.
    • Owner: The owner of the Workflow

    The Workflow designer window appears for you to add the corresponding Component Workflows, the order of execution and other specifications for the Workflow.

    Note: The Workflow designer is part of the Process Assembly perspective. For practical reasons, the Building Workflows section only describes the steps a Continuous Delivery Automation user has to take to create and design CDA Workflows. You can find more information about the Process Assembly in the specific section: About Process Assembly

Adding Component Workflows

This section describes how to add Component Workflows to an Application Workflow.

Component Workflows are the core entities of Continuous Delivery Automation and the focus point of the CDA object model, as from Components it is possible to reference the properties (dynamic or static) of any related object.

As an Application can contain many Components, so an Application Workflow can contain many Component Workflows. However, it is possible for one Component to have many Component Workflows which share only the Component static and dynamic properties.

To Add Component Workflows to an Application Workflow

  1. Open the Application Workflow.

  2. Click the Objects button in the Workflow toolbar to open the Objects pane. It lists all executable objects available in the client you are logged into and that you can use in the Workflow.
  3. Select the Components tab.

    Note: If one or more Components (or any Application containing them) are archived/restored while building the Application Workflow, they must be reopened to show the correct entities in the Components tab.

  4. Select the appropriate Component Workflows in the Objects pane and drag-and-drop them on the editor.

  5. You can do one of the following:

    • Create a blank Component Workflow. If you select this option, you will have to define the Actions of the Component Workflow at a later point in time.

      Note: By default, an Action to get the Artifact is added and linked to the start node. This Action is only executed if an Artifact is assigned to the Component in the Deployment Package.

      • The promptsets of the Action will be populated according to the Component type.
      • The Component types Tomcat and JDBC are supported:

        JDBC --> Get_Artifact --> Filter Files --> Includes : **/*.sql

        JDBC --> Get_Artifact --> Filter Files --> Includes : **/*.war

    • Copy an existing Component Workflow. Select this option if you want to add an already configured Component Workflow which is being used for another Application Workflow.
  6. Arrange the Component Workflows in the editor.

    This has no effect on the synchronization. It is simply for design purposes; it helps you visualize the Workflow logic.

  7. Link the Component Workflows. This converts the Component Workflows into tasks and creates dependencies between them.

    If you do not link the tasks and you execute the Application Workflow as is, the tasks (Component Workflows) execute simultaneously right at the beginning.

    1. Hover the mouse over the task to select it. It is encircled in dark yellow and left and right arrows are displayed.
    2. Click and hold the arrow at the end that you want to link.
    3. Draw a line between the selected and the target task and release the mouse button. The two boxes are now linked.

      Tip: Seek efficiency by executing Component Workflows in parallel whenever possible. In other words, when the Components do not overlap or interfere with one another.

    When the relationship is established, many functions are available that help you fine-tune the dependencies between tasks. For example, you can condition the execution of a downstream task on the status of the upstream one.

  8. Save the Workflow.

Adding Actions to Component Workflows

Each Component constitutes an individual process that contains the various Actions necessary to deploy that Component. This section describes how to add the required Actions to the Component.

You can add any number of individual Actions to a Component. For example, for a Webapp Component, you may want to add Actions to undeploy, deploy, stop, start the Application, and so on. Each Action also contains a Workflow called "Action Workflow" with two processes: UNIX and Windows. This is how Continuous Delivery Automation is cross-platform, as UNIX and Windows processes are supported.

An Action does something to a Component: it deploys, undeploys, stops the Application...An Action triggers an AE job that contains syntax which can be interpreted by the system. It is supplemented by parameters to ensure that the Agent has the necessary information to carry out the deployment, like filepath, names of servers, usernames, passwords...

When an Action executes for a Workflow, the Action is passed with the parameters to the Agent, which then executes the script on the system. The deployment takes place.

Typical Component Workflow

This is how a typical Component looks like: it is a set of Actions executing sequentially on the Component being deployed.

Graphic depicting typical Component Workflow

In the example above there are five Actions:

  1. A source control export Action is used to export the Component from source control (assuming you have a product like SVN in your Environment).
  2. The second Action makes changes to the Components. This could be an amend to a .war file, for example.
  3. The third Action removes the web Application that is currently deployed.
  4. The fourth Action re-deploys the webapp.
  5. The fifth Action restarts the Application server where the webapp Component has been deployed.

Note: Hundreds of predefined Actions are available for you to use.

To Add Actions to a Component Workflow

  1. Double-click the Component Workflow to open it.

  2. Click the Objects button in the Workflow toolbar to open the Objects pane. It lists all the executable objects available in the client you are logged into and that you can use in the Workflow.
  3. Select the Actions tab. Here you find the list of available Actions.

    Note: some folders containing out-of-the-box Actions specific to web servers, files, databases, and version control among others are displayed with your custom Actions. To know more about how to create custom Actions, see Working with Actions.

  4. Select the required Actions in the Objects pane and drag-and-drop them on the canvas.

    Important!It may happen that an alert icon appears inside the Action after dropping it. This indicates missing information which has to be added in the properties tabs. For example, when the Component does not have a dedicated field in the custom properties for a specific element, like a script URI. If so, the missing information must be added by clicking the corresponding label. For more information, see: Defining Properties of Component Workflows and Actions

  5. Arrange the Actions in the editor.

    This has no effect on the synchronization whatsoever. It is simply for design purposes; it helps you visualize the Workflow logic.

  6. Link the Actions.

    This converts the Actions into tasks and creates dependencies between them.

    If you do not link the tasks and execute the Component Workflow as is, the tasks (Actions) execute simultaneously right at the beginning.

    1. Hover the mouse over the task to select it. It is encircled in dark yellow and left and right arrows are displayed.
    2. Click and hold the arrow at the end that you want to link.

    3. Draw a line between the selected and the target task and release the mouse button. The two boxes are now linked.

      Note: We recommend seeking efficiency by executing deployment Actions in parallel whenever possible. In other words, when the Actions do not overlap or interfere with one another.

    When the relationship is established, many functions are available that help you fine tune the dependencies between tasks. For example, you can condition the execution of a downstream task on the status of the upstream one.

  7. Save the Workflow.

Editing the Properties of Workflows

To change the properties of a Workflow you can use one of the following:

You can change the following Workflow properties:

Workflow Definitions and Custom Types

All Workflow definitions are stored in objects and are assigned a CDA type that represents one of two base types "Application" or "general". The Workflow custom types that are delivered with the CDA  Application are:

You can use these or create your own custom types instead or in addition to these.

Executing Workflows

After building and configuring the Application Workflow you can execute it.

To Execute Workflows

  1. There are two starting points to execute Workflows:
    • From the Workflows list.
    • From the All Workflows list in the Application.
  2. Click the Execute button in the toolbar. The Schedule Workflow Execution dialog is displayed.

    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

  3. Click Execute.

Note: When executing CDA Workflows from the Process Assembly you are redirected to the Release Automation perspective. The sub-menu options Execute Once, Execute Recurring and Restart cannot be triggered for CDA Workflows.

Duplicating Workflows

You can duplicate General Workflows, Application Workflows and Component Workflows. Application Workflows and their related Component Workflows can be duplicated within an Application or into another Application.

Important! Component properties are not updated when duplicating Application Workflows. Consider creating new properties for the duplicate instead of deleting/editing the existing ones, since this action may have an impact on the original Workflow.

To Duplicate General Workflows

  1. Open the Release Automation perspective.
  2. Click the Workflows tab.
  3. Right-click one of the Workflows of type General and select Duplicate. The Duplicate Workflow dialog is displayed.
  4. Optionally, enter a new name for the Workflow or edit its title.
  5. Optionally, select a different folder, owner or both.
  6. Click Create.

To Duplicate Application Workflows within the Same Application

  1. Open the Release Automation perspective.
  2. Open an Application and select one of its Workflows or click the Workflows tab.
  3. Right-click one of the Workflows of type Install and select Duplicate. The Duplicate Workflow dialog is displayed.
  4. Optionally, enter a new name for the Workflow or edit its title.
  5. Leave the default Target Application as is.
  6. Optionally, select a different folder and/ or owner.
  7. Click Create.

To Duplicate Application Workflows into a Different Application

  1. Open the Release Automation perspective.
  2. Open an Application and select one of its Workflows or click the Workflows tab.
  3. Right-click one of the Workflows of type Install and select Duplicate. The Duplicate Workflow dialog is displayed.
  4. Optionally, enter a new name for the Workflow or edit its title.

    Note: Application Workflows to be duplicated in a different Application can keep their original names.

  5. Select the target Application where the new Application Workflow will be saved.
  6. Optionally, select a different folder and/ or owner.
  7. Click Next.
  8. Assign the Component Workflows of the duplicated Application Workflow to one of the existing Components in the target Application.

    Note: If you leave a Component Workflow unassigned, it will not be copied to the target Application. Leave all Component Workflows unassigned to duplicate the Application Workflow without Component Workflows.

  9. Optionally, enter a title for the new Component Workflows.
  10. Click Create.

Deleting Workflows

Right-click the entity and select Delete.

Important! Deleting a Workflow deletes all executions started by this Workflow and the Workflow definition.

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 Workflow