I would like to create a task with some other metadata attached to it. I want to get a list of tasks assigned to a specific user while having a specific value to the metadata. Is this possible in flowable
Thanks in advance
I would like to create a task with some other metadata attached to it. I want to get a list of tasks assigned to a specific user while having a specific value to the metadata. Is this possible in flowable
Thanks in advance
You can store custom data as a task-local variable (using TaskService#setVariableLocal) and use that to query the tasks. If you want to store the data as real table columns, you’ll have to resort to adding those columns and using a native query (TaskService#createNativeTaskQuery).
Thanks joram for your help.
What kind of metadata? Is it related to the task or flowable runtime or is it solution-specific and unused by the process engine? We have had requirements for metadata storage that was solution-specific and not used in conditional expressions or as process variables. In the past we supported basic task attributes (name-value pairs), but we wanted to discourage this additional level of coupling, so now we support attributes at the UserTaskElement level since they will not change for a particular version of the template. If the values are dynamic, then a local variable or attributes associated iwth the runtime task element makes more sense. It would be interesting to know how the metadata is being used in that case.
The metadata i want to use is solution specific and is related to task only so it will not be used by process engine at all.
FYI, i want to use flowable as shared task management platform across different applications only to store and retrieving tasks. They all have some unique information related to their apps and some HTTP links ( just as example but we won’t retrieving only by HTTP link there will be link Text associated with it). So when creating a task i want to store this information with the task. So while retrieving tasks based on different criteria such “give me tasks of a user that are created in application A” or"give me all tasks from Application B which contains a given HTTP link".
Please let me know what is the better way to store this kind of information.
As I said, it is really not a good practice to push any data to the process that is not used by the process engine.
“It’s not the process engine’s responsibility to store the application’s data – the process engine should only store what it needs to orchestrate the process.” – Tiese Barrell
http://airquill.io/2014/06/29/Storing-data-in-processes.html
That said, do you expect the value to change at runtime or will it be defined at design time and not change for the specified definition version? In other words, do you expect a new version to be created if a change is required? Again, we extended the UserTaskElement in the DefinitionElement to use attributes, but only as a compromise to our internal consumers. In this way, they are encouraged to retrieve the attributes when the definition enabled event is received and persist them locally so this is only done once.
Unfortunately, our proprietary DefinitionElement is a collection of processes, tasks, etc. and serves as a container class for our API to allow solutions to retrieve the parsed definition, so it is not really part of the Flowable code.
Just to be clear as of now we have no plans of automating any business process at all. We just want to store and retrieve tasks.
The metadata that i am attaching some of them will change after the task is created. Right now i am using POST /runtime/tasks to create a task and then POST /runtime/task/{taskId}/variables to add the additional metadata to the task.
Can you please tell me whether this is the right way to do it or if there is any other better way to do it
If the value will change at runtime, then I assume using local variables is the way to go after all. However, regardless of whether it is automated or not, it is not a good practice to push data to the process that is not used by the process - just in general, from a BPM methodology perspective.
Thank you Ismall for your help