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.