We have different kind of process definitions and we are looking for a standard and prominent mechanism to check if all executions related to one root process have failed and have dead letter jobs.
For example we have processes that have parallel and consequent call activities, some of these callactivities have subprocess in them. Other example is that root process have callactivities that contain other callactivities.
So far, we have looked in querying running executions but every time we face some corner case.
For example what we tried and was near to cover all cases:
SELECT * FROM ACT_RU_EXECUTION WHERE root_proc_inst_id_=<root_proc_inst> and is_mi_root_=false and is_active_=false
Unfortunately, the query s not working for processes that contains parallel callactivity where service task, part of the call activity, failed. The result shows also executions representing other elements in the callactvity but they do not have dead letter jobs.
Other approach that we considered is to filter executions representing only service tasks because only they will have dead letter jobs. However we failed service task in subprocess in callactivity in other callactivity and the result was “intermediateCatchEvent” after the service task failed not the service task.
What we are looking for here is a general way of retrieving the so-called state of one Flowable process.
We want with some queries(to the RuntimeService and HistoryService) to retrieve that state and to use it later on in the code. The problem is that we cannot come to a sustainable solution because each time we implement something another corner case comes up which is not covered by our implementation.
So, we decided to write you in order to give us the best way of monitoring our Flowable processes.
So basiacally we want to cover some basic states of a Flowable process:
RUNNING(each executions are running),
ERROR(all executions have failed)
DELETED(delete whole process instance and its child executions)
AT_RECEIVE_TASK(probably the easises - are there any executions at receive task).
So far, we have implemented some logic which uses the RuntimeService and the HistoryService in order to ‘calculate’ these states but as we are extending our BPMN diagrams all the time, that logic needs to be adapted in order to continue to work. Here is some example, for calculating the ERROR state we were using the DeadLetterJob table. The logic was currently this - if there are any executions that have dead letters - the process is in ERROR state. However, the logic now has to be adapted in order to check whether ‘all’ executions have dead letter jobs but not ‘any’ - here comes the problem because our regular executions are mostly ServiceTasks and CallActivities but we have introduced SubProcesses where the DeadLetterJob is associated not with the Subprocess but with the next execution after it. And this brought some problems with the current logic.
Why this topic was created? - We are hoping that you would propose us some guidance how we could ‘calculate’ the above states using the best optimized Flowable queries. And we were afraid that we were re-inventing the wheel here and that was the other reason for this Forum topic - to tell us is there is such method that we could use?
We introduced a new column in table ACT_HI_PROC_INST, which holds the above status
and an FlowableEventListener, which updates the column when the Flowable Job fails (JOB_EXECUTION_FAILURE).
So the process state depends on state of its executions. As @donkon mentioned one possibility is to keep it synchronized through the listeners another one is to calculate it on demand. HistoryService can affect performance a lot.
Looking at the description, it feels like this could be done by applying a listener to your process instance or process instance elements (e.g. with a parse handler - or generically on process engine config level).
the error use case could be detected by listener for dead letter job entities that get created
same for deleted
the receive task is probably not a default event, but it’s possible to wrap the existing ActivityBehavior and inject a new one, where you do some custom logic.
In all the cases, this probably would be easiest to store in a separate table or (as stated above) a custom column in the process instances table.
