Starting a new Process from within a different Process

Flowable Engine
1

We have a Spring Boot Server application with the standard rest endpoints defined in Controller classes that call actions in Service classes.

When we invoke a method createProcessInstance to CREATE PROCESS A we

  • retrieve the latest process definition via a call that looks like

ProcessDefinition latestProcessDefinition = repositoryService.createProcessDefinitionQuery()
.processDefinitionKey(key).latestVersion()
.singleResult();

  • and then eventually we create the new instance by

    ProcessInstance processInstance =
    runtimeService.startProcessInstanceById(latestProcessDefinition.getId(), variables);

  • finally we retrieve the task (1st task in the new process) by

    TaskInfoQueryWrapper taskInfoQueryWrapper = new TaskInfoQueryWrapper(taskService.createTaskQuery());
    TaskInfo taskInfo =
    taskInfoQueryWrapper.getTaskInfoQuery().processInstanceId(processInstance.getId()).singleResult();

This all works perfectly well when we call it from any point within our java services initiated via endpoint posts

BUT

when we call
the same method
from the same service to start a new PROCESS A
from a Delegate java class that is executing as part of a different deployed PROCESS B

the new PROESS A instance is created as expected, but there is no first task associated with it, the TaskInfo comes back from the query as null

Is there some sort of restriction or unexpected behavior when we trigger a new PROCESS A from a delegate invoked by PROCESS B ???

thanks

1 Like
2

Hey @amalyc,

One suggestion first, instead of fetching the latest process definition by key and then staring the process instance by definition id you can use runtimeService.startProcessInstanceByKey(key, variables) that would start the process definition with the latest version.

Back to the original problem. The way the persistence works in Flowable is that everything that has been started within the same CommandContext is flushed to the database after the closing of the CommandContext. In your case when you are calling it from your own service classes it works as starting a process instance creates a new CommandContext and closes it, which means everything has been flushed. However, when you are doing it from within a JavaDelegate then you are already in a CommandContext (the one from the currently running process), which means that nothing is flushed to the database yet and therefore the querying of the tasks doesn’t work (as the information is not in the DB yet).

There are multiple ways that you could achieve what you are looking for.

Use the TaskEntityManager

For your particular query you can use TaskEntityManager#findTasksByProcessInstanceId. This comes from the internal packages and in your delegate you can access it via CommandContextUtil#getTaskEntityManager(). There is one small caveat, this doesn’t work yet with the current entity cache, but we’ll fix it :slight_smile:

Highly advanced

There is another way, but I have to stress out this is highly advanced and should be used with extreme care. The way to do it would be to start the process instance in a fresh CommandContext via the ManagementService#executeCommand(CommandConfig, Command<?>).

ProcessInstance processInstance = managementService.executeCommand(new CommandConfig(false), commandContext -> runtimeService.startProcessInstanceByKey(key, variables))

// You can now retrieve the task

The reason why this works is that you are using a CommandConfig with explicitly disabled use of the CommandContext, this means that once the command you are executing is done you will have cache flashed to the DB and you can query it. The transaction is still propagated though, so if an exception happens after the starting of the process then everything will be rollbacked.

Cheers,
Filip

3

As I mentioned before the fix for the TaskEntityManager#findByProcessInstanceId has been done in this commit.

And a note for the CommandContextUtil it should be the one from the org.flowable.task.service.impl.util package.

Cheers,
Filip

4

Thanks very much. just before the holidays we implemented the "start the process instance in a fresh CommandContext " alternative for now (until we eventually move to the next flowable release) and it worked perfectly

1 Like