I have a Parent Process which has some user task and subprocess is being called in between as below. The sub process has also some User Tasks.
My Queries
-
As a requirement we have back functionality in UI screen which can take it from ‘User Task 2’ to ‘User Task 1’ in the parent process. Let us assume we are currently at ‘User Task 2’, in this scenario as we have passed through sub process it’s process is completed. When we jump from ‘User Task 2’ to ‘User Task 1’ and then moving forward is there as way to get old completed sub process and attach it to parent instead of creating a new instance of sub process.
-
The back functions can also move from the parent process ‘User Task 2’ to sub process ‘User Task 3’ or ‘User Task 4’. Currently we are at ‘User Task 2’ in parent process. and we have to jump to ‘User Task 4’, as we have completed the sub process can we re-attach the same sub process we have completed before back to parent process and jump to ‘User Task 4’ in the sub process.
How about setting a variable “subProcessCompleted” to true when the sub process completes. Then, after looping back to and completing user task 1 you can just check if you can skip the sub process or need to execute it again. The data from the previous execution will still be available if it has been mapped to the parent.
I agree with what you have suggested which will enable us to skip or continue the sub process. My question is does camunda has any way to reattach the same or this is the only way we need to move forward.
For my second scenario as per my understanding of camunda it will always create a new instance of the process but is there a way to get the old one and attach to parent process for jumping.
A completed sub process is completed. I am not sure what “reattaching” would mean in this context. You mean instead of running a new instance of the sub process (in the same version) you would skip the execution of the sub process and instead read the results (data) from the previously completed instance of the sub process? You could do this via the API, but it is highly uncommon. I don’t see why you would need to do this, given the approach described above is much cleaner.
“attach to the parent process for jumping”
The process instance in a call activity has its own life-cycle. After it is completed you would not be able to “jump” back into the same instance. A new execution would mean a new sub process instance. A complete task instance always remains completed. Even if you were able to jump back into the same process instance, you would still create new task instances, which would be very similar to starting a new sub process instance.
When you use a call activity you can define how the binding should be done. Apart from binding to the latest version, it is possible to bind to the same deployment, version or version tag.
Can you elaborate further, why such a feature would be required / useful?
Is there a requirement the available features don’t cover?
i think you are talking about IFC, ie ‘in flight change’ for the order, where due to some change in order you want to rewind from a certain point and do not want to repeat some tasks which have no impact from the change.
i am yet to find the best solution for this scenario. but you can try-
- model the tasks with a flag for auto-complete in case of IFC.
- you can keep an interrupting boundary event on the main process and trigger it when you want to rewind the order.
- after the event is triggered keep a service task to start the same process definition and pass on all variables from this instance and additionally pass IFC flag.
- your new instance will have all the data and only the tasks which are not flagged for auto complete will be available to you to work on.
- new order can have same business key with the version attached to it so you can find related orders and still differentiate them.
