Is there a way for me to know which subprocess a task belongs to from within the Task APIs? I have a task query that uses the historicTaskInstanceQuery() to get me a list of tasks. I know I can get subprocess names (which is all I need) from the historicActivityInstanceQuery(), but I’m trying to not rewrite all my code to swap out query APIs.
The only thing I need is to figure out what the name of a subprocess is, given a Task object. The reason I want to know if there’s something within the task API (or something else) is because I’ll be looping over my tasks, and I don’t want to fire off an API query in a loop like that (I loop the tasks to pull out the task data I need to return to the UI stack).
Hey @jeff.gehly,
Currently, we are not exposing such information to the Task object.
There are 2 ways you can do this:
- Collect all task object execution ids in a set and then fire one query call to get all sub process activities from the
HistoricActivityInstanceQuery and then do the mapping
- Write custom SQL to achieve what you need and do a join.
Cheers,
Filip
Watching my process, I can see in the ACT_HI_ACTINST table the execution ID changes 3 times. First when my master process spins up, follows along some sequenceFlow elements, hits a decision gate, and then enters my subProcess. The execution ID for this is first chunk is 950069. Then I it my subProcess, and my execution ID changes to 950080. Then the head scratching starts, because the start node within my subProcess has execution ID 950082, and 950082 remains the execution ID up through my first user task. So I have a master wokflow, a user task, and a subProcess ID that all seem not to be related to each other via the database. The only way I can think of to solve this wonky behavior without severe pain is the use of task locals, where I forcibly set each task to have a task local that tells me what sub process it belongs to.
I assumed it would all link up in the ACT_HI_ACTINST table, which is where I pulled those execution IDs from. Since the IDs don’t line up, I don’t see how I could write a query to associate a task with its relevant subprocess.
For those who are curious, the work-around I have for this solution is to set a task local variable during task creation, so I can match up against that. Basically, I have this ‘create’ type expression running for all my users tasks that I want to tag as belonging to a particular subProcess.
${task.setVariableLocal(‘subProcessName’, ‘SubProc 1’)}
Then, when I fetch the task, I can pull the task local variables and the tasks will tell me exactly which subprocess they belong to. It’s a round-about way of doing this and it requires that you adhere to specific conventions, but it does get the job done without murdering performance and let you continue to use the task APIs to pull the data instead of having to do custom queries or other complex logic.