Signals in Call Activities or how to pass process variables into sub layers

I reorganized my BPMN and introduced some Call Activities which I use as sub layers to make my main process clearly arranged and increase reusablitiy. That worked quite well until I created a new BPMN file. The first new files are just copies of the first process where I deleted some parts. In all parts I use a signal called “MachineUpdate”. The copys contain the same signal as the original, in the new file I created a signale with the same name again (so only the id is different). And suddenly the signal can’t be delivered. The execution of my plan stopped and nothing happend. I can change the id directly in the xml file (and make the plan work again), but I don’t think that this is the way to go.

I use the signal to receive some process variables which I use in my gateways (using the method signalEventReceived in RuntimeService). Here is another problem: It is not possible to use the same process variables in the underlying execution. I solved the problem by adding a signal event right after the start to wait for another MachineUpdate. But is there a possibility to pass these variables into the call activity?

Or did I used the call activities wrong?

You can certainly pass those variables into the Call Activity, it would be a lot easier as well.

I’m interested in seeing what you’re doing with the signals - can you upload your model?

That will help a lot.
Here is the subprocess I am working on:


the annotations are written in german but I think you can understand it anyway.
I think I still have the same problem with the MachineUpdate-Signals… why can’t they found their recipient?

Where exactly are the signals being fired from?
Also - why exactly do you need signals? is the main purpose passing data to the instance?

I use a self developed application which will be executed on a machine. The signal will be fired if there are new PLC data which will update the process. All sub processes need to use the same data.

What API call are you using to send the signal?

I use some code which is developed here in the University of Bielefeld. In fact I use the Java Call: org.camunda.bpm.engine.RuntimeService signalEventReceived(String string, Map<String, Object> map);
does that aswer your question?

That seems ok to me.

Is it possible that the signal is sent BEFORE the token has committed it’s state to the database?

sorry I don’t understand the question
I only use that method to publish new PLC data so there is no other database or am I wrong?

How would you design an update process from an outer asynchronous source?

At moment i don’t think there’s a problem using the signal event to tell the process to continue.
I just need to understand the sequence of events a little better.
So when the process starts it begins waiting for the MachineSignalEvent which makes sense and then at some point another system using the Java API sends a signal to the engine that matches the signal the process is waiting for and the token should move forward.

You mentioned that the current problem you’re having is that this used to work ok but now it doesn’t since you added another process which waits for the same signal?
Just to help me understand better whats happening:

how long is a process expected to wait until the signal is sent?
What exactly prompts the signal to be send - does the process request the data to be sent?

It seems like there was a problem with a TaskListener I created. I removed the TaskListener and there is the expected behaviour. Thanks for your help :slight_smile: