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: Folder 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 to search for entities and narrow down the results, see: Global Search

Viewing Workflow Executions

See Executing Application Deployments

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 the Behavior of Actions in a Workflow
  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, filesystem...).
      • 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 Automic Continuous Delivery Automation object model. They are used for generic Automic Continuous Delivery Automation processes only (like checking an internal Automic 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

      You can select the current user or one of the user groups the user belongs to as owner (or one of all active user groups for administrators). To assign a different user, edit the entity after creating it.

    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 an Automic 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 Automic 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 Automic 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.

Important! Prerequisite for creating/executing REST Actions: The Webservice Rest Agent must have Java configured for the Agent to reach a Target via HTTPS.

To Configure the Webservice Agent to Reach a Deployment Target via HTTPs with Oracle Java

  1. In your browser, click the padlock in the URL bar.
  2. Export the certificate in .cer format. Example: myfile.cer
  3. Add the certificate to your JVM.
  4. Navigate to the location where the cacerts files are stored, for example: C:\Automic\External.Resources\JDK\jdk1.8.0_101\jre\lib\security\cacerts
  5. In the previously mentioned directory, open the cmd prompt as an administrator and import the myfile.cer file into the cacerts. Use the following command as an example:

    keytool -import -alias example -keystore C:\Automic\External.Resources\JDK\jdk1.8.0_101\jre\lib\security\cacerts -file myfile.cer

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. For more information 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 the Behavior of Actions in a Workflow.

  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.

Defining Dynamic Properties

Workflows allow you to define dynamic properties that can be used in deployments in the Dynamic Properties section. See Working with Dynamic Properties.

You can also search for dynamic properties using the Global Search.

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.

Note: The sort order of prompts is copied to the new Workflow. For more information, see: Creating Dynamic Properties

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) and all of the listed conditions are met.

Conditions to delete entities of type Workflow

See also: