Throwing SignalEvent programmatically in asynchronous way

Hi.
I’m using a custom java piece of code to broadcast a signalEvent to a bunch of listening processes.

Following the manual (camunda version 7.6):
runtimeService
.createSignalEvent(“signalName”)
.setVariables(variables)
.send();

So I’m able to broadcast signal to all processes with some payload (the variables). But the send() method apparently is waiting for those processes to finish before returning to my original java routine, unless they have an asyncBefore start event or they have some timers/async task inside.

I would like that the process engine will send the the signal and return to the original procedure as soon as possible, I don’t care about processes results or exceptions at this point.

So I’m asking: is it possible to send a SignalEvent in asynchronous way and return to caller immediately ? I know this should be possible through the camunda model setting the throwing signal as camunda:asyncBefore=“true” but I’m setting this call from pure Java code.

Hi @Michele_Zanarotti,

Unfortunately, I can’t see a way to do it manually. However, why don’t you just model it by using a non-interupting signal event?

Best,
Johannes

Given that Camunda is required to maintain state between task executions, it looks like you’re running into an issue associated with a sort of “catch-22” between state and event management.

Have you looked at specialized event-management infrastructure? The goal here is to off-load event requirements into something like JMS, Camel (etc.) so that task implementations aren’t necessarily extending inter-process communication beyond the boundaries required for database-maintained (or JTA) transactions (Camunda task execution).

I tend to rely on JMS platforms - and, prefer those built-into my application container/server (Websphere, JBoss, etc.) . And, Camunda integrates with these specialized event systems.

The trade-off is that you’ll loose some of the BPMN illustration, are at least those models set for “execution”, for services running within these specialized event frameworks. But, you could simply model complex event interaction as BPMN “black-box” or formal UML… In my experience, complex event process (CEP) typically requires its own set of specialized features/components. So, rather than extending a Camunda model, the camunda task implementation maintains its system boundary (functional envelope) by sending messages across the BPM/CEP system boundary via APIs (i.e. messaging).

Camunda provides an example of Camel integration illustrating their relationship.