Skip to main content

Task Elements

A TaskElement corresponds to a 'verb' in the literature. A task operates on a DataElement, and will execute some actions. These actions are not atomic by default, but can be configured as such. A Task will take the element it is working on, and return a task result. This result can either be a success, or a failure. While a task will mostly be used in workflows, it is important that tasks are implemented independent of the state of the DataElement it is working on.

space
└── model
├── space.xml
├── dataElements
└── taskElements
├── TaskElement1.xml
└── TaskElement2.xml
TaskElement1.xml
<!-- TaskElements should be named in PascalCase -->
<taskElement name="TaskElement1">
<packageName>net.demo</packageName>
<!-- Target element points to the DataElement that is given as input for this task -->
<targetElement component="space" name="Starship"/>
<taskElementType name="Standard"/>
<transactionType name="atomicInternal"/>
</taskElement>

Task Types

The type of Task is a non-functional identifier that is used to categorize TaskElements based on their purpose or behavior.

TypeDescription
StandardThe default task type. Executes some actions on the target DataElement.
BranchingMultiple outcomes are possible for this task, the implementation chooses which one is applicable.
BridgingA 'bridging' task is one which creates other DataElements, therefore creating a bridge between the target and its relations.
ExternalDescribes tasks which serve as an interface for an external system to update the internal state.
ManualIndicates a task is intended for manual operation. For example when triggered by a user of the application.
UpdaterA task that updates the state of linked elements.
Proxy-

Transaction Types

A TaskElement can have one of the following transaction types:

TypeDescription
atomicInternalThis task is executed atomically: it either fails or succeeds entirely. Since the implementation is internal to the system, the atomicity can be maintained through transactions (e.g. by the JEE framework)
atomicExternalThis task is executed atomically, but its execution is external to the system. If the task fails, a 'compensating' task is required to revert its changes.
aggregateTaskThis task can be split up into smaller subtasks. The task keeps the state of the overall progress, so that it can continue after being interrupted. e.g. a task that reads a CSV file can be split into several subtasks that read segments of 500 lines. The last line that was read is kept. If the task needs to restart, it can start from the last read line.
noTransactionThis task is not transactional. If it fails, no actions are taken to revert any changes. This is the default behaviour.