Skip to main content

Workflow Component

Flows as state machines

In order to implement NS applications, traditional business processes have to be translated into state machines. This means that each flow is conceived as a sequence of tasks, represented by TaskElements operating on a single DataElement.

A Task embedded in a flow is executed whenever an instance of the target DataElement is in a particular state (the "begin state"). While the task is being executed, the state is set to a temporary busy state (the "interim state"). When the task has been completed, the state is altered again into an "end state" (in case the task was successfully executed) or a "failed state" (in all other cases).

As a consequence, adding processing functionality to an NS application having DataElements should start with the creation of FlowElements.

Configuring a Workflow


Workflows can be configured in the application model as well. See Workflow Metamodel for more information.

After creating a DataElement, a FlowElement and the necessary TaskElements, the workflow needs to be configured. This configuration is kept in the database and can be input in 2 ways:

  • Through database initialization scripts (preferred way for production)
  • Through the User Interface (good for demos or prototyping)


First is the Workflow DataElement in the workflow Component:

NameA descriptive name for the workflowInvoiceFlow
TargetThe name of the target DataElementInvoice
Component nameThe name of the Component containing the FlowElementinvoices
Flow element nameThe name of the FlowElementInvoicing
Responsible (optional)The name of a user whose access rights will be used to execute the tasksadmin
Sequencing strategyEither default or greedy (see below)default


Next, you will need to define an EngineService. The EngineService configures the timer that polls for new DataElement instances to process.

NameA descriptive name for the workflow. If multiple engineServices are defined, each should have a unique name. The name of the engineService is used to keep the timers of different engine services apart.InvoiceService
StatusThe status of a timer is either start or stop. An engine will only run a Workflow if its status is start.start
Wait timeTime (in seconds) between 2 respective timer-ticks. Note that defining a small wait time will increase the frequency of log-statements by the EngineService.30
WorkflowA link to the previously described workflowInvoiceFlow
Time window group (optional)Defines the time windows during which the workflow can runAllDay
Batch sizeDefines the maximum number of instances that the engine takes for each batch. If this number is undefined or 0, the engine will take all instances it can process.50
Maximum number of nodesIn a multi-node system, this defines the maximum number of times this EngineService can be spawned over multiple nodes that can be spawned.3
EngineService status

The status field is used to enable and disable engines. Setting the status to stop will not stop the timer from triggering. Rather, at each timer-tick, the engine will check whether the status is start in order to continue


StateTasks define the transitions within a Workflow. You will need at least one StateTask for your Workflow to start processing DataElement instances.

NameA descriptive name for the State Task.InvoiceSender
ProcessorA reference to the target Task Element defined as its component and element name, separated by a colon (:).invoices:InvoiceSender
ImplementationThe fully qualified java class name of the implementation class for this task. The expanders generate 2 implementation classes by default with postfixes -Impl and -Impl2. If the task has no implementation, you can enter the value 'none'.net.demo.InvoiceSenderImpl
ParamsSet as 'default', or configure the Parameter Object.default
Begin stateThe state at which to execute this task.Initial
Interim stateThe state which is set during the execution of the task.Sending
Failed stateThe state to which the status field is set if the task fails.SendingFailed
End stateThe state to which the status field is set if the task succeeds.Sent
WorkflowA link to the previously described workflow.InvoiceFlow
Max concurrent tasksDefines the maximum number of parallel executions that can run in parallel for a given task. If this is not defined, it is presumed the task is not serializable and so the maximum number will be 1.5
Timeout (optional)Time (in ms) that the Task has to execute. If expired, the Task will fail.60000

Default or Greedy Sequencing

If we have 3 sequential StateTasks and 3 instances in the first beginState, there are 2 ways to process these instances:

  1. Default: Execute the first Task on each instance, then the second and then the third
  2. Greedy: Execute each Task in sequence on the first instance, then on the second and then on the third

With greedy sequencing, the time between a instance being picked up and it reaching the final state will be smaller. This can lead to a better response time, especially with a lot of instances. It will take longer to reach the final instance though.