Skip to main content

Task Elements

A TaskElement models the actual business logic that has to be performed within a business process (e.g. send email, validate availability). A task operates on a DataElement, and will execute some actions.

carRental
└── model
    ├── carRental.xml
    ├── dataElements
    └── taskElements
        ├── TaskElement1.xml
        └── TaskElement2.xml
TaskElement1.xml
<!-- TaskElements should be named in PascalCase -->
<taskElement name="checkCarAvailability">
  <packageName>net.demo</packageName>
  <!-- Target element points to the DataElement that is given as input for this task -->
  <targetElement component="rentalComp" name="Booking"/>
  <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. While this (currently) does not change the implementation, it still is useful to add this information.

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 systemSystemA set of interconnected components that work together to achieve a specific purpose or function. to update the internal state.
ManualIndicates a task is intended for manual operation. For example when triggered by a user of the applicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution..
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 systemSystemA set of interconnected components that work together to achieve a specific purpose or function., 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.
atomicExternalThis task is executed atomically, but its execution is external to the systemSystemA set of interconnected components that work together to achieve a specific purpose or function.. If the task fails, a 'compensating' task is required to revert its changes. Since execution is external this will not create a transaction locally.
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.

Features