camunda-community-hub/zeebe-http-worker

Variables returned from HTTP task are no longer available in parent scope

Opened this issue · 2 comments

In the previous release of this task, the following variables were returned:

  • statusCode
  • body

Without defining any output mapping, it was possible to reference these variables in downstream paths of a workflow. For example, I used the statusCode in one branch of the exclusive gateway as follows:

statusCode == 200 && someOtherProperty != null

This worked.

With the current release, statusCode is no longer available in scope of the parent process. Meaning this variable can no longer be used in downstream steps or conditions unless you define an output mapping on the http task as follows:

Output Mapping:
source: statusCode
target: statusCode

According to the literature, if output mappings are not defined, variables returned from a task or process will be merged into the parent variable scope.

Please refer to the BPMN model and rename from .txt to .bpmn.

Associated code to run the workflow is as follows:

DeploymentEvent deployment =
				client.newDeployCommand().addResourceFromClasspath("simple-http-process.txt").send().join()

        	OffsetDateTime now = OffsetDateTime.now();

		final Map<String, Object> post = new HashMap<>();
		post.put("userid", "1");
		post.put("title", now.toString() +  ": it's all about clean code");
		post.put("body",  now.toString() + " : read some good books on clean code");

		// FOR REST, you specify payload as parameter like this.  In other words there must be context variable called "body"
		final Map<String, Object> payload = new HashMap<>();
		payload.put("postToCreate", post);

		WorkflowInstanceEvent wfInstance =	client
						.newCreateInstanceCommand()
						.bpmnProcessId("simple-http-process")
						.latestVersion()
						.variables(payload)
						.send()
						.join();

simple-http-process.txt

saig0 commented

Hi @Klaus-Nji-sp,

I don't think that this behavior was changed in the latest release.

In your example, I see that the task has an output mapping to pass the body to a given variable. If one output mapping is defined then the default merging behavior is disabled and all variables have to be mapped explicitly. Otherwise, the variables are not merged.

Does this make sense for you?

If one output mapping is defined then the default merging behavior is disabled and all variables have to be mapped explicitly. Otherwise, the variables are not merged.

@saig0 , that does not sound quite accurate. Using the same example, I removed the mapping from body to postCreated and kept the mapping from statusCode to createPostStatusCode and there was partial mapping. The variable createPostStatusCode was available for use in conditional logic.