flushing activiti data to the database

[joachimvda]

Is there a way to force activiti to write the internal state to the database? I would like something similar to flushing the session in Hibernate?

The problem I am facing is that I have two flows (say flow A and B). A listener on a task in flow A wants to transition flow B by one or two steps. Say flow B has tasks K-L-M-N. The listener on flow A want to transition Flow B to task N if either L or M are the current task.
I do this by doing the fllowing consecutively:
1. search tasks on flow B, if taskDefinitionKey matches L -> transition the task
2. search tasks on flow B, if taskDefinitionKey matches M -> transition the task

This works fine if flow B is on task K or N, keeping it there.
This works fine if flow B is on task M. In that case 1. does nothing and the flow ends up on task N
This fails when flow B is on task L. In that case task L is transitions on 1. moving the flow to task M. However when determining the current task in step 2., it still return that L is the current task.

Is there a way to force the code to "know" that flow B has already transitioned in 2?

I read that async may be a solution to this, but I need everything to execute in one transaction. There are a lot of validations happening in both flows, and success should be all or nothing.

Thanks for your help.

Kind regards,
Joachim

[trademak]

You could use message or signal events to communicate between flows. Then you could be informed about transitions in the other flow.

Best regards,

[joachimvda]

Using signal events is not an option in our case. In most cases these are really user tasks which need to be transitioned.
Also (but not relevant to this issue) I am unable to signal event tasks when they are in a subprocess.

Other suggestions?

Kind regards,
Joachim

[trademak]

Then I don't understand it anymore. You said you need to execute everything in one transaction. But you are user tasks? A user task typically runs in its own transaction. Maybe you can provide a more complete picture what you want to achieve.

Best regards,

[joachimvda]

I think I tried to explain the flow above.

We have two flows (say flow A and B).
Flow B has several steps, say tasks K - L - M:
K: complete data
L: wait for flow A to progress to a certain state
M: allow user to enter more data

Step M in flow B allows the user to do everything which is possible in task K plus something extra.
At a certain point in flow A, process B should progress until it is in task M.
This is done using an script task (in flow A) which tries to transition flow B. If task K exists, it is completed. Then it checks if task L exists and transitions that as well.

If task K did indeed exists, then the system indicates that K is still the current task which assures that the transitioning of task L fails.

Task L is modelled as a user task. This is done for two reasons:
- in some cases, the user can actually do something using this task while waiting (thoug the user is not allowed to complete the task)
- It is not a receive task as we had problems signalling tasks when contained in (embedded) processes.

I guess I could model this case using a boundary signal, but that feels wrong. This would mean that I have to model both a normal transition and a boundary signal transition from task L to M which both do exactly the same thing.

THanks for your help,
Joachim

[trademak]

Ok thanks for the additional info. Your last statement about adding a boundary signal event would the approach I would take. That's the right functionalty to use in these kind of use cases.

Best regards,