Address all saga instances with one message

#1

We have the requirement to address all running saga instances of a specific saga type with one message (business requirement is a kill-/finish-signal to all saga instances in certain (rare) occasions). Does NSB provide an elegant approach for this or is this something that we have to do on our own (e. g. persisting the IDs of all running saga instances and sending a command to each instance)?

Thanks!
Tobias

#2

Hi Tobias,

Every incoming message is mapped onto a saga instance, with which the saga is loaded from the database. There’s no way to somehow send a message to all instances at the same time.

Perhaps you can go into more detail what it is why you on rare occasions, want to end all saga instances at once?

Other options is to query the database and find the instance and then send a message to the saga using the right identifiers. But what NServiceBus does when you MarkAsComplete() a saga, is simply remove it from the database. You could do exactly the same yourself?

#3

Hi Dennis,

thanks! We indeed ended up in querying the database and sending a message to each saga instance. That should be OK for our needs.

Tobias

#4

Hi Tobias,

Like Dennis I would also be interested to get a better overview over that business requirement. Would you mind sharing a bit the context there? We are usually asking in order to find potential gaps in our offering or sometimes knowing the context better helps us to give more guidance in the right direction.

Regards,
Daniel

#5

Hi Daniel,

I’ll try to go into some details:

-our system receives applications (governmental context) in a specific message format (specific XML standard)
-then it processes each application in a long running (days or weeks) process (saga): it makes requests to other systems (using the same XML standard) in order to collect additional information and finally submits the application to the final receiver (using the same XML standard)
-the XML standard evolves/changes from time to time (about twice a year)
-the systems can only support exact one version of the XML standard at one point in time
-just before the update to the new version of the XML standard the existing sagas have to be terminated (custom logic and then deleted) because they can’t be processed with the new version any more

Tobias

#6

Hi Tobias,

How many of those sagas will you have? Is it an unbounded list?

Why is the saga dependent upon the XML Standard? Does the change in the XML standard affect how the process is coordinated by that saga too?

Regards
Daniel

#7

Hi Daniel,

in theory it’s unbounded (depending on business load). In practice there are less than 100 at the moment.

The saga itself is dependent upon the XML Standard because it saves the initial incoming request (XML Standard) in its saga data and generates outgoing requests from it.

Regards,
Tobias

#8

Tobias,

Have you thought about making the saga only focusing on the process flow and moving the actual XML version specific part to the processing logic of the workflow within handlers? So not actually storing the XML standard in the saga but putting that into some kind of blob storage that you only store the reference to that blob in the saga?

Daniel

#9

Hi Daniel,

thanks for your suggestion!

If I am not missing your point storing the XML outside of the saga does not solve the problem. We have still the problem that existing applications have to be terminated because we can’t transform the XML.

Tobias

#10

Hi Tobias

So you can’t transform the current XML to the new one by up converting it? Because if you could when the XML payload is decoupled from the saga data you could receive correlated messages for a specific saga instance that load an individual saga, determine whether it can be migrated, do a SendLocal to do the migration process, reply to the saga and continue doing the processing. If up converting is not possible, the saga could then Mark itself as completed and triggered corresponding messages that indicate the non-successful completion of the saga.

Daniel

#11

Hi Daniel,

yes, we can’t transform or rather it’s a business decision that we shouldn’t (too much effort and too much risk that something goes wrong). That’s why we jump directly to the second scenario and cancel all sagas.

That said your design suggestion with the two sagas and external storage would have been an elegant solution for the transformation scenario :slight_smile: .

Thanks!