nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Events and Signals Scope

matt1

From what I can tell from experimenting and from the docs neither Events (Messages) nor Signals are by default scoped to the current process instance.

The docs state:

To restrict the scope of the signal event, add the (non-BPMN 2.0 standard!) scope attribute to the signal event definition:

&lt;signal id="alertSignal" name="alert" activiti:scope="processInstance"/&gt;‍

I just want to be certain because later in the docs it says the following which seems to contradict what is above:

Note: the signal event does not perform any kind of correlation to a specific process instance. On the contrary, it is broadcast to all process instances. If you need to deliver a signal to a specific process instance only, perform correlation manually and use signalEventReceived(String signalName, String executionId) and the appropriate query mechanisms.

I'm just not sure and can someone please verify the exact behavior?

Many Thanks,
Matt

Find more posts tagged with

Comments

martin_grofcik

Hi Matt,

Signal is broadcast (see jUnit test in activiti source org.activiti.engine.test.bpmn.event.signal.SignalEventTest#testSignalCatchIntermediate)
from the activiti user guide

The difference between signalEventReceived(String signalName); and signalEventReceived(String signalName, String executionId); is that the first method throws the signal globally to all subscribed handlers (broadcast semantics) and the second method delivers the signal to a specific execution only.

 <signal id="alertSignal" name="alert" activiti:scope="processInstance"/> activiti:scope is activiti specific process model extension.

Regards
Martin

matt1

So, to be clear, when I use <code>activiti:scope</code> I can be confident that the signal is scoped only to the current process, correct?

matt1

Another part of the issue I'm having is the executionId. In ExecutionListeners and in services I'm finding that the execution that is passed as an argument is a child execution. And, attempts to get the parentId or parent return null.

I've read a number of posts and the only way I seem to be able to get at the parent execution is to access the database directly. Is there some reasons why the parent (root) execution is not available?

jbarrez

> Is there some reasons why the parent (root) execution is not available?

There could be many reasons, but without the process it's hard to make a statement.

fedd

Hi, I am interested in this question too. Just to be sure, that in the documentation, the "Signal Event Examples" section, authors could add a note that the unwanted behaviour explained on a picture with the big sad face can easily be fixed with the Activiti specific model extension.

Am I right to assume that this section was written before the "activiti:scope=processInstance" extension was introduced, and was not changed since.

Or is this extension uncapable to fix the unwanted behaviour of the last example?

jbarrez

@fedd: you are correct. I've fixed the docs. It'll come in a next update. Many thanks!

fedd

Thank you!

I would dare to ask your team consider to create a message receive construct and move this process instance scope feature to messages rather then signals. I personally find it confusing that we can adjust a signal from being engine wide straight to a process instance wide, missing something in the middle (like inter-process messages). In other words, signals are wide, messages are narrower, and process instance scope is the narrowest, but they are signals again (which may be confusing to users and newbies like myself)

(I am implementing an interprocess messaging for my project, which will just invoke a 'messageEventReceived' method, and I am able to cope with the problem of identifying an exact process instance that a message should be aimed to in a project specific manner.)