How to model multiple Sagas that handle a common message type?

[Plamen Boudinov]

Lets say we have a Communication service endpoint, which sends predefined Email/SMS/Viber messages to customers. When SMS gets delivered to a mobile (notifed either through external webhook or periodic status poll), this endpoint raises an event of type CommunicationTaskStatusChanged.

These tasks can be modelled as sagas or separated handlers, which should not matter?

We can have many CRM sagas which request to send some customer communication by sending command to Communication endpoint containing some correlationId property.

All these Sagas are interrested in events CommunicationTaskStatusChanged, which could mean that some SMS or Viber communication got delivered or delivery timed out. These events will bring back the correlationId.

If all Saga handlers have the same signature void Handle(CommunicationTaskStatusChanged message..), then all of these Sagas will be Queried upon their correlation data by the CommunicationTaskStatusChanged mapping. But only one saga type is interrested in the status of this particular communication message. So this seems wrong, to make the infrastructure query sagas that are not involved at all.

Should the CommunicationTaskStatusChanged event somehow be explicitly routed back through auto-correlation, to specific Saga type + Saga Id?

* Note that if it was not CRM sagas, but separate CRM event handlers, during handling we can decide if we are interrested in the StatusChange of this particular predefined Communication task type, not making persistence queries at all. 

Something is designed or described wrong here, can someone help me point it out please!

Thanks a lot in advance!

[Plamen Boudinov]

This question is about sagas as defined in NServiceBus or Rebus(in the letter there is no auto-correlation using message headers)

[Greg Young]

This might be better on an nservicebus group as it is rather
nservicebus specific

On Sat, Jan 21, 2017 at 1:29 PM, Plamen Boudinov <boud...@gmail.com> wrote:
> This question is about sagas as defined in NServiceBus or Rebus(in the
> letter there is no auto-correlation using message headers)
>

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Plamen Boudinov]

Did that, but the question is also about design and then, whether i should use Sagas at all, either in their Process manager or Workflow flavour.

[Alexey Zimarev]

In MassTransit I would explicitly specify the CorrelatedBy<Guid> interface for those messages (both command and resulting event) and it won't hurt to have several get-by-id-style requests to the saga persistence. In such scenarios where only technical moving parts are involved, I would always prefer explicit correlation id.

[João Bragança]

Why not use different event types here? The key for me is 

> But only one saga type is interrested in the status of this particular communication message.

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Alexey Zimarev]

I guess because there any multiple sagas sending those messages and only two infrastructural components that take care of those messages. It would be quite illogical to bind technical services to logical process managers. The set up is correct, how to handle those is another story.