-
-
Notifications
You must be signed in to change notification settings - Fork 364
Process managers
Configuring Rebus to persist sagas (in the literature known as process managers) in a database is fairly straightforward.
Generally, you will
- Include an appropriate persistence NuGet package
- Call an appropriate
.StoreIn(...)
extension method from that package
and then saga instances will be stored there in a way that allows for rich modeling in sagas, while still making as much sense for the given persistence technology as possible.
With Microsoft SQL Server you will probably
Install-Package Rebus.SqlServer -ProjectName <your-project>
and then do something like this when you configure Rebus:
Configure.With(...)
.(...)
.Sagas(s => s.StoreInSqlServer(connectionString, "Sagas", "SagaIndex"))
.Start();
By default, the SQL Server saga storage will go and ensure that the two tables specified in the configuration are created, so in this case the tables [dbo].[Sagas]
and [dbo].[SagaIndex]
will be created.
If you want to customize the used schema, you can do that as well – just specify the schema and table name explicitly, e.g. like [rebus].[Sagas]
in order to have the table created in the [rebus]
schema (which will automatically be created if it does not already exist).
With SQL Server, the saga data gets serialized as JSON into a single column, and then the configured correlation properties will be saved "on the side" in the configured index table, allowing an otherwise black-box (to SQL Server, at least) blob of JSON to be looked up by the value of some of its properties.
Basic stuff
- Home
- Introduction
- Getting started
- Different bus modes
- How does rebus compare to other .net service buses?
- 3rd party extensions
- Rebus versions
Configuration
Scenarios
Areas
- Logging
- Routing
- Serialization
- Pub sub messaging
- Process managers
- Message context
- Data bus
- Correlation ids
- Container adapters
- Automatic retries and error handling
- Message dispatch
- Thread safety and instance policies
- Timeouts
- Timeout manager
- Transactions
- Delivery guarantees
- Idempotence
- Unit of work
- Workers and parallelism
- Wire level format of messages
- Handler pipeline
- Polymorphic message dispatch
- Persistence ignorance
- Saga parallelism
- Transport message forwarding
- Testing
- Outbox
- Startup/shutdown
Transports (not a full list)
Customization
- Extensibility
- Auto flowing user context extensibility example
- Back off strategy
- Message compression and encryption
- Fail fast on certain exception types
Pipelines
- Log message pipelines
- Incoming messages pipeline
- Incoming step context
- Outgoing messages pipeline
- Outgoing step context
Prominent application services