Workflow Launcher Action Plugin



Overview

This action plugin launches one workflow from within another. It is similar to the Sub-workflow plugin, but it differs in that Workflow Launcher simply launches another workflow and then the current workflow immediately proceeds. This behavior is asynchronous compared to Sub-workflow, where the current workflow will wait for the launched workflow to return before proceeding. A Workflow Launcher step is Complete when it has successfully launched the workflow it is configured to, whereas a Sub-workflow step is Complete when the sub-workflow it launched has completed its execution.

Saved Parameters Description

  • Name: The name used to identify a saved Workflow Launcher configured instance.
  • Work-order_description: Describes this work order.
  • Associated with Workflow (ID): Drop-down box to select which workflow will be launched (can not be modified after selection).
  • Comments: Comments about this action template.
  • Use true name: Force using the work order description without adding start time information.
  • Master ID: Can be used to specify a group of work orders for the purpose of visualization.
  • Wait for completion: Wait until the launched work order completes.
  • Polling frequency: How often the remote server is polled for files. Default is 1 second.
  • Run with dedicated execution resource: If this box is checked, the Workflow Launcher will launch a work order for the associated workflow and will spawn a new dedicated worker for that workflow. That dedicated worker will only work on step from that work order, however those step can still use the other common workers when they are available. This behavior is the same as the launch with dedicated resources check box from the UI workorder start screen
  • Execution Priority: An integer that indicates the priority level to be used for the work order. By default 2 (medium). Other valid values are for fair priorities: 1 for low and 3 for high. For preemptive priorities, any negative number can be used, the greatest going first. 0 being the absolute preemptive priority. For example. -100 would go before -1000.
  • Sub-workflow inputs mapping: These will match the inputs required by the workflow associated in the dropdown box above.
  • Saved inputs: Provides the ability to save in the template the values for some inputs requested by the workflow specified.

Inputs Description

If the default template is used, for example, the workflow to be launched is not set at design time.

  • Workflow_ID: The ID for the workflow to be launched.
  • WorkOrder_Description: Description of the Work Order – will appear in the status when running.
  • Workflow_Parameters: A hash of the inputs for that workflow.

  • If a template is used specifiying the workflow to launch, then the inputs will be determined by how the action template was set-up and will correspond the inputs required for that workflow, minus the inputs provided as saved-inputs in the template definition.

  • Running as user: By default the workflow will run as the SYSTEM user. This variable allows to specify an alternative user.

Outputs Description

  • WorkOrder_ID: The actual work order ID assigned by Orchestrator for the launched workflow. That ID can be used to track the progress of the execution of the spawned work order ColumnToListValueFrom (if any).
  • WorkOrder_Status: The status of the spawned work order at the time the steps complete. In most cases this status should state In Progress if the action completex successfully. If the action fails, however, this status will be helpful in determining the cause of the failure (cancellation, error, or another reason).

Supported Actions

None

Dependencies

None

Operating Instructions

This action very simply launches another workflow. This is done asynchronously, meaning that once this step triggers, it simply launches the workflow and the workflow continues. It does not wait for the execution of the launched workflow to complete.
Note: The work_order ID of the launched workflow is returned as an output to allow it to be tracked.
Tracking can be done either using the GUI: http://orchestrator_url/work_orders/; for example, http://orchestrator.aspera.us/work_orders/130031 will return the details for that work order (the one with ID 130031). Alternatively, querying the status of the spawned work order can be done using the API. The URL for the request is then described in the API section of the documentation, in details. A basic status check would look like the following: 
http://orchestrator.aspera.us/workflow_reporter/work_order_status/130031?login=admin&password=aspera
The result is be an XML file detailing step-by-step status for that work order.