Mapping a message to multiple Saga Instances

[Victor Chircu]

Hi,

In the Saga documentation, it is stated that "Mapping a single message to multiple saga instances is not supported.".  What it isn't clear to me if this issue is limited to saga instances of the same saga type? Does NServiceBus support mapping the same message to 2 different saga instances of different saga types? My tests say that it doesn't, but I just want to be sure. I'm using NServiceBus 5.2.0. and NServiceBus.NHibernate version 6.2.2.

Thanks,

Victor

[Sean Feldman]

Hi Victor,

You can have multiple sagas of different type kicked off by the same message. You can't have multiple instances of the same saga type, but different saga types are ok.

Think of it as one message that triggers two different business processes. 

What kind of test you're referring to? Could you share your code?

[Victor Chircu]

Hi Sean,

Thanks for the response. What if both Sagas are deployed in the same endpoint? Could this be an issue?

We have 2 Sagas deployed to the same endpoint. Both Sagas should handle the event, but it is handled only by one Saga type. If we comment the Handle method in the first Saga, then it is handled by the second Saga.

If this should not be an issue, we will create a small code example and share it.

Thanks,

[Andreas Ohlund]

A single message can be mapped to multiple sagas of different types. (I'll make sure to clarify this in our documentation).

>My tests say that it doesn't, but I just want to be sure. I'm using NServiceBus 5.2.0.

This should definitely work in v5, can you share your test code?

Cheers,

Andreas

On Thu, Jan 21, 2016 at 2:12 PM, Victor Chircu <victor...@gmail.com> wrote:

Hi,

In the Saga documentation, it is stated that "Mapping a single message to multiple saga instances is not supported.".  What it isn't clear to me if this issue is limited to saga instances of the same saga type? Does NServiceBus support mapping the same message to 2 different saga instances of different saga types? My tests say that it doesn't, but I just want to be sure. I'm using NServiceBus 5.2.0.

Thanks,

Victor

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at https://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/3482eba2-eda7-4f6b-909b-a934c3068396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin Alexander]

I've done this successfully in the past. The issue you're experiencing may be unique to the build or configuration you are using. For example, have you attempted to control the order in which the handlers are invoked against this single message type? It would be interesting to see of the behavior changes when these options are or are not being invoked.

[Mitch Wagers]

We have two different sagas, activated by different commands. Both sagas are listening to the same Event on the Bus AFTER they are activated, and what is referenced in this thread does not work. We are only able to get one saga at a time to listen to an event after it has been activated. I reviewed a lengthy thread that said Particular was not going to support this (that was back in 2012-2015). So, we need a definitive answer whether this scenario is supported or not? This is a REALLY simple business case, so it seems very limiting that two sagas can't listen to the same Event, especially when they are initially activated by different commands. This is a real blocker for us.

[Justin Alexander]

Hi Mitch,

Can you share some additional details about the two sagas that are not behaving as you expected? A repro would be ideal.

The reason I am focused on increasing my understanding of the specific application you are working with is that having a single message interact with different sagas hosted within the same end point is a very common scenario. As I wrote in the post you responded to from 2016, we have a number of NSB-based systems that exhibit this design. 

What NSB has NEVER supported is having a single message interact with multiple instances of the SAME saga type. Some of the references you cited imply that you may be conflating these two scenarios.

I think the most relevant details for you to share would be:

1. Both of the classes that inherit from nServiceBus.Saga (with references to IamStartedByMessages<T> and IHandleMessages<T>)
2. ConfigureHowToFindSaga() method from both saga classes (with references to Saga.ConfigurMapping<T>)
3. The Handle() methods for the shared message type in question within both saga types
4. Classes that inherit from IFindSagas<T> (if you have any)

~Justin

[Mitch Wagers]

Justin,

Here you go, they are attached. Just to note in our case, it is unacceptable behavior for us to design our saga instances around how the deployment is done (same endpoint vs. different endpoints); that strategy smells funny to me.

Our classes do not have ConfigureHowToFindSaga(...), it seems redundant to ConfigureMapping(...), or I don't understand the difference. It is imperative to understand within the attached files, that the two sagas are no longer listening to the same event as we have worked around the issue, in a much simpler way than was described on the long forum thread that I read from 2012. That said, when they did listen to the same event, only one saga "received" it. Since that saga's data didn't contain the InternalTransactionId as per the mapping, the message was then dropped and the saga that was supposed to receive it never did.

I'm also confused as to how I'm conflating the two scenarios? I don't see a resolution in this thread, am I missing it? What I see is that OP didn't reply after the last message, but we are also not using v5 of NServiceBus.

Thanks,

Mitch

[Troglite]

Hi Mitch,

The code samples you provided are helpful. I'm up against a hard deadline within my own work at the moment, so I haven't been able to test the observations I am about to share.  But, I wanted to at least provide some high-level guidance you can consider before more time passes.

Probably the most practical advice I have to offer is to start a new thread instead of adding to this old one. The Particular team monitors new threads that do not receive a response within a reasonable window if time... so your chances of getting an authoritative response will be much higher. 

I don't fully understand the differences between ConfigureHowToFindSaga and ConfigureMappings either. This was the best reference I could find.

https://docs.particular.net/persistence/sql/saga

And ConfigureHowToFindSaga is

 documented here. 

https://docs.particular.net/nservicebus/sagas/message-correlation

I can tell you that my team has a large number of sagas that rely on the ability to have a single message shared bwtween them and that all of the mappings for these sagas use ConfigureHowToFindSaga. We also use MSMQ... so if "ConfigureMappings" is being provided by a custom saga persistence class that is tied to the SQL Server Transport... it would explain why we don't use ConfigureMappings and potentially why we haven't experienced the problem you described. 

I did not suggest in any way shape or form that you should "design ...saga instances around how the deployment is done". I agree completely that this would be a bad practice. I think the confusion arises from the fact that sharing a single message across multiple saga types is only a concern if the sagas are hosted in the same end point. If the saga are distributed across multiple end points, then the message is no longer "shared" b/c a separate message will need to be sent to each of those discrete end points.

On your last question, you had referenced other threads on this topic without providing a link in your first post. The beginning of this thread starts off talking about multiple instances of the same saga class interacting with a single message. This is NOT supported. Your code sample clearly indicates you are focused on an entirely different scenario where two different saga classes interact with a single message. This IS FULLY supported and has been for quite some time.

I've worked with NSB long enough to know that these two scenarios are often confused. My intent in pointing out the inconsistency between your question and the beginning of this old thread was to give you an opportunity to either convey that you were already aware of these differences or ask for clarification.

Anyway, I hope this information is helpful.

Justin

--
You received this message because you are subscribed to a topic in the Google Groups "Particular Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/particularsoftware/UwRtEjXe5YA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to particularsoftware+unsubscribe@googlegroups.com.
To post to this group, send email to particularsoftware@googlegroups.com.

Visit this group at https://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/37a5dbcf-60a2-4764-bd51-ba8313bf7b5d%40googlegroups.com.

[Andreas Ohlund]

Hi Mitch!

Just like Justin mentions having multiple sagas of different types react to the same message is fully supported.

Looking at your attached code it seems that your mappings are incorrect. They miss the `.ToSaga(s=>s.SomeID)`.

See 

So in your case 

`mapper.ConfigureMapping<SC.Notifications.Commands.RegisterUserCommand>(message => message.InternalTransactionId);`

should become

`mapper.ConfigureMapping<SC.Notifications.Commands.RegisterUserCommand>(message => message.InternalTransactionId)

.ToSaga(s=>s.InternalTransactionId);`   

Does this help?

Cheers,

Andreas

To unsubscribe from this group and all its topics, send an email to particularsoftw...@googlegroups.com.

To post to this group, send email to particula...@googlegroups.com.

Visit this group at https://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/37a5dbcf-60a2-4764-bd51-ba8313bf7b5d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.

To post to this group, send email to particula...@googlegroups.com.

Visit this group at https://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/CAK%3DtXobcHFDPV3c7B6KQJpL3sbPmnqmB9_NeyB4v7E9Cg5CBZw%40mail.gmail.com.

[Andreas Ohlund]

Sorry I forgot the link to our mappings documentation

https://docs.particular.net/nservicebus/sagas/message-correlation