Signal Events - Versioning Query

[Hammad_Dar]

The documentation states that:

Process versioning: Upon deployment of a new version of a process definition, the signal subscriptions of the previous version are canceled. This is also the case for signal events that are not present in the new version.

A parent process generates a signal event at a certain point. The parent process has kicked off but has not reached to a point where that event would be generated.

Process definition gets updated with a new version while the old version process instances are still not finished yet. Would the event which is required to be generated by that old version of the process definition would still be generated once that execution reaches to the point or not?

What is the best approach towards designing a system based on events? Signal Events appear to be the best fit but the quote above from the documentation can be a problem in case of new version deployment.

Looking forward to hearing from Camunda experts.

[StephenOTT]

The signal API is very much a “everything” approach. The Message API can do the same things as the signal but has much more control available to target messages.

What are you use cases for using events?

[Hammad_Dar]

Hello @StephenOTT - Thank you for your reply.

Well I want to start multiple child processes on an event from the parent process. As we do normally in Java where an event is published and everyone who is interested in that event will pick it up and do the work.

As more than one process with message start event having the same message name is not possible, I assume Message Events are not the way to go. Please do share your thoughts on the best way forward.

[StephenOTT]

How many child messages are you expecting to generate for a single parent?

If you are expecting to start instances with a Message or Signal, what are worried about for the overwriting of the subscriptions?

Your use case is very abstract: if you provide a bit more business detail a more appropriate business solution can likely be suggested.

[Hammad_Dar]

I have a state which when reached in a process, I want three child processes to be kicked off. I have used Call activity and it works like a charm. I tried with Message Events but each child process requires a unique message name against which it will start, which means, I had to generate three unique message events. I don’t want to do that for obvious reasons.

Lets say I have an order which when materialized, needs to kick off billing and shipping processes in an event driven way. Does that make sense?

[StephenOTT]

The message does not have to have a unique name. You can use the “Correlate All” feature to correlate your message with multiple subscriptions.

You can use a single message name, and then use the Message Correlation builder API to set the correlation restrictions/scope (such as a specific definition id, key, process variables, etc).

You could create a process that has a “new order” message start event. That process would trigger the other events such as “billing, shipping, survey, etc”

[Hammad_Dar]

Yes I did that but problem is that my logic of creating events would be required to be changed whenever a new service is introduced for any event. I wanted to generate an event and let multiple processes pick that up and start their work as per their specs.

For this, is signal event the only choice?

[Ingo_Richtsmeier]

Hi @Hammad_Dar,

the section from the docs you posted in your first post applies only to signal start event. The behavior is the same as for any new process deployment where you start the process instance with runtimeService.startProcessInstanceByKey("myProcess");.

I think signal start events are a good fit for your use case.

Hope this helps, Ingo

[StephenOTT]

@Ingo_Richtsmeier using signals in this pattern, especially if we are talking about billing and shipping / commerce, means you lose any targeting control for selective execution:

Consider the following:

The Signal API: SignalEventReceivedBuilder (Camunda BPM Javadocs 7.14.19-ee)

The Message API: MessageCorrelationBuilder (Camunda BPM Javadocs 7.14.19-ee)

Signal Events generally mean a “all or nothing” trigger: Sure you can “find” the pre-existing executions, or filter by tenants, but at a “business level” those do not mean as much as specific process definitions, (IDs and Keys), local variables, variable targeting, Start Message Only targeting etc.

–

In the BPMN above if you consider column 2 with the signals, you start the process (such as a commerce purchase) and the end event triggers the “New Purchase” signal. Multiple process defs are started (lets say “Billing, Shipping, Post-Purchase Survey”).

very quickly businesses will add additional more event driven scenarios such as “Post 6 Month Survey”, “Multi-warehouse events depending on products”, “Single or multiple shipping events”, “Conditional Exchanges”, etc.

Signals fall apart because “everything” becomes activated.

From Camunda BPMN Engine perspective: using the Message API, you can create conditional targets all with the same Message Name. Message Events B, C, D, and E could all have the same message names but you can target which definitions to start conditionally.

When B is triggered from column 1 row/pool 2, the Start Event that is triggered could be Col 1, Row 4, or could be col 1 Row 5+6+7. If we use the Signal API, we do not have these capabilities

[Hammad_Dar]

@Ingo_Richtsmeier Thank you for the reply.

@StephenOTT I agree with your that with events, we lose the “selective execution” capability and things go out of our hand. I see your point and assume that what you mean is “because BPM is orchestrating the business flow and it is a tool to take control of how things move forward, signal events have the capability to take control out of our hands”. Is that what you meant?

I assume that you are in favor of below modeling technique:

[StephenOTT]

Depending on your architecture, you risk having race events, where the Message is sent back to your workflow before the Receive message task is ready to receive. (transactions are committed).

There are multiple patterns available depending on the specific business flows you need.

here is a option (untested- you not a 100% it will work as described, but the flow is relatively the same: You may need to use conditional events and variables, but async ~should work as described in diagram): works

[Ingo_Richtsmeier]

Hi @StephenOTT and @Hammad_Dar,

usually I’m not a fan of signal events, as many users tend to misunderstand the one to many relationship. Especially when you use them as intermediate or boundary events.

But for start events it’s a different thing.

You can’t use the same message name in different start events - they have to be unique here. But you can use the same signal name in different start events in different processes.

To get a one to many relationship between parent-child processes, you can either use multiple message end events to start the following processes, or use a single signal throw event and start multiple processes.

Now it’s a matter of taste and flexibility which approach is better for you.

Downside of messages is that you may need to add a new end event to a running process. Downside of signals is that you have to be careful with the names.

I haven’t considered to join the processes later.

Hope this helps, Ingo

[StephenOTT]

Though because Messages have to be “programmed” (they don’t get auto sent when the token arrives), it raises a good point /feature that is missing from the API:

Ability to query for event subscriptions by eventNameLike https://jira.camunda.com/browse/CAM-13407