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.

Type	Description
Standard	The default task type. Executes some actions on the target DataElement.
Branching	Multiple outcomes are possible for this task, the implementation chooses which one is applicable.
Bridging	A 'bridging' task is one which creates other DataElements, therefore creating a bridge between the target and its relations.
External	Describes tasks which serve as an interface for an external system to update the internal state.
Manual	Indicates a task is intended for manual operation. For example when triggered by a user of the application.
Updater	A task that updates the state of linked elements.
Proxy	-

Transaction Types

A TaskElement can have one of the following transaction types:

Type	Description
atomicInternal	This 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). Note that these transactions impose restrictions on the task. The transaction timeout may prematurely terminate a task if it takes too long to complete.
atomicExternal	This 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. Since execution is external this will not create a transaction locally.
aggregateTask	This 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.
noTransaction	This task is not transactional. If it fails, no actions are taken to revert any changes. This is the default behaviour.