OutputParameters in Delegation Code being removed from Runtime Variables

Camunda 7 Topics Discussion & Questions
1

Hey guys!

I’m trying to use a Service Task with Java Class (Delegation Code) implementation and OutputParameter to set variables to Process Instance Scope, but i noticed that when process has a ParallelGateway or InputParameters a new execution is created and for some reason these variables are invisible for other Executions/Process Instance. The problem: Let’s say that we want to use the output variable from the Service Task after ParallelGateway closes, process engine will throw an incident because can not evaluate this expression since the variable no longer exists. :cry:

We think that there is an implementation error in our JavaDelegate class and we tried to use the Get Started Service Task code and Delegation Code (ToUppercase) example and curiosly we notice the same behavior.

import org.camunda.bpm.engine.delegate.DelegateExecution;
import org.camunda.bpm.engine.delegate.JavaDelegate;

public class ToUppercase implements JavaDelegate {
  public void execute(DelegateExecution execution) throws Exception {
    String var = (String) execution.getVariable("input");
    var = var.toUpperCase();

    execution.setVariable("input", var);
    // Create a local variable named response to use this at OutputParameter Expression
    execution.setVariableLocal("response", "{\"name\":\"Response JSON Name Attribute\",\"id\":1}");
  }
}

I will attach the CSV files at the end of this big question :smiley: with query result to show RuntimeVariables at two execution scopes and a History Variables Instance where we can see the variables executions owners.

Process Diagram Example

execution_test_scope.png907×264 9.81 KB

I put a timer before and after Parallel Gateway to see at Cockpit which variables process instance will show as yours, and in the first timer we have 3 variables:

  • input: (defined just to satisfy ToUppercase logic)
  • name: (defined as OutputParameter using an expression: ${JSON(response).prop(“name”).value()})
  • const_value_output: (defined as OutputParameter with “ConstValue” )

(Sorry, but i’m a new user and i can not use more than one image, attachments and 2 links in this POST.)

In the second timer we have 4 variables:

  • input (only variable remaining from Service Task with Java Class before Parallel Gateway)
  • task_1_output (defined as OutputParameter by one of two task inside of Parallel Gateway) [Service Task using Expression Implementation]
  • task_2_output (defined as OutputParameter by one of two task inside of Parallel Gateway) [Service Task using Expression Implementation]
  • last_task_output (defined as OutputParameter by the last task outside of Parallel Gateway) [Service Task using Expression Implementation]

Here we can see that two of variables “name” and “const_value_output” are gone from RuntimeVariables, but still persisted at History Process Instance Variables table within the same execution which initialized the Process Instance.

Thanks,
George

2

Hi George,

Welcome to the forum. There is a known issue with variables set via output parameters and following parallel gateways, see https://app.camunda.com/jira/browse/CAM-8072. You might be seeing an instance of that. As a workaround, you can consider setting those variables directly within your service task implementation via API.

By the way, you can also write unit tests for your processes, see the following links:

That could save you the time of deploying to Cockpit and performing manual testing.

Cheers,
Thorben

1 Like