Expected Call Activity Out Parameter behavior when BPMNError thrown

Flowable Engine
1

Consider this simple process:

image
image600Ă—578 10.6 KB

With the following call activity definition:

Call Activity

<callActivity calledElement="sub_process_with_java_delegate">
    <extensionElements>
        <flowable:out source="clientName" target="clientName"></flowable:out>
    </extensionElements>
</callActivity>

Java Delegate in called process

public class DoBadThings implements JavaDelegate {
  @Override
  public void execute(DelegateExecution execution) {
    execution.setVariable("clientName", "Jane Doe");
    throw new BPMNError("BAD");
  }
}

Should clientName be available for the user task?

If not:

  1. is there documentation explaining this
  2. is there a way to persist across the error boundary event?

If so, we have a project in which the mapping doesn’t seem to be taking place in this scenario and I would be happy to provide further details if needed.

1 Like
2

By default, it won’t be available. The reason is that a call activity uses an in/out mapping for it’s variables. So:

  • Have you tried providing an/in out mapping? (not sure if this works when using a BpmnError).
  • Otherwise, you can get the parent process instance from your execution, and set the variable on that process instance instead of the one for the called one in the call activity.
1 Like
3

Having the same issue. Sub-workflow does not persist an out variable to the parent when Bpmn error is thrown. It does only if sub-workflow is successful (probably because end event is executed). Is there an option to enforce that on the call-activity itself? Or some other clean solution?

@joram - for the first bullet point

Have you tried providing an/in out mapping?

He did provide the flowable:out variable for clientName on the call activity.

Otherwise, you can get the parent process instance from your execution, and set the variable on that process instance instead of the one for the called one in the call activity.

This is not ideal either - what if variable is already set on the sub-workflow and unexpected error happens?

Also, if there is a grandparent workflow it won’t be persisted to it either. Application I am working on has multi-level sub-workflows and rely on out variables.

4

I checked the code and that is indeed correct - it doesn’t do that.

It’s not ideal, that is true, but looking up the hierarchy is possible too. I don’t see another way of setting it otherwise.