Propagate variables through a process tree

Camunda 7 Topics Discussion & Questions
1

I have a need to propagate a json variable, ‘orderModel’, to all of the processes within a process tree, similar to the case presented here https://forum.camunda.io/t/atomically-updating-variables-in-a-process-tree/7313. In my case the variable might be changed in the parent or any related subprocess or call activity of the parent.

I was thinking of locating the topmost parent processInstanceId and then use recursive subProcessInstanceId and setVariable(id, variable, value) to set the variable in each process. The total number of active related processes at any time is likely no more than 5-10.

Will this approach lead to unexpected optimistic locking exceptions or other known pitfalls? I need some advice as to whether this is bad practice or not before going too far in this direction.

2

We used this approach in the past, but do not use it anymore. Instead, we keep the values in our own tables and access them by calling a service, basically.

For user’s convenience, we created a wrapping bean with getters and use Camunda’s context to find out in which process the bean is called. It looks similar to this:

import lombok.RequiredArgsConstructor;
import org.camunda.bpm.engine.impl.context.BpmnExecutionContext;
import org.camunda.bpm.engine.impl.context.Context;
import org.springframework.stereotype.Component;

import java.math.BigDecimal;

@RequiredArgsConstructor
@Component("wallet")
public class WalletBean {

  private final WalletService walletService;
  
  public Double getBalance() {
    BpmnExecutionContext executionContext = Context.getBpmnExecutionContext();
    return walletService.getAmountByBusinessKey(executionContext.getExecution().getProcessBusinessKey());
  }

}

Then, the expressions in BPMN would look like this:

${wallet.balance > 100.00}

Though this is simply a nice to have. Calling WalletService directly from the BPMN would do just fine.

As for the initial approach with updating the process tree - yes, there will be exceptions. We used nested transactions to update each process and ignored the errors. Nested transactions allow not to rollback everything in case data consistency problem is encountered. But in the end, we were tired of seeing those exceptions in the log and opted for a more stable solution.