Automated steps

A workflow might have steps that can be performed without the need for user interaction, such as a job that can be submitted without user input. If so, you can designate the step as an automated step in the workflow definition file. Doing so instructs the Workflows task to run the step automatically, as soon as any prerequisite steps in the workflow are completed. By including one or more automated steps in a workflow, you help to simplify the user experience.

In the Workflows task user interface, automated steps are indicated to users in the following ways:
  • In the Workflow Steps table, the column Automated indicates whether a step is automated, based on how the step is defined in the workflow definition.
  • In the Workflows task main page, when an automated step is performed, the workflow status is indicted as Automation in Progress.

A workflow can consist of both automated steps and non-automated (manually performed) steps.

How the user interacts with an automated step

To perform an automated step, the user selects the Perform action in the Workflow Steps table, as is done for manual steps. For an automated step, the Workflows task presents the user with a dialog window to confirm whether the step and any subsequent automated steps should be performed automatically. Alternatively, the user can choose to perform the step manually, by selecting an option in the dialog window that is called Manually perform the selected step.

When started, an automated step—or series of automated steps—can run to completion or until stopped by another condition, such as a user stop request or a step error. Specifically, a workflow with automated steps can run until one of the following conditions occurs:
  • Completion of all subsequent steps.
  • Processing reaches an automated step for which one or more required variables are not satisfied.
  • Processing reaches a non-automated step in the sequence of steps.
  • Processing reaches an automated step that is not currently eligible for automatic processing. That is, the step is Unassigned, Assigned, Not Ready, or Submitted.
  • Processing is stopped through a user request.
  • An error is encountered.

A workflow that is comprised entirely of automated steps can run to completion without user intervention.

Tracking the progress of automated steps

For workflows that contain automated steps, z/OSMF creates notifications and history entries to inform step owners of the automation progress.

At the completion of an automated step or a sequence of automated steps, z/OSMF creates a notification to inform the step owner of the step status. If processing reaches a manual step that requires user interaction before the workflow can continue, z/OSMF creates a notification for the step owner to prompt for action. Similarly, if an automated step is stopped or fails for any reason, z/OSMF sends a notification to the step owner. In z/OSMF, users can access notifications through the Notifications task.

During the processing of an automated step, z/OSMF updates the workflow history to indicate the key checkpoints in the workflow progress, such as:
  • Completion of the automated step
  • Completion of all automated steps in the workflow
  • Automation is started or stopped through user request (and by whom)
  • An error is encountered during the processing of an automated step.

Automation progress is not displayed (in terms of step completion check marks) until the user refreshes the display.

Users of the Workflows task can view the details of the step status in the Workflow History table.

Design considerations for automated steps

Consider a step to be eligible for automation if it requires no user input at all, or if all of the required inputs can be supplied to the workflow at creation time, in the form of a workflow variable input file.

When you code the step element, you can specify whether the step is automated (that is, can be performed automatically by the Workflows) by including the autoEnable attribute on the step element (<step>). Set this attribute to true or false, as needed. By default, the autoEnable attribute is false. Figure 1 shows an example.

Figure 1. You can designate a step as automated by adding the autoEnable element to the <step> element tag.
<step name="Sample_Automated_Step" optional="true">
<title>This is a very simple JCL job</title>
<description>This optional step submits an empty job using IEFBR14.</description>
<instructions>This step is performed automatically.</instructions>
<weight>1</weight>
<skills>Submit a job to run on z/OS</skills>
<autoEnable>true</autoEnable>
<template>
    <inlineTemplate>//STEP1      EXEC  PGM=IEFBR14
//SYSEXEC   DD   DUMMY
//* PRINT DD SYSOUT=A
/*
        </inlineTemplate>
        <submitAs>JCL</submitAs>
     </template>
</step>

For any automated steps that you provide, it is recommended that you use the description tag to provide the user with enough information to understand the implications of allowing the step to run.

When automated steps are ordered consecutively in a workflow, a request to run the first automated step begins a process in which each subsequent automated step can run to completion, or until one of the steps encounters a condition that stops the processing of steps. For this reason, it is recommended that you group automated steps in the workflow definition file together, to take full advantage of this cascading behavior.