We have nested multi instance subprocess to intreate through each vendor and programs under them. For each program we create a report via service task(parallel path 1) and wait for message (parallel path 2)from that report completion before proceeding to another program.
We had two issues, where sometime both parallel path 1,2 complete at same moment and flow gets stuck due to transactions not seeing each other about parallel paths are completed, so we provided a fix of using end terminate event after message listener. After providing the fix, we did saw during message processing flowable optimistic exception indicating parent execution was updated during same time. Any design suggestion to avoid this?
Dont see an option to mark end event as exclusive.
Is it safe to add end parallel gateway to make sure parallel paths are completed without getting optimistic lock exception or would you suggest to eliminate multi-instance subprocess?
What you shared initially and what you shared last are 2 entirely different scenarios.
In the first one, the sub process will end when the message has arrived, i.e. it won’t wait on the generate report (if it is async).
However, in your second one, the sub process will end when both the message and generate report arrive.
In any case, thinking a bit more about what you said
I assume that the report service task is something that send something to some system to perform the report generation and when that system is done it sends something back to Flowable. You can perhaps look into making your service task Triggerrable, with this you then do not need to listen to an event, but your service task itself would be the wait state.
Some of reports take longer time to generate, thats why we created it as a service task(JavaDelegate) to run report in async and send message to flow once its complete. sorry, should have added it initially.
Dont follow what you mean by triggerable. In any case, do you see an issue of using multi-instance subprocess and parallel gateway pattern for our use case?
For the triggerable you can read here in the docs and it is explained How to use triggerable in the forum. It could be the right approach for you.
It really depends on how you are doing the report generation. If you are just spinning up a new thread immediately and continue with the service task, then in theory there is a scenario where the report generation would finish before the Flowable transaction is committed and thus sending the event will not work since it is not available yet in the database. What I would do is to make sure that the report generation happens after the Flowable Transaction is committed. The pattern you are proposing is the same as the triggerable, the only thing is that the triggerable is a bit more explicit and it is easier to model.
I would also think about what can happen if your report generation fails, if the system goes down during that.
