The Taskana TASKANA Adapter syncs tasks between TASKANA and an external workflow system, e.g. Camunda BPM. In this document, we call a task in the external workflow system 'referenced task'.
The adapter periodically performs the following work::
retrieve new referenced tasks and create corresponding Taskana TASKANA tasks
* retrieve newly created referenced tasks
* get the task’s including desired process variables
* map referenced task to Taskana TASKANA task
* create an associated Taskana TASKANA task
* remember the tasks created in the adapter’s databasedelete outbox entry for the successfully created TASKANA task
retrieve finished referenced tasks and terminate corresponding Taskana TASKANA tasks
* retrieve finished referenced tasks
* terminate corresponding Taskana TASKANA tasks
retrieve finished Taskana TASKANA tasks and complete corresponding referenced tasks
* retrieve finished Taskana TASKANA tasks
* complete the corresponding referenced tasks in the external system
retrieve claimed TASKANA tasks and claim corresponding referenced tasks
* retrieve claimed TASKANA tasks
* claim the corresponding referenced tasks in the external systemcleanup Adapter’s database tables
* delete aged entries from the adapter’s database tables
retrieve TASKANA tasks where the claim was cancelled and cancel the claim of the corresponding referenced tasks
* retrieve cancel claimed TASKANA tasks
* cancel claim the corresponding referenced tasks in the external system
The adapter is structured in an adapter proper that controls the logic and two SPISPIs:
The SystemConnector SPI that connects to the external system and
The TaskanaConnector SPI that connects to the taskana TASKANA system.
The component structure of the adapter is as follows
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes
...
To determine this interval, transactional behavior must be taken into account. Due to transactions, a task that was created at a specific instant may become visible only when the transaction is committed.
In the extreme case this is the maximum transaction lifetime. As a consequence, the specified interval is not between the last query time and now, but between (the last query time – maximum transaction lifetime) and now.
Using default values to illustrate: Queries are performed every 10 seconds. The default maximum transaction lifetime is 120 seconds. This is, the adapter has to retrieve all tasks that were created in the last 130 seconds.
In the result, the query returns many tasks that have already been processed by the adapter. To cope with this problem, the adapter uses the TASKS table of its database to keep track of the tasks that are already handled.
Tasks that are not found in this table are added to the table and a corresponding taskana task is started. Tasks that are found in the table are ignored, they are duplicates.Variables
When the adapter finds a referenced task for which a TASKANA task must be started, it retrieves the desired variables of the referenced task's process. These variables are stored in the custom attributes of the corresponding taskana task in a HashMap. The names of the variables, prefixed with “camunda:” (e.g. camunda:someVariable) will be the keys. The prefix is used to determine which custom attributes of the TASKANA task should later be played back to camunda . The values are of type String that and contain the Json JSON representations of the variables.Workbaskets
Task / workbasket mapping has been kept to a minimum. If the adapter creates a taskana task, it puts it into the workbasket of the referenced task’s assignee. If this workbasket doesn't exist, it is created (together with some workbasket_access_items). If the task has no assignee, it is put into a default workbasket with name DEFAULT_WORKBASKET.The workbasket for the tasks can either be declared as a process variable (see “Information mapping from Camunda BPM to TASKANA” here ) or the task routing SPI can be implemented to apply custom routing logic (see here)