You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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();
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.
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.
In the previous release of this task, the following variables were returned:
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:
simple-http-process.txt
The text was updated successfully, but these errors were encountered: