Newbie. Separate thread for Activiti Explorer UI and the workflow process instance

[sankalpn]

I am trying to write some workflows which, after taking user input in start event form, invoke a series of web service APIs inside service tasks (meaning service tasks take longer to finish) and produce output via email tasks.

I am using activiti-explorer UI for user inputs and to deploy the workflow process (version 5.16.3).
What I observed is, the activiti UI freezes at the start screen after taking user inputs as the service tasks run. After going through user guide and some forum topics, I set "jobExecutorActivate" to "true", which enabled async executor and I thought would also enable activiti workflow to run asynchronously, as a separate thread, with respect to UI.

But, even after that, the UI continues to freeze on the start event form which takes user input. The UI goes back to "deployed process instances" screen, apparently after it enters an intermediate wait state (as seen from tailing tomcat logs).

My doubt is:
1) Am I right in interpreting that activiti-explorer UI and the workflow process instance are still runnning in the same thread?
2) If so, or even otherwise, is there a way I can have activiti-explorer UI jump to "deployed process instances" immediately after start event form has been submitted to workflow process instance?

Thanks in advance for any pointers.

[jbarrez]

No, using async=true on the service task returns the thread and your ui thread should be free.

So something else is going on. Could you post the relevant process xml?

[sankalpn]

Ah! Got it. I cannot have async=true on my service tasks because they have to be sequential. I was hoping that by enabling jobExecutor, UI thread would automatically move on after firing start event. But from your response (correct me if I am wrong), it seems that the workflow process instance thread needs to return before UI thread can be freed. So, as a workaround, I introduced an intermediate timer event just after start event of my workflow, which freed UI thread immediately.

Now, I didn't find any other configuration, say, make the whole workflow or just the start event asynchronous, which would allow me to get rid of this workaround timer catch event. Am I right here?

Thanks for pointing me in right direction.
Sankalp

[trademak]

If you set async = true to your first service task, everything is still executed in sequence, so no parallel behaviour. And you don't have to introduce the intermediate timer event in that case.

Best regards,

[sankalpn]

Thanks Tijs. That works.