When startProcessInstanceByKey gives the instance back ?

[vire7777]

Hi all

A little question but SO important for me.
I ve created a workflow instance launcher with the code :

ProcessInstance instance = runtimeService.startProcessInstanceByKey(processKey);‍

But something strange about that !
In my workflow, i have two javaservicetask then a human task and i ve seen that the code above gives me the instance back ONLY when it reaches the human task.

In the documentation, there s something about that :

It's important to note that the Activiti engine will continue process execution steps until it reaches a wait state, such as the user task. At such a wait state, the current state of the process instance is stored in the database. It remains in that state until a user decides to complete its task. At that point, the engine will continue until it reaches a new wait state or the end of the process. When the engine reboots or crashes in the meantime, the state of the process is safe and well in the database.

But could i do something for having it directly after the instance launch because i need it before the instance reaches the first javaservice task.

Thanks for your time and answers

[sothach]

But could i do something for having it directly after the instance launch because i need it before the instance reaches the first javaservice task.

If you make set the first task as async=true, then startProcessInstanceByKey  will return immediately (the workflow is now running in a new thread)

[ronald_van_kuij]

Maybe this should be mentioned very early in the docs…

[vire7777]

But if i want to use "async=true", i don t know why, the workflow don't find my class anymore…

[dognose]

which class?

[vire7777]

My javaservicetask calls a class "com.test.ActivitiTask"
When i do not set async, then it calls my Execute method on this class "com.test.ActivitiTask"
If i put "async = true" then it doesn t find my class "com.test.ActivitiTask" and doesn t lauch my method execute…

[jbarrez]

Maybe this should be mentioned very early in the docs…

I don't know … async is a pretty complex thing to grasp …
Definitely if you don't understand the regular transactional way of execution …

If i put "async = true" then it doesn t find my class "com.test.ActivitiTask" and doesn t lauch my method execute…

Huh? The jobexecutor (which runt he async jobs) lives in the same JVM as the engine …
It doesn't execute it immediataly of course. And also, you have to make sure the jobexecutor is actually activated in the process engine configuration.

[vire7777]

I've putted jobExecutorActivate on "True" but nothing else !
Anyway i really doesn't unsderstand why it doesn't find my class and i have a "class not found" error message however when the task isn't async, it works perfectly.
I've read the doc and there's nothing about it… I understand how it works and that s why i m so disapointed…

Other question :
Could it be possible that, because i'm deploying my xml on activiti-explorer, when i lauch the process instance and engine in my application (not activiti explorer), activiti try to search my class (in the async javaservicetask) in activiti-explorer evenif i really don't think so (logically, it would search, as you said, in the same JVM)

[ronald_van_kuij]

Maybe this should be mentioned very early in the docs…

I don't know … async is a pretty complex thing to grasp …
Definitely if you don't understand the regular transactional way of execution …

Just a reference that if you want/actually need something like this,  making the first task async is needed. Point out that it is 'advanced' usage, and just point to the async chapter… Nothing more

[ronald_van_kuij]

Other question :
Could it be possible that, because i'm deploying my xml on activiti-explorer, when i lauch the process instance and engine in my application (not activiti explorer), activiti try to search my class (in the async javaservicetask) in activiti-explorer evenif i really don't think so (logically, it would search, as you said, in the same JVM)

Yes… classes should be available to ALL jvm's that do something on the process… If the job executor is in the explorer and the classes are not, you get this error.