Simple way to block the creation of several instances of the same workflow (same proc def key, same business key)

[wberges]

Is your feature request related to a problem? Please describe.

By default, Flowable accepts to create several instances of the same workflow definition with the same Business Key. It means that, in case this workflow is successfully created but the caller considers that this creation failed (e.g. error during commit of the caller - possibly another workflow -, http timeout at Load Balancer side, external client calling several times the same transaction...), there may be a retry which is done, creating duplicated instances of the same workflow. To block such possibility, we have added a constraint in the execution table by creating a Unique Key composed by the pair {PROC_DEF_ID_, BUSINESS_KEY_}. BUT this solution doesn't work in some specific use-cases: if we deploy a new version of the same workflow, the PROC_DEF_ID_ changes (because it is a combination of {process KEY : version : deployment id}), and we can so create duplicated workflows (one for each deployment version).

Considering that the KEY_ field isn't in this table (only in the deployment one: ACT_RE_PROCDEF), we decided to truncate the PROC_DEF_ID_ to extract dynamically the KEY_ value and so build a unique key independant from the version & deployment... It worked well until we discovered a limitation in the code: when the PROC_DEF_ID_ length is greater than 64 chars (max length in DB), the PROC_DEF_ID_ value becomes the deployment id without key and version. Unfortunately, we discovered this size limitation only when the version became greater than 9 (unlucky guys :)) Example:

• MY_PROC_DEFINITION_KEY22:9:c5637f94-5c4e-11ed-b85e-c03eba3cd8b2
• => PROC_DEF_ID_ = MY_PROC_DEFINITION_KEY22:9:c5637f94-5c4e-11ed-b85e-c03eba3cd8b2
• MY_PROC_DEFINITION_KEY22:10:c5637f94-5c4e-11ed-b85e-c03eba3cd8b2
• => PROC_DEF_ID_ = c5637f94-5c4ae-11ed-b85e-c03eba3cd8b2

Describe the solution you'd like

It would be useful to have also in the execution table the KEY_ which could so be used directly as part of the unique key. It would allow us to generate directly the unique key without having to truncate the PROC_DEF_ID_ and also avoid the length limitation.

Describe alternatives you've considered

• Be aware about such limitation (not know before this issue) and warn the team to don't create workflows with KEY length greater than 22 (64 - 3 (if version max 999) - 2 (::) -36 (deploymentId) = 23)
  • or increase the max length value in both DB and code (not really a good idea if we want to avoid patching each new release)
• continue to extract the KEY by truncating the PROC_DEF_ID_

Additional context

None