Arguments & Variables

Workflows and activities process an input in order to generate an output. Along that way they might need to store certain data. All of this is achieved, using arguments (argument) and variables (variable).

Arguments

Each workflow and activity have a specific set of ingoing and outgoing parameters defining their respective contract. In Orchestrator these parameters are called Arguments.

Variables

Additionally, a workflow might need to store certain data temporarily in a variable to maintain information on the current state of the workflow. In order to store such information Orchestrator uses Variables.

Structure

A variable is identified by the following characteristics:

Name: The name of the variable, used to access the value stored within it.
Type: The type (in .NET notation) of the value stored within the variable.

An argument is a superset of a variable and contains these additional fields:

Direction: Determines if the argument is an ingoing or outgoing parameter (In or Out).
Mandatory: Determines if the argument is mandatory or not for the execution of a workflow / activity. (Only relevant for in-arguments)

Example

Consider an activity called Sum adding two given numbers and returning the result. The arguments of this activity would potentially look like this:

Name	Type	Direction	Mandatory
a_summand1	System.Int32	In	true
a_summand2	System.Int32	In	true
a_sum	System.Int32	Out

Name

Type

Direction

Mandatory

a_summand1

System.Int32

true

a_summand2

System.Int32

true

a_sum

System.Int32

Out

Now consider a workflow that is intended to add three numbers, only using the above Sum activity. The workflow would have a similar set of arguments as the activity, only adding a third summand:

Name	Type	Direction	Mandatory
wf_summand1	System.Int32	In	true
wf_summand2	System.Int32	In	true
wf_summand3	System.Int32	In	true
wf_sum	System.Int32	Out

Name

Type

Direction

Mandatory

wf_summand1

System.Int32

true

wf_summand2

System.Int32

true

wf_summand3

System.Int32

true

wf_sum

System.Int32

Out

Additionally, the workflow would need to have a variable to store the interim result of the addition of the first two values:

Name	Type
var_interimSum	System.Int32

Name

Type

var_interimSum

System.Int32

The workflow could then consist of two separate Sum activities. The flow could then look like this:

Pass wf_summand1 and wf_summand2 to first Sum activity
Store result of first Sum activity in var_interimSum
Pass var_interimSum and wf_summand3 to second Sum activity
Store result of second Sum activity in wf_sum

In this way, wf_sum would - given successful execution of both activities - hold the sum of all three in-arguments.