My requirement is to dynamically assign and update priorities to User Tasks. The dynamic priority can be on basis of some pre calculated execution variable via a script task (preferably - in case there is some generic formula) or service task. The metrics that would be considered initially can be like other execution variables related to current process instance and metrics like user tasks already running of a particular kind etc.) due_date could also be one of the main factor. due_date itself would also be assigned dynamically on basis of other execution variables.
Now, talking about dynamically updating priority:
There could be something like consul or similar tool to configure variables in real time. Consul or similar tool will be used to set/update priorities of each kind (taskDefinitionKey) of tasks whenever desired via its own UI. Whenever any key-value pair is updated on Consul, it calls a function and the config is reloaded in the executing code. Consul would change the weightage/metrics and the new tasks would be assigned priorities on basis of new variables. In case of existing/unclaimed/running tasks, I will have to still hit the REST API, calculate the new priority based on execution variables and consul config variables and assign to each task iteratively/recursively.
Now, this API might turn a bit heavy as it would be updating all the user task of all process instances of all process definitions in ideal case. It would provide support for query params or rather JSON payload to act as filters. One might just feel like updating the priority of only few kind of tasks/instances/definitions but in ideal case, it must be able to run on the entire system too.
I am looking for the best possible solution/infra/worker-process to achieve dynamic assigning/updating of priorities for all kinds of tasks. Any light on the context would be of great help ?
I would say API is ready. I see 2 kinds of tasks to update:
- existing task instances - (e.g. org.flowable.engine.test.api.task.TaskServiceTest#testSaveTaskUpdate)
- process definitions have to behave according to new settings. Expressions can cover this case. ()
Regarding solution. It hard to propose something without details.
I still think that I did not understand your question. That’s why here is mine:
Could you rephrase your question please?
Regards
Martin
@martin.grofcik Thanks for the response. You are right regarding the 2 kind of tasks to update.
Requirement :
Lets say a process definition is deployed and process instances are being spawned continuously. There are like x (x1, x2, x3…) number of different user tasks i.e., having a different taskDefinitionKey. Lets assume that there are currently 5 types of x1 task, 17 types of x2 task and so on currently active. The user tasks in the execution flow would have some priority assigned to them initially on basis of exec variables, current workflow metrics and priority weightage assigned to each kind of task (x1 = 4, x2 = 5, x3 = 4, …) etc.
Now, suddenly the admin wishes to update the priority weightage like (x1 = 7, x2 = 2, x3 = 1, …) via an Admin Panel (may be Consul), the priorities must be updated for all the existing tasks. For new upcoming tasks, priorities must be assigned on basis of exec variables and new custom weightage. The question that which all tasks need to be updated can be either all the tasks or a subset of tasks filtered on basis of some criteria.
The new process definitions or new upcoming tasks can behave according to new settings, right, agreed.
But, updating existing tasks (there can be one, hundreds, thousands or count may scale upto millions) would be a heavy activity. I mean iterating over all the tasks of all process instances of all process definitions can be too much cumbersome, verbose and poor programming practise.
I am looking for the best possible solution/infra/worker-process to achieve dynamic assigning/updating of priorities for some or all kinds of tasks.
Let’s assume that priorities are changed frequently and it does not make sense to update all tasks again and again.
In that case I would keep tasks untouched and use assignee just as an constant pointer to consul property where actual value is stored.
If you need to really calculate assignee and make a queries on that - you can always create DB statements to do that.
Martin
@martin.grofcik I dint get you.
“In that case I would keep tasks untouched and use assignee just as a constant pointer to consul property where actual value is stored.” This would enable dynamic assigning of users to tasks but How would this help in updating priority for tasks (unclaimed/unassigned or claimed/assigned) and for new upcoming tasks. I am probably missing something here.
I would say that I am missing something, but I still think that it is feasible.
The only difference between priority and assignee is type (Integer -> String).(priority x1 can point to 10 and priority x2 can point to 5).
Re:claiming : when somebody claims the task, API allows to store any string in assignee field.
Adam claims the taskA. (Adam acts in roleA which is property in consul RoleA -> Adam)
taskService.claim(taskA, roleA);
we can just search for roleA assignees to get all tasks claimed by Adam.
If we want to change Adam to Eve, we can just change consul property RoleA -> Eve.
The problem which I see there is e.g. ordering through API queries.
Martin
1 Like