Routing Slip, Activities & Co.

[codebrainr]

Hi,
I have some questions about Masstransit Sagas, Routing Slip & Co. anyone can help me?

1. When creating a Saga, it's valid to embed business logic in the "Then" method responding to an event?
2. It seems that there's no way to "stop" an executing routing slip right? And if so, what if started a set of steps, and while the activities are running
   an event is published which must abort or cancel the routing  slip execution?
3. It's a good practice to start a routing slip from a saga?
4. Could be considered a good design to make an activity of a routing slip long running? like for example downloading a content?

Thanks in advance

cheers

[maldworth]

1. I think Saga's should only care about events and State. There can be business logic (to determine state based on some details in the event), but if there is any I/O required, this should not be the responsibility of the Saga, and should be out of process.

2. I'm not that knowledgeable with Routing Slips, but I don't think there is a way to halt it from an out of process event. The routing slip Activity(ies) wouldn't be able to listen to some out of band event to act on it, it would have to be some tracking service (parent saga). You "Could" possibly have a routing slip activity "Between" each regular activity that perhaps checks some persistent store where you have a flag whether the routing slip should continue or stop (i.e. compensate). But that has some design "smell", so I'd tread carefully.

3. Again, somebody with more knowledge can correct me if I'm wrong, but I don't think there's any problems with starting a slip from within a saga.

4. How long running? Maybe read about Turnout http://docs.masstransit-project.com/en/latest/advanced/turnout.html

[Chris Patterson]

1. Sagas are all about business logic, but more the logic around decisions versus action. Actions should be performed by services which are coordinated by the saga. Since the saga is an intersection of state and behavior, it's important to keep it "alive" -- and available. By alive, I mean not sitting waiting on a thread for a remote call to complete -- because sagas are executed typically within a database transaction. And that isn't something which should take a long period of time.

2. A routing slip should be designed around the "do it all, or fail and don't do anything" mentality - AKA, a transactions. Courier was created to model distributed transactions, which can scale immensely compared to database-oriented transactions. When a routing slip is executed, it's expected to run to completion, or fault and compensate any completed activities prior to the fault. Only an activity should be able to dictate that the transaction should either be faulted (aborting early) or terminated (ending with a "nothing to see here, move along").

3. It is, but consider the implications and perhaps a hybrid approach makes sense. In our systems, we execute a routing slip if the command to a consumer is "clean" -- no retries, no re-delivery flags. Typically we can expect that this message type is idempotent in our back-end system, so processing it multiple times has no effect more than processing it once. So we'll execute the routing slip immediately, and track progress using a saga. If the routing slip faults, we have a complex retry engine designed to coordinate and schedule retries for the message so that it ultimately gets processed. In that case, the state machine sagas are indeed executing the routing slip as part of the retry/recovery path. The actual routing slip itself is initiated by a separate consumer, the state machine just sends the command to the consumer to initiate it.

4. Yes, activities can do long-running things, within the consumer time limit of the transport. If it's super long, something like Turnout might make sense, but in most cases pulling content via HTTP is easily done within a routing slip activity. We send to HTTP/SOAP endpoints using activities all the time, so yes, it's a common example of an activity.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/2244c706-1da0-4f09-ba2d-9738d3072580%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.