2

My team is considering if we can use mass transit as a primary solution for sagas in RabbitMq (vs NServiceBus). I admit that our experience which solution like masstransit and nserviceBus are minimal and we have started to introduce messaging into our system. So I sorry if my question will be simple or even stupid. However, when I reviewed the mass transit documentation I noticed that I am not sure if that is possible to solve one of our cases.

The case looks like: One of our components will produce up to 100 messages which will be "sent" to queue. These messages are a result of a single operation in a system. All of the messages will have the same Correlated Id and our internal publication id (same too).

1) is it possible to define a single instance saga (by correlated id) which will wait until it receives all messages from a queue and then process them as a single batch?

2) otherwise, is there any solution to ensure all of the sent messages was processed? (Consistency batch?) I assume that correlated Id will serve as a way to found an existing saga instance (singleton). In the ideal case, I would like to complete an instance of a saga When the system will process every message which belongs to a single group (to one publication)

I look at CompositeEvent too but I do not sure if I could use it to "ensure" that every message was processed and then I would let to complete saga for specific correlated Id.

Can you explain how could it be achieved? And into what mechanism I should look at in order to correlated id a lot of messages with the same id to the single saga and then complete if all of msg will be consumed?

Thank you in advance for any response

Bartosz Kowalczyk
  • 1,479
  • 2
  • 18
  • 34

2 Answers2

3

The ability to receive a series of messages and then operate on them in a batch is a common case, so much so that there is a sample showing how to do just that:

Batch Sample

Each saga instance has a unique correlation identifier, and as long as those messages can be correlated to that single instance, MassTransit will manage the concurrency (either optimistic or pessimistic, and depending upon the saga storage engine).

I'd suggest reviewing the state machine in the sample, and seeing how that compares to your scenario.

Chris Patterson
  • 28,659
  • 3
  • 47
  • 59
3

What you describe is how correlation by id works. It is like that out of the box.

So, in short - when you configure correlation for your messages correctly, all messages with the same correlation id will be handled by the same saga instance.

Concerning the second question - unless you publish a separate event that would inform the saga about how messages it should expect, how would it know that? You can definitely schedule a long timeout, attempting and assuming that within the timeout all the messages will be received by the saga, but it's not reliable.

Composite events won't help here since they are for messages with different types to be handled as one when all of them arrive and it doesn't count for the number of messages of each type. It just waits for one message of each type.

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83