Avoid nearly engine-specific API for task subscription

[stephanpelikan]

Scenario

How to define a task description which will work with any BPMN 2.0 based process-engine.

Current Behaviour

In SubscribeForTaskCmd.kt a taskDefinitionKey is used to define the task one wants to subscribe to. I ask myself whether a task's definition key is really available to all engines. Instead the activity's ID is available for sure. In BPMN 2.0 there is a special attribute implementation for naming implementation URIs and there is also an operation attribute having an attribute implementationRef decribed by: This attribute allows to reference a concrete artifact in the underlying implementation technology representing that operation, such as a WSDL operation. Maybe we should name it implementationRef or implementation instead. Actually, also operation consists of an input message specification which would replace the attribute payloadDescription. Some engines like Camunda also define input-mappings.

Additionally, I asked myself whether the taskType is specific to Camunda, but from a BPMN 2.0 point of view there is also a difference: The operation attribute is only available to service-like-tasks and the implementation attribute is available to all tasks. So, from the BPMN 2.0 point of view there is a difference between user-tasks and service-like-tasks and therefore we can pass this attribute as it is. But on the other hand, a process-engine also might also have different specific APIs for all kind of tasks. So, why not list of kind of tasks in TaskType and let the adapter decide what that means to the specific engine implementation?

Also, I miss a possibility to define processDefinitionKey or a tenantId to limit subscriptions to that specification. This is not possible for Camunda 8 but for Camunda 7 and maybe also other engines.

Wanted Behaviour

I think we have to add a comment to taskDescriptionKey:

/*
May refer to BPMN 2.0 attribute `implementation` or `operation[@implementationRef]` or
any engine-specific attribute of the task XML-tag. As a fallback an adapter-implementation
should also accept a task's `id` attribute, since this the only common attribute in all engines.
*/

If think the first sentence is quite OK. What do you think about the second sentence and it's implication?

An implicit question in regard to the second sentence is: Do we want the engine adapter to be aware of the current BPMN deployed and all previously deployed and still active versions? If the adapter has access to the BPMNs it is easy to do fallbacks like checking for the activity's id. If we decide that the adapter must work without any BPMN reference then value of taskDescriptionKey is not generic any more. Maybe we should skip the second sentence and any higher order adapter (like VanillaBP) may handle this.

Regarding taskType, processDefinitionKey, tenantId and others: Maybe we should define a map instead of taskType which holds that values. Additionally, there might be engine-specific keys like tenantId which may be filled by higher order adapters:

/*
 * Any additional engine-specific restrictions to limit this subscription for. Examples:
 * 1. `taskType`: `USER_TASK`
 * 2. `tenantId`: `myAwesomeTenant`
 * Checkout the engine-adapter for keys available and their meaning.
 */
restrictions: Map<String, String>;

[zambrovski]

I'll try to implement your proposal. In addition, the correlation of messages can also use the same idea of restrictions: Map<String, String>.

[zambrovski]

@stephanpelikan please check the implementation. There is a new README in the examples/java-c7 to start with.

[zambrovski]

I implemented the proposal. Currently, the fallback to task id is not implemented yet. So you think we need this if you look on current implementation?

@stephanpelikan please close this issue, if you think so.
For me - I think we have it now.