Hello,
We have 6 hierarchical layers of process models, with 1 master process, 4 phases, 25 sub-phases, 150 Scenarios, 350 Processes and some 1200 Steps, all modeled as one giant flow with the help of call activities. Only the steps do perform some real task, the higher levels are just structural entities.
The idea is to have a so-called „backbone“, where those Steps are located, which, when failing, pause the entire flow and wait for manual intervention. At the same time, we do have uncritical Steps, which we want to model as so-called „branches“ (parallel execution), which, when failing, just pause the respective branch and wait for manual intervention, while the „backbone" keeps running. Both, backbone and branches have their own end events. The problem seems to be how to proceed to the next backbone call activity, as long as not all branches are completed. But this would exactly be the desired behavior, i.e. even when a branch remains active, say in the phase level, the backbone should continue down the line with the next phases or sub-phases etc. The uncritical error in the phase branch shall not prevent the backbone from continuing.
We tried with several gateways, throwing and catching events, signal events etc., but we were not able to „convince“ the backbone to continue while a branch is still active (= end the process and proceed to next call activity). Is it, that a process can never end before all branches (parallel executions) are completed, which somehow would make sense? But how can we overcome this dilemma? What could be a suitable approach for us?
Regards and thanks,
Joachim
Hi Joachim.
If you can reduce the complexity your use case will be more understandable. Currently my understanding is that you need to start a new process instance while another process instance is still in progress.
I would use CMMN models together with processes in that case.
Regards
Martin
Hi Martin,
I have tried to paint something simpler to explain the question. While the Branch 1 in Call Activity 1 is still active due to some error and say a manual intervention (user task), the backbone keeps going forward and Call Activity 2 (Process 2, typo in screenshot) is triggered, and so on. In our scenario, only errors in the backbone would lead to a full stop of the process flow, any error in any branch should not.
Regards,
Joachim
From my point of 10.000ft view, I would suggest to use CMMN model with sentries between stages.
Martin
Hi Martin,
thank you so much for your suggestion. Not having worked with CMMN so far, this is completely new for me, but I will have a look at it.
In the meanwhile I had my Archimedes/Newton moment in the night and tried with signals, see:
Of course this model is just to show, it won’t work. But I tested it with a real process and from my perspective it worked. The branch was triggered and the “Intermediate Signal Throwing Event” got completed, hence the overall process instance got completed and it triggered the following Call Activity. We need to test whether our UI can digest this and still display the Child in the proper sequence, or whether it will lose the context.
Indeed, a pattern with signals would work for this kind of use case. You’d need quite some bookkeeping for the signals of course. Another angle to investigate is the new event registry, with typed events.
CMMN would be worth to have a look at. Your use case of providing context for the different processes and starting/stopping them depending on events coming in fits your use case nicely. Reading your description above, it looks like you have different ‘stages’ in the whole execution and need somehow to keep context between all the different processes.
Hi Martin and Joram,
I had a look at CMMN, but from what I understood this is far too “anarchistic” for us. We do really have a very clear process with a defined flow, it is just that some activities - when failing - shall cause the whole flow to completely stop (backbone) and others can be fixed later in the event of a failure and shall not stop the whole flow (branch).
I have tried to include a CMMN model into our BPMN model, but I could not find a way how to do this, although documentation suggest that it is possible. But it doesn’t tell how.
Because of the clear nature of your process flow I did not want to switch to CMMN models as such, and then integrate BPMN models as process task. However, if you tell me that this will solve our problem, I am going to try it out.
The signalling approach actually worked as such and, initially feeling like Archimedes and Newton altogether, I was brought back to earth quite rapidly! The triggered process loses it’s connection to the parent and is started as a new root process. Our UI cannot digest this, and even in Flowable I lost the triggered child from the process/task overview, I think because the initiator was not passed somehow and the task was not assigned to anybody. The book keeping of the signals would not be an issue, we have clear naming conventions and would call them like the called child with a prefix.
Regarding the event registry, I had a look and asked a techie to investigate further. I had the impression that here also the parent would get lost and a new root process would be started, let’s see.
Further investigating, not yet ready to bury the backbone/branch idea…
Regards,
Joachim
Hi Joachim.
Yes, that’s exactly as it works (Case could provide you a container to wrap all entities together)
If you want to keep parent/child relation you should use call activities.
Regards
Martin
Hi Martin,
actually we are currently planning to upgrade our Flowable to the most current release in order to be able to use the CMMN tasks in our BPMN processes. I am hoping to be able to use this blocking=no option or the like, let’s see.
Regarding your last point, we are already using Call Activities only, but with the signalling approach the connection gets always lost. Or is there any setting which you have in mind which would keep the parent/child relation?
Regards, Joachim
Parent/child relation is kept for call activities, Case tasks or Process tasks. In other cases (as signals) they are not present.
Martin
Hi Martin,
so you mean to say that neither the parent would know which processes have reacted on the signal, nor the child would know who has sent the signal, and there are no traces whatsoever in the Flowable database which would allow us to draw this connection? Correct?
And there is also no way to pass parameters when using the signalling approach, right?
Please quickly confirm once more.
In that case we do not need to follow this approach and rather wait for the upgrade to try out case tasks.
Yes, parent does not know which process accepted the signal
There are traces in the flowable history, if you use it. (You can also use event log, but I do not recommend it. Its generates too much data. To draw a connection it can be non trivial task to parse history.
Regards
Martin
Hi Martin,
thank you very much for your valuable help! Your last remarks raise my hopes to be able to trace it from the history, which we are anyway doing and I have asked a colleague to look into it.
For the case task, which I wanted to try out as well - but thought that we need to upgrade our Flowable release first in order to be able to use it - I have now seen that it seems to be part of the enterprise edition only. Is this correct?
Regards,
Joachim.
Case task is part of the open source bpmn too.
org.flowable.engine.impl.bpmn.behavior.CaseTaskActivityBehaviororg.flowable.engine.impl.bpmn.behavior.CaseTaskActivityBehavior
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:flowable="http://flowable.org/bpmn"
targetNamespace="http://flowable.org/bpmn">
<process id="caseTask">
<startEvent id="theStart" />
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />
<userTask id="theTask" name="my task" />
<sequenceFlow id="flow2" sourceRef="theTask" targetRef="theTask2" />
<serviceTask flowable:type="case" id="theTask2" flowable:caseDefinitionKey="myCase">
<extensionElements>
<flowable:in source="testVar" target="caseTestVar" />
<flowable:in source="testNumVar" target="caseTestNumVar" />
<flowable:out source="caseResult" target="processResult" />
</extensionElements>
</serviceTask>
<sequenceFlow id="flow3" sourceRef="theTask2" targetRef="theTask3" />
<userTask id="theTask3" name="my task2" />
<sequenceFlow id="flow4" sourceRef="theTask3" targetRef="theEnd" />
<endEvent id="theEnd" />
</process>
</definitions>
(I did not find case task in OSS modeler but it can be used.)
Regards
Martin
Hi Martin,
this is what I see:
Do you mean to tell that I (or someone who understands this) would have to write such cryptic stuff which you have pasted above and one cannot use it from the Visual Editor? Why is this? Some settings my IT guys have to make so that I can see and use it?
Regards,
Joachim
The case task is indeed not (yet) added to the open-source modeler. The engine has the capability to execute it, that is what @martin.grofcik is referring to.
(You are correct that the case task is part of the enterprise modeling tool. This forum however is about the open source distribution. If you’re interested, have a look at https://flowable.com/trial/ or the enterprise forum: https://forum.flowable.com)
Hi joram,
Thanks for your explanations. Actually we have inserted Martin‘s html example in a model of ours and deployed, which worked. But it neither showed the case task in the modeller nor got it executed. Same in Activiti and Camunda, which we tried online. So we eventually gave up. If we cannot see it, we anyway do not want to use it, so, motivation was not too high to proceed.
I think we can close this thread then.
Btw., I really like Flowable, it is a state-of-the-art BPMN tool and is able to handle our complexity, but some things I do not really understand, e.g. why it cannot display a case task, but is able to run it, or why such a simple thing like a scrollbar (basic feature of the last century/millenium) is not available in Task to choose tasks or processes from a long list!?! We have to zoom out until it is not possible to read the process names anymore. Because of this, we have to create a lot of Apps for our 1500 process models…
Regards, Joachim
Hi Joachim,
As with many open source projects, for some things we rely on community contribution. The key focus of the Flowable open source team is always the engines - that’s the experience, knowledge and skills that’s difficult to find, and in which the core Flowable team are world-leading. It would be great if anyone with ability in last century/millenium features could help the project (is that a subtle enough hint? 
)
If we were Facebook, Google or Amazon, we could fund all the work around the engines. May be one day!
Cheers
Paul.
Hi Paul,
the hint was clear and thanks for the explanation! I liked your subtle hint…
Regarding the implementation of the last century/millenium features…, I am a molecular biologist ((is that a subtle enough hint? ).
Regards,
Joachim
Yes, your hint is clear - you’re going to contribute a brain-Flowable interface to do task list scrolling.