Synchronous command handling for process managers/sagas.

[Jordan Neuhart]

I'm curious about how or if others are handling synchronous processing of commands which are send from process managers/sagas. My current architecture assumes synchronous command handling in ASP.NET MVC, i.e. controller -> command handler -> events -> persist in EventStore. Now, I'm looking at adding an event sourced process manager/saga for a certain case and I'm a little stuck at what to do with/where to send commands generated by the process manager. The process managers will be initiated and handled by one or more Event Processors running in a separate process. For the commands generated by the process manager, do I:

1. Submit them back through an API controller method and have them processed through MVC again.

2. Handle them immediately in the same process as the Event Processor.

In the second case, the flow would be something like this EventStoreSubscription -> Event -> Process Manager-> PM generates state events and commands -> Save PMstate events in EventStore and register future PM timeout event -> Command Handlers -> Aggregates -> Events -> Save Aggregate Events in Event Store. I'm leaning more toward the second option because I think the retry logic would be less complicated and it would be less prone to infrastructure problems. I'm still not sure what I would do with commands that just "disappeared" but the timeout event should give me a catch all solution to any unforeseen problems/bugs that come up when handling commands. I'm not saving the commands, so won't be able to retry them. Has anyone else done something like this? Any issues you experienced?

Thanks,
Jordan

[Jordan Neuhart]

I should also mention that I am trying to avoid using a service bus if at all possible. I'm not really interested in more complexity at this point.

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/ULNa0S_eDLo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

email: jjne...@gmail.com
cell: 402-217-1377

[João Bragança]

#2. You can write a checkpoint to a stream after successfully handling a command.

--
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.

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

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Jordan Neuhart]

What would the checkpoint be based off of in this case? Since I wouldn't be storing my commands in ES, except maybe for logging purposes, I wouldn't have a global command checkpoint to use and I would have to find some way to generate checkpoints within the context of an individual process manager.

It might be better to just store the process manager's current state in the timeout message. If I get the message back and have not advanced in state then I know something went wrong, and, depending on the specific case, I can retry the command or I can indirectly, via an error message, ask a user for manual intervention. Of course this assumes that there aren't any bugs in my timer service which is returning the timeout events.

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

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

--

email: jjne...@gmail.com
cell: 402-217-1377

[João Bragança]

The  checkpoint of the event that triggered the command. In many ways it's like a projection.

[Jordan Neuhart]

So use the event Id as a causation Id on the command? Interesting. I'll have to think about it a little more.

[Anderson Muller]

What do you save as the data of the PM state events? Is it the copy of the original event, is it a generic CheckpointReached event with the PM state as the data?

[João Bragança]

I tend to event source my process managers so  i use a generic CheckpointReached after any command(s) have been successfully processed.

[Anderson Muller]

OK, but then how does that event look like? What do you have in the event data? The original event data, or the PM state after you processed the event, or something else?

[João Bragança]

Nope just the checkpoint token of the last event that I processed. If I crash, I get my last checkpoint token. Then I replay the stream I am listening to through my process manager. This of course generates the commands again, but I will drop them until I get an event whose checkpoint token > my last checkpoint token.

[Anderson Muller]

OK, got it, thanks for the explanation.

[Jordan Neuhart]

Yes, it would be a copy of the original event. So the event gets saved in more than one stream, one for the aggregate that originally fired the event and one for the saga that is listening for the event. Please see this two part article for more info:

http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-i-of-ii/

[Jordan Neuhart]

When are you saving the checkpoint reached events to the process manager? Is it after you successfully send each command? If so, are you immediately persisting the process manager's state again after you add each checkpoint reached event? Or does your sending mechanism just append the events directly to the process manager's stream?

[João Bragança]

The checkpoint is the only state I'm interested in. Yes, right after each command or batch of commands. With the latter you of course need to make sure its idempotent.