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)
Workflow
First is the Workflow DataElement in the workflow Component:
| Field | Description | Example |
|---|---|---|
| Name | A descriptive name for the workflow | InvoiceFlow |
| Target | The name of the target DataElement | Invoice |
| Component name | The name of the Component containing the FlowElement | invoices |
| Flow element name | The name of the FlowElement | Invoicing |
| Responsible (optional) | The name of a user whose access rights will be used to execute the tasks | admin |
| Sequencing strategy | Either default or greedy (see below) | default |
EngineService
Next, you will need to define an EngineService. The EngineService configures the timer that polls for new DataElement instances to process.
| Field | Description | Example |
|---|---|---|
| Name | A 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 |
| Status | The status of a timer is either start or stop. An engine will only run a Workflow if its status is start. | start |
| Wait time | Time (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 |
| Workflow | A link to the previously described workflow | InvoiceFlow |
| Time window group (optional) | Defines the time windows during which the workflow can run | AllDay |
| Batch size | Defines 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 nodes | In a multi-node system, this defines the maximum number of times this EngineService can be spawned over multiple nodes that can be spawned. | 3 |
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
StateTasks define the transitions within a Workflow. You will need at least one StateTask for your Workflow to start processing DataElement instances.
| Field | Description | Example |
|---|---|---|
| Name | A descriptive name for the State Task. | InvoiceSender |
| Processor | A reference to the target Task Element defined as its component and element name, separated by a colon (:). | invoices:InvoiceSender |
| Implementation | The 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 |
| Params | Set as 'default', or configure the Parameter Object. | default |
| Begin state | The state at which to execute this task. | Initial |
| Interim state | The state which is set during the execution of the task. | Sending |
| Failed state | The state to which the status field is set if the task fails. | SendingFailed |
| End state | The state to which the status field is set if the task succeeds. | Sent |
| Workflow | A link to the previously described workflow. | InvoiceFlow |
| Max concurrent tasks | Defines 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:
- Default: Execute the first Task on each instance, then the second and then the third
- 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.