I have the following simple test process that I ran a script task after boundary timeout event.
The script task is a simple JavaScript
<scriptTask id="sid-7BA11464-9B5D-4F6A-B2B6-FC4B693A885D" name="timeout script" scriptFormat="JavaScript" flowable:autoStoreVariables="false">
<script><![CDATA[execution.setVariable('errorStatus', 'timeout');]]></script>
</scriptTask>
The timeout event fires after one second:
<userTask id="sid-CFF54E6B-8430-4A52-9DC9-F095ADFEC7EE" name="post user task" flowable:formFieldValidation="true"></userTask>
<sequenceFlow id="sid-4553B1CB-811F-40E2-AC6E-22E00D9A7B71" sourceRef="sid-CFF54E6B-8430-4A52-9DC9-F095ADFEC7EE" targetRef="sid-F73E4EB0-B8FE-4162-84CF-7BA22E5D3BB7"></sequenceFlow>
<boundaryEvent id="sid-25DE22EA-03F5-4765-83CA-7EF3CE435EFC" attachedToRef="sid-CBCCDB1E-567E-4434-9A30-74445AE26074" cancelActivity="true">
<timerEventDefinition>
<timeDuration>PT1S</timeDuration>
</timerEventDefinition>
</boundaryEvent>
When I ran this process, the process never moved forward beyond the first user task because the script task execution failed. It does not give me any error in the console output, but I know it is the script task failure since it moves on to the next task if I remove the script task. Also, if I put the script task in any other place other than after the boundary timeout event, it executes properly since I can verify the variable errorStatus value.
Wondering if anyone else has seen this behavior? Is this a bug or do I miss something?
I found a lot more issues with the timer boundary event. Execution listener does not seem to work on it. If timer boundary event flows to another user task as the document illustrated (BPMN 2.0 Constructs · Flowable Open Source Documentation), this user task cannot have execution listener defined either (it would fail to execute the user task, but it seems to work if I do not define any execution listener).
It seems to me, I cannot expect tasks after the timeout event to work properly, what is the expected behavior?
Hey,
We are using timer boundary event on UserTasks with success. Your diagram is strange/incorrect. Timer boundary event on UserTasks acts like alternative/timeout on normal flow, but in your cast there is no normal flow.(no other outflow from user task)…maybe this is the problem
I’ve found the issue and it is a very strange issue – it does not make any sense to me.
I actually have two spring boot web apps running on my test machine. The first one runs the process defined by my diagram in a unit-test suite, the other runs the embedded web UI apps so I can monitor the progress. I’ve assumed these two spring boot apps should be independent from one another, but in reality, they are somehow strangely connected!
When the first app executes the script task, somehow, my web UI app seems to run the script task as well! I am using java 17 and I did not include nashorn dependency in my UI app project because I did not expect it to run the script task, but it did for some bizarre reason! As soon as I added the nashorn dependency in my UI app, my first app can execute the script task successfully after timeout event!
Same goes to the issue with the execution listener that did not work after timeout event. I defined a class for the listener in the first project, but I did not define it in my UI app project. But as soon as I defined the same listener class in my UI app, the problem went away as well, that is, the execution listener works as expected after the boundary timeout event.
Also, if I do not run my UI app while I am unit-testing my process diagram, it also works as well.
Before I added the nashorn dependency and listener class in my UI project, somehow, script task and execution listener worked fine if they were NOT executed after the boundary timeout event – they were not working only if they are after the boundary timeout event.
I hope someone can make a sense of this behavior.
Hey @carbon_60,
I am not sure why this doesn’t make sense to you. Flowable is setup in such a way that it can run multiple nodes in the same time. Seems like both of your applications are connected to the same database.
Since you have timers it means that any of the available applications connected to the same database are able to pick up the timer job and execute it. If you have 2 instances that are not identical then you would see the problem that you are seeing.
I would suggest to you to have identical applications or you shut down the async capabilities of the one that you are using for viewing purposes only. Keep in mind that even if you shut down the async capabilities you might still make a mistake and run a process from the viewing only instance.
Cheers,
Filip
Thanks Filip for explaining – I guess my understanding of flowable engine was totally wrong in a fundamental way then!
What I wanted to test is to deploy two separate applications. One for end-users to run processes and another for admin/devop to monitor and debug any customer issues using the web UI admin app. Both apps need to be connected to the same DB for this to work, right? So it looks like this is not a recommended deployment model? Instead, I should combine the two into a single app? The reason I would prefer to have them separated is so that the web UI app can be limited to a network only devops have access to.
Adding flowable.asyncExecutorActivate=false to web ui app does seem to do the trick, but it is your statement that mistake could still be made to accidentally allow web UI app to run a process makes me unease with this deployment model in general.
Maybe Multi-tenancy would be good for you in this situation
