Closed pdbi closed 7 years ago
Can you share the BPMN XML and share the code in the Java service task (Method A)?
I upload the BPMN XML, https://github.com/flowable/flowable-engine/files/1233872/flow.zip when the RP flow post, it will call a method(A) : returnOrderWorkFlowController.close(ro); in the receiptManager,
this method will trigger a RO flow goes down.
this is part of returnOrderWorkFlowController.java:
public void close(GenReturnOrder ro) {
List
private void complete(String taskId, String toTransitionName){ Map<String,Object> variables = new HashMap<String,Object>(); variables.put(TRANSITION_NAME, toTransitionName); getTaskService().complete(taskId, variables); }
actually, I want to see the method (closeById) in the wf_ro is called just after the returnOrderWorkFlowController.close(ro); but not...
Ok, thanks. The change from Flowable 5 to 6 is, that Flowable 6 uses an Agenda. Every operation that needs to be executed on the Engine is added to that Agenda. So in your example, creating another instance that does a call to a java service task (method B) will be added to this Agenda as well. This means that I would expect that the operation to create the new instance will be added first to the Agenda. Then the next step will be to complete the java service task (method A). So that's why you see this behaviour.
To model the behaviour you are looking for you would need to add a receive task after the java service task (method A), and trigger this receive task at the end of the other instance.
is there anyway to avoid to use the agenda for arrange the service tasks? because even it try to use the receive task to improve, it seems can not promise the trigger would active in the next operation. because it's in the operations linked list. we have multiple instances execute at same time. it will waste times on waiting the others, which are no related operation, in the linked list. Really Thanks for Suggestion in advance.
wow, this is a big problem for us. Actually, we have a lot of interactions between different workflow instance. For instance, flow A many need trigger flow B to process some jobs and the B also have to use the newest data of A, and then, after B finished it job, flow A will continue.
If we have to always complete A first, and do B, and then make A goto next again, it is not a workflow from my point of view.
So, for Flowable 6 and later version, won't support this requirement?
@pdbi When you use a call activity to start the new sub process instance, you would automatically get the behaviour you are looking for. Then process A will wait until process B is completed.
@oooryanooo No of course this is possible with Flowable 6. Using a call activity would be the standard way of doing this.
For example , there is a Instance A, when A goes into a java service task, in this java service task(Method A), it call flowable api to make another instance B to go to next task. Instance B also call a java service task(Method B) in the progressing. Now the problem is coming. because we call the Method B in the middle of the Method A. what we thought the methods should do like this: Method A first part --> Method B --> Method A left part. but actually, the Method B won't be call until the Method A is finished. it looks like Method B is hang here until A is finished.
before I use the Actitivi, there is no this problem. I'm not sure if it's a new bug for flowable or not, may be I miss some configuration , please remind me, thanks a lot.
FYI, our system use the Flowable 6.1.2, this is part of [config:](url
flow.zip
)