Input and output parameters are always typed. Currently the following data types are available:

  • String
  • Bool
  • Long
  • Double

Values may be assigned to input parameters by using the Java Expression Language which is explained in more detail in the next section.
Additionally, parameters that carry the specifier "Uri" at the end of their name require additional explanation provided in the Uri Parameters section.

Please note that string input parameters for tasks can be tagged as the sub-type storage. This implies that users are able to select a storage input parameter directly from a dropdown. This dropdown contains all of those storages which have been defined as globally compatible parameters.

Please note that the use of Expression Language is, as of release 19.1, no longer necessary for the Workflow Designer. It is however optional. Prior to 19.1, values for task input parameters could only be assigned using Expression Language. The Workflow Designer now allows the user to select from a pool of compatible workflow variables via a dropdown. Only users granted special rights are able to edit the (resulting) expression language for a task input parameter.

Expression Language

The Expression Language (short form: EL) offers a means of enabling the front end (client) layer to communicate information to the backend (server) layer. In context of VidiFlow's workflow engine the Designer provides the client and the BPM engine the server component.
By using EL, to the following options are possible in VidiFlow's Workflow Designer:

  • Dynamically assign data to workflow variables
  • Dynamically access data stored in workflow variables

In addition to assigning and reading values, it is possible to combine data access with more elaborate operations that are covered in the scope of the EL such as

  • Arithmetic operations
  • Executing public and static methods on Java objects

The basic concepts of the Expression Language are expanded upon in the following sections.

Immediate and Deferred Evaluation

EL expressions can be immediately evaluated or deferred for later evaluation.
For expressions marked for immediate evaluation, the evaluation happens right away when the server renders a web page for the first time. Expressions marked for immediate evaluation are always read-only, thus they can only be used as r-values in an assignment (see below).
The syntax for immediate expression evaluation requires curly braces around the EL expression prefixed with a dollar sign:

Alternatively, a delayed or deferred evaluation leaves the point in time in which the expression should be evaluated up to the underlying application. This means that expressions for deferred evaluation can resolve to different results depending on when the expression is modified and when it is being read. Thus expressions that are evaluated deferred are read- and writable during their lifecycle making them usable as either l- or r-values (see below) and providing the capability to alter the expressions evaluation during its lifecycle.
The syntax for the evaluation of a deferred expression requires curly braces around the EL expression and be prefixed with a hash sign:

Value and Method Expressions

While value expressions are used to retrieve or store a value under a given name, method expressions provide access to methods which in turn might return a value. Within the scope of workflow design, there is typically no requirement for using method expressions.

Expression Language in the Workflow Designer

In a typical use case, an expression resolves to an object which dynamically stores information such as the value of a workflow variable in a particular workflow instance. Hence variable assignment and accessing requires the use of the #{<expression>} syntax due to the fact that write operations can only be performed on expressions that are evaluated in a deferred manner. Examples for variable assignments in the Workflow Designer are depicted below.

As shown in the example above, the task offers a locally scoped output parameter named "ContentString". It is being accessed by usage of a deferred expression evaluation since its runtime value needs to be read after the task was executed. For simplification of usage, accessing the "ContentString" is an operation that does not allow manipulation at this point.
The dynamic value of "ContentString" is assigned to a globally accessible variable named ContentString_1ueso0c which is a globally scoped variable which is available for further evaluation or manipulation in the workflow.

Examples of EL Expressions

Examples of EL Expressions

EL Expression


${1 > (4/2)}


${4.0 >= 3}


${100.0 == 100}


${(10*10) ne 100}


${'a' < 'b'}


${'hip' gt 'hit'}


${4 > 3}


${1.2E4 + 1.4}


${3 div 4}


${10 mod 4}


${!empty param.Add}

False if the request parameter named  Add  is  null  or an empty string.


The context path.


The value of the  numberOfItems  property of the session-scoped attribute named cart.


The value of the request parameter named  mycom.productId.


The host.


The value of the entry named  deptName  in the  departments  map.


The value of the request-scoped attribute named javax.servlet.forward.servlet_path.


Gets the value of the property lName from the customer bean during an initial request. Sets the value of lName during a postback.


The return value of the method calcTotal of the customer bean.

The table above as well as additional information, can be found at the Java Expression Language Tutorial web site:

Java Expression Language Documentation Link

Uri Parameters

VidiFlow employs a dedicated concept for addressing objects like as domain objects such as Videos, Metadata, Storages, or physical resources such as files and folders.
References are generally made by Uniform Resource Locators (URIs) where the name of the URI parameter indicates what the reference is made to and what schemes are acceptable for values during runtime.
Currently the following URI naming patterns are understood within the workflow engine, whereas the prefix before the "Uri" signifier indicates the family of the URIs' content. The URI scheme offers further levels of distinction within a URI family. Please note that there might be ab arbitrary prefix before the URI family name to indicate what the URI stands for.

Naming Pattern


Possible schemes


Most general URI from which all other URI families are derived



Signifies objects in the VidiFlow domain such as Items, Storages, Shapes, Collections.

  • pf://


Signifies references to physical files and folders

  • smb://
  • file://
  • ftp://
  • ftpe://


Signifies references to objects in a worker-based VPMS system

  • vpms://

For some parameters a URI can only refer to a single dedicated family of URIs, for others, the value at runtime can be one of different families. The general rule is that the names of Uri parameters capture the top-level family in the URI hierarchy that is applicable to the runtime value.
For example consider the following scenarios and the appropriate URI naming:

  • PlatformUri
    • Create an object in Platform and the task has an output parameter referencing the created object
    • Do an operation on an object in the Platform repository
  • PhysicalUri
    • Transfer a file using lower level OS functions only without any knowledge of objects in the repository
    • Create a folder
  • ObjectUri
    • Transcode a file to another format. The source for the transfer might be specified in the form of a domain object such as a video item that is resolvable to one or multiple source files for transcoding. Alternatively, the source of the transfer might be specified as a physical path to the source file. Since the parameter value referencing the transcoding source can be of either one of the PlatformUri family or the PhysicalUri family the parameter name captures this by using the most general ObjectUri family notation.
  • VpmsUri
    • Update metadata of an object in the worker-based VPMS database.