Workflow Component
Workflow modeling has been reworked. We recommend using the process-automation component instead of
the workflow-component. While most features are still available, they should be reconfigured. Consult the process
automation docs for more information.
Configuring a Workflow
Workflows can be configured in the applicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. 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:
| FieldFieldA property of a DataElement expanded to a database column and user interface input element. | 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 elementFlow Element (FlowElement). [Deprecated ] A deprecated process modeling construct describing state transitions targeting a status field on a DataElement. 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.
| FieldFieldA property of a DataElement expanded to a database column and user interface input element. | 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 systemSystemA set of interconnected components that work together to achieve a specific purpose or function., this defines the maximum number of times this EngineService can be spawned over multiple nodes that can be spawned. | 3 |
The status fieldFieldA property of a DataElement expanded to a database column and user interface input element. 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.
| FieldFieldA property of a DataElement expanded to a database column and user interface input element. | 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 expandersExpanderA unit of generation that combines a data tree instance (functional M1 model) with a template to generate an artifact. 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 fieldFieldA property of a DataElement expanded to a database column and user interface input element. is set if the task fails. | SendingFailed |
| End state | The state to which the status fieldFieldA property of a DataElement expanded to a database column and user interface input element. 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.