Automatonymous | A state machine library for .Net - 100 % code - No doodleware | Machine Learning library

Automatonymous is (well, was, but still is) a standalone project. But it has seen limited adoption outside of MassTransit for the reasons you state: instance management, loading and saving instances, identity, etc.

Which is why with v8 of MassTransit, the Automatonymous codebase has been fully integrated to provide a seamless developer experience. Concerns such as instance/state management are handled by the saga repository, which is message-based. I haven't thought about providing any other affordances to dispatch events to state machines outside of the saga repository at this point.

You need to use the Serilog.Extensions.Logging NuGet package, which adds ILoggerFactory support to Serilog. You can pass that interface to configure MassTransit via:

There is support, you just have to configure it:

In general, making these types of requests (such as HTTP) is not recommended. Sagas execute within the context of a database transaction, and for that reason adding an external dependency, such as a slow or perhaps unavailable HTTP resource can cause the concurrency throughput to drop significantly if sagas are blocked waiting on external systems.

It might be better to have a separate consumer responsible for querying the remote system, and send/publish a command from the saga which the consumer would use to retrieve the data and report it back to the saga (either via a response, or an event observed by the saga).

The concurrency mode doesn't matter. For instance, if the saga is waiting on an HTTP request, and optimistic concurrency is used, if another event updates the saga while the current event is waiting on an HTTP response, when the saga tries to persist it would fail due to a concurrency/version conflict as it was updated by the other event.

So, when it comes to sagas, short and sweet should be the goal, delegating all the heavy lifting to other components. Sagas should orchestration work, and not do too much work themselves.

When a routing slip is executing, MassTransit will publish events for each routing slip activity as well as an event once the routing slip has completed.

You can use those events, rather than creating your own, to monitor the routing slip from start to finish (all events are correlated by TrackingNumber).

If you have multiple routing slips in your system for different transactions, you can specify subscriptions to route those events directly to the tracking saga for each transaction, instead of publishing, so they don't overlap into separate tracking sagas.

These events are best used for monitoring/tracking routing slip execution, and should not be used in place of business events. For instance, if your activity charges a credit card, it would make sense to publish a "CreditCardCharged" event with the details for auditing/tracking the card transaction separately for accounting/legal purposes.

In your code example, you aren't adding the saga, or configuring the saga on a receive endpoint. The consumer is a separate thing, and completely unrelated to the saga. You should be calling:

AddSagaStateMachine()

And then either using ConfigureSaga or switching to ConfigureEndpoints for the endpoint to be configured automatically.

Consumer sagas, for lack of a better name, are the original sagas implemented by MassTransit when it was created 13 years ago. They were consumers with state and used variants of IConsumer to direct messages to saga instances. Consumer sagas implement one or more interfaces to consume correlated saga events. This support is included so that it is easy to move applications from other saga implementations to MassTransit.

State Machine Sagas, which use Automatonymous, provide a powerful state machine syntax to create sagas. They are more flexible in terms of event correlation, and have a fluent syntax for defining state and behavior. They also work nicely with dependency injection via the creation of custom activities which are resolved at run-time for each message.

Automatonymous was written separately to enable its use out of MassTransit, but it by the same author (me).

If you are observing events delivered to the state machine prior to the Initially event completing, you should add UseInMemoryOutbox to the receive endpoint (before the state machine configuration). This will defer outbound messages until the state machine instance is persisted. My suspicion is that you are using an optimistic locking strategy, and the second event is arriving prior to the initial event persistence completing.

So below are the changes i did to ensure the statemachine works as expected. The changes were done based on @Chris suggestion in comments, even though our initial implementation of the statemachine was based on the docs on sqlserver efcore persistence.