DelegateTask to JSON

Camunda 7 Topics Discussion & Questions
1

I’m trying to broadcast the info picked up by Task listener (building on the work in Comunda Reactor and the CDI integration ) to emit messages to a wider bus. Basically I want to take an instance org.camunda.bpm.engine.delegate.DelegateTask and convert it into json and then send it to rabbitMQ or maybe Kafka.

I would greatly prefer not to have to do this manually. I see I can get access to the com.fasterxml.jackson.databind.ObjectMapper on the spring context, but that doesn’t work with DelegateTask. Looks like it wants the TaskDto.

Has anyone tried converting one of the delegates into JSON? It seems like this must be a pretty common use case. All I need is a pointer in the least painful direction!!

Thanks in advance.

Robert
Brooklyn, USA

1 Like
2

For what it’s worth, I wound up creating a new DTO and manually mapping all the properties I needed in the constructor.

1 Like
3

Hi @rmoskal,

Could you please give some more details of what you implemented and how?
I may need something similar.
Actually I need to build a JSON message with task information and send it to a websocket message bus server.

Thanks,
Kostas

4

Good to see discussion on this topic. It’s my passion… apologies for the long-winded reply.

A few points on my approach

1) CDI and Camunda task integration via “expression”:
I inject "@Named(“myNamedClass”) into the java class and reference this from the bpmn model as “#{myNamedClass.myJavaMethod(execution)}”

2) JSON: for JAX-RS integration, I’ve followed a more loosely structured approach by avoiding object-type serialization. I switched to directly using jackson’s JsonNode. For example the implementation receives and directly consumes the payload itself - no type serialization overhead. My new approach saves a lot of coding (arbitrary type defs, exception handling, etc). However… Camunda may need to use a String conversion (Spin? Haven’t tested yet).

NOTE: I prefer a facade approach to BPM engine integration. In my opinion… (with some experience) this helps avoid training/documentation overhead with the dedicated SOA development team. And, we get to safely protect (wall in) potentially direct, risky calls into the engine via ad-hoc integration points…

Examples using a shared BPM engine:
source

@POST
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
@Path("bpmechopost")
public JsonNode bpmEchoPost(JsonNode hello)  {

[... and further down ...] 

// get the process variables
final JsonNode arrNode = hello.get("processVariables");
Map<String, Object> variables = new HashMap<String, Object>();

for (final JsonNode jsonNode : arrNode) {
	variables.put(jsonNode.findValue("name").asText(), jsonNode.findValue("value").asText());
}

// start the process
ProcessInstanceWithVariables pVariablesInReturn = runtimeService.createProcessInstanceByKey(processID)
		.setVariables(variables)
		.executeWithVariablesInReturn();

and building a JSON return from a completed task:


String piid = pVariablesInReturn.getProcessInstanceId();
boolean isEnded = pVariablesInReturn.isEnded();
VariableMap variableMap = pVariablesInReturn.getVariables();

[… build/return results…]

// this time we build a proper JSON return value - using Jackson
ObjectMapper mapper = new ObjectMapper();
ObjectNode rootObjectNode = mapper.createObjectNode();

// Extract completed process results or output
// set the process processID, InstanceID, and isEnded 
// variables as child JSON nodes
rootObjectNode
	.put("processID", processID)
	.put("processInstanceID", piid)
	.put("isEnded", isEnded);

[... and return ...]

return rootObjectNode;

});

3) Event Integration via Wildfly Artemis (built-in JMS implementation)
For brevity, just inserting the reference here.
And… github source

Once Camunda’s originating event is sent into Artemis-jms, it’s then available for consumption by the general integrated architecture (EAI). Though, I’m interested in using Camunda’s CDI event bridge… along-side “task events” - it’s on the to-do list.

NOTE: Apache-Camel provides a rich set of integration libraries - following the classic EAI event-routing approach. All very well documented

5