Let each workers set their own work to completed while the saga effectively polls using delayed messaging to see if all work is done. Of course, he's specifically talking about NServiceBus, but the problem and concepts are the same.Ĭreate an external storage. Jim has another post that came after the one you referenced that outlines the issue and solution. The problem with kicking back finished events to the saga is that it creates contention on a shared resource (i.e the saga state). Then you can on the implement a virtual method that the saga can use to do the 'generic' thing when it's picked up, and you only have to implement overloads for those special items, that require something special to happen? I imagine it being sent to the queue via a Generic method, where the object must implement IFoodOrdered When the saga listener gets an 'order completed' Event it would contain the object that is completed in the event? If ( (x => x.Schedule(CheckAllRequestsDone, context => new CheckAllRequestsDoneCommand(context.Instance)))Ĭouldn't you 'simply' pass the object along in the queue, as an event parameter?

RequestsStates.All(x => x != nameof(MyRequestStateMachine.Processing)) Schedule(CheckAllRequestsDone, context => new CheckAllRequestsDoneCommand(context.Instance)) Periodically check that all requests done (by 'Reducing NServiceBus Saga load'): Schedule(() => CheckAllRequestsDone, x => x.CheckToken, x =>Ĭ = ( 10) RequestsStates.All(x => x != nameof(MyRequestStateMachine.Processing)) // assume 3 states of request - Processing, Done and Failed return allDone Var requestsStates = db.MyRequestStates.Where(x => x.ParentSagaId = ).Select(x => x.State).ToList() Var db = serviceProvider.GetRequiredService() Schedule(FailSagaOnRequestsTimeout, context => new FailSagaCommand(context.Instance)) X.Received = e => e.CorrelateById(context => ) Īwait context.Publish(context => new MyRequestCommand(context.Instance, 'foo')) Īwait context.Publish(context => new MyRequestCommand(context.Instance, 'bar')) Ĭ = DateTime.UtcNow + FailSagaOnRequestsTimeout.Delay Ĭ = 2 (Need to complete them at some time later.) So instead of saving number of completed nested sagas in parent saga I just query state of child saga instances.Ĭheck on every MyRequestDone message: Schedule(() => FailSagaOnRequestsTimeout, x => x.CheckToken, x => I came into similar problem - need to publish few dozends of commands (all same interface, IMyRequest) and wait all.Īctually my command initiates other saga, which publish IMyRequestDone at the end of processing without marking saga completed. Given the above concerns - what would a good saga example for this type of workflow look like? This would be very tedious if you had to do that for every item in the kitchen? Ex: FriesOrdered, BurgerOrdered FriesCooked, BurgerCooked. But I'm not sure how else you would do it with out creating a message request and response and correlating Event for each food item in the kitchen. However after reading warnings here regarding sharing of queues and noticing that Consumer.Conditional filtering has been removed with MassTransit 3.0 It feels as though the framework is saying 'Bad Things(TM) will happen' with this type of approach. Since the Saga doesn't care about the type of food completed just the fact that all the food is completed this would seem to be an OK solution. Ex: fries and burger station gets a message regarding an order of Fries, The fries station consumes the order announces an ItemDoneEvent that the saga is listening for. To have a common interface for all of the types of FoodOrdered events that all of the food stations would get and then each food station would be able to consume/create its respective item and publish a common done event. Workflow image stolen from above article: Jimmy Boagard describes a McDonalds fast food chain here comparing it to a scatter gather pattern.

Masstransit listener