An EngineService instance contains the information of the Timer that triggers a workflow. In the EJB3 implementation, the TimerHandlerBean implements this trigger by using the EJB TimerService.
- 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.
- status: The status of a timer is either start or stop. An engine will only run a Workflow if its status is start.
- changed: Not used, should always be ‘no’
- busy: Should be ‘no’ when created. This flag is used by the engine when running. It will prevent the engine from starting a new batch on a timer-tick if the previous batch is still being processed. (obsoleted by expanders 3.2.0; busy flag is now ‘in-memory’)
- 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.
- collector: Not used, should always be ‘0’
- workflow: An EngineService should be linked to the correct Workflow
- time window group: Defines the time windows during which the workflow can run
- 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.
- maximum number of nodes: (since expanders 3.2.0) Defines the maximum number of Engine Service nodes that can be spawned.
|Time window group||AllDay|
|Maximum number of nodes||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
|3.0.6||3.1.0||Added field ‘batchSize’|
|201704||3.1.4||‘timeWindowGroup’ implemented for EJB3 stack|
|201712||3.2.0||Added field ‘maximumNumberOfNodes’, obsoleted ‘busy’, EngineNodeService element|