Workflow basics

Automation in BMC Atrium Orchestrator comprises workflow processes built by using activities that might call other workflow processes. Workflow processes designed in BMC Atrium Orchestrator produce XML files that are based on Business Process Execution Language (BPEL) and are interpreted and executed by peers—specifically, configuration distribution peers (CDPs) and activity peers (APs)—on a peer-to-peer grid.

Workflow processes can be configured to run on any of the following peers:

• this: The peer that currently hosts the master Job Manager services the request.
• any: Any peer on the grid services the request in a round-robin manner (the default setting).
• best: The grid determines the best peer to service the request, based on a simplistic evaluation model.
• peer: A named peer services the request—for example, Big Peer.

Generally, workflow processes are left at the default any peer setting.

After a workflow process begins, it runs to completion on the same peer. The process terminates in one of the following states:

• Success: The process completes without an unexpected error, although some internal processes might break in an expected way.
• Compensation: The process runs in a compensated state when an adapter cannot execute an operation for any of the following reasons:
  
  • An incorrect element is specified in the request—for example, the target address for the BMC Remedy Action Request (AR) System actor adapter is invalid, the BMC Remedy AR System server is down, or a running instance of the adapter cannot be found
  • The Utility activity tries to divide by zero
  • The peer on which the activity is running fails for some reason, such as a power failure, hard drive crash, and so on
    In this case, the system automatically recognizes that that job did not complete and reassigns the job to another peer.

Activities within a workflow process are usually assignment, flow-control, and decision-making steps, except the Call Adapter activity, which is implemented by using the Adapter Manager and can be executed on a peer different from the one on which the containing workflow process is running. The following figure illustrates a workflow for an HTTP Get action:

BMC Atrium Orchestrator Development Studio workflow design

The Switch and initial two Assign activities run on Peer A; the Call Adapter activity is interpreted on Peer A but the requisite HTTP adapter is on Peer B. At this point, the Adapter Manager delegates the actual HTTP request to the adapter on Peer B. The request is executed from Peer B. In other words, the HTTP server registers Peer B's address as the originator. The response is then sent back via the grid framework to Peer A, which resumes processing, and then moves to the final Assign activity. This switching is an important factor to consider when setting up firewalls or demilitarized zones (DMZs), or evaluating logs or other host data when running a process.

A workflow process uses the following concepts:

• Events: Objects that act as triggers or commands that capture the passing of control to the workflow. Events contain an entry point and optionally a data source, if required. The workflows consume the events that are uniquely identified objects.
• Inputs: A workflow process's specific inputs that are consumed during the processing to generate specific outputs.
• Artifacts: Configuration items, environment variables, and templates. These resources are not consumed during the processing.
• Actions: A workflow process is a collection of actions created by using activities.
• Execution order: The sequence in which processing is accomplished.
• Outputs: A specific outcome that is generated by performing a sequence of actions on specific data.