Start process synchronously and return results Back

[smirzai]

Actually this is a continuation of this topic:
   http://forums.activiti.org/content/starting-process-instance-synchronously


Especially in OLTP or embeded use cases, one wants to run the workflow and get the results synchronously. In some cases there is no real database behind or the performance requirements are too strict to enable historization.

What I would like to suggest, is something like this:

First the output variables should be introduced exactly like subprocess, only for the main process. Here is an example:

<process id="vacationRequest" name="Vacation request">     <extensionElements>          <activiti:out source="someVariableInSubProcss" target="nameOfVariableInMainProcess" />  </extensionElements>    <startEvent id="request" activiti:initiator="employeeName">  …‍‍‍‍‍‍‍‍

then it could be something like :
    Map<String,Object> outcome = myRuntimeService.startInstance("myProcess", vars);

will start the process, wait until it ends, then preserves and returns the result from context and not history tables.
I can try to see how I can implement it. 

[smirzai]

ok, actually the name of the function should be something else, say

<code>
Map outcome = runtimeService.startInstanceSync("myProcess", vars);
</code>

[mdaviot]

1st idea :
Looks great, fits exactly with what I had in mind. We could then enhance the designer UI to map these output variables like it is done in call activity mapping.

2nd idea :
Maybe an even simpler approach would be to always return in the map all variables in scope at the end of the process, so you don't even need to define the mapping, just to add these startInstanceSync methods in the API.

Honestly I’m not sure it really adds that much value to specify which variables are published at the end of the process so I would recommend the 2nd idea.

[frederikherema1]

I understand where you're coming from. Processes without wait-state won't be in the runtime-tables because, at the end of the API-call, all entities are deleted. only history is left behind. However, there is more to a process than just it's variables (path it went trough, for example) so I'm not sure it's as simple as just returning a map of variables (also, what with sub-execution-variables and name-clashes).

Currently, you can use a process-end listener (and potentially the BPMNParseHandler approach to add listeners to any process to keep BPMN xml unaware of spacial handling) that saves the process-variables etc. to a thead-local map. After you have called the startProcessByXXX() you access the map and have a blast

[smirzai]

Something like that is the idea for implementation. But don't you think adding the support to the engine itself, instead of configuring it each time, might be a useful extension for Activiti ?

[frederikherema1]

Yes, it would be a useful extension if the result you get back is actually complete (not just the variables). This should be thought trough if we want to add it to the engine. ATM, we don't have the bandwidth ourselves to add this feature, but I'm happy the review/discuss any suggestions/implementations around this.

[jbarrez]

I'm not convinced we should add this feature.

If your process is 100% synchronous, simply pass an object in the variables map, and populate the object values during process execution.
When your process finished, the object will now have all the values set. This already works now and doesn't need any new implementation work.

[smirzai]

@jbarrez: even if the process is not itslef 100% synchronous, one may want to call it synchronously and wait until all the paths are completed.

[smirzai]

This is the exact same request:
http://forums.activiti.org/content/out-variables-primary-process-proposal

[jbarrez]

I'm just afraid of adding thread waiting to a call. It is a potential performance bottleneck of major implications.
Activiti has never interfered with client threads so far, and I'd like to keep it that way, it keeps things simple and understandable.

If you really need it, it's very easy to do yourself with thread waiting and polling the service.