-
-
Notifications
You must be signed in to change notification settings - Fork 370
Rebus configuration section
Several Rebus options can be configured in XML, which can make your application much more flexible with regards to allowing build scripts and whatnot to transform and adapt configurations to multiple environments. Here is an example app.config/web.config - first the configuration section declaration at the top:
<configSections>
<section name="rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" />
</configSections>
and then, some place further down in the file -
<rebus inputQueue="myService.input" errorQueue="error@anotherMachine" workers="10" maxRetries="5">
<endpoints>
<add messages="AnotherService.Messages" endpoint="anotherService.input@yetAnotherMachine" />
</endpoints>
</rebus>
In this example, the endpoint is configured to receive messages from the queue myService.input, which will be automatically created when the bus starts up. The endpoint is configured to tolerate maxRetries="5" message delivery failures, until the message will be moved to the error queue error on the machine with hostname anotherMachine.
The endpoint will start 10 workers when it starts up, which means that at most 10 messages can be processed in parallel.
And then, when the bus does a bus.Send or a bus.Subscribe with a message type from the AnotherService.Messages assembly, the message (or, when subscribing: the subscription request) will be routed to anotherService.input on host yetAnotherMachine.
Please note that, for inputQueue and errorQueue attributes to have effect, you need to configure the transport in one of the (...)AndGetInputQueueNameFromAppConfig(...) variants - e.g.
Configure.With(....)
.Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
.(...)
and for the <endpoints> element to have effect, you need to configure Rebus to route messages based on the Rebus configuration section, like so:
Configure.With(....)
.MessageOwnership(t => t.FromRebusConfigurationSection())
.(...)
When Rebus is configured to encrypt message bodies, each endpoint needs to be configured with an encryption key, a shared secret - that can be done by adding the <rijndael> element to the configuration section - here's an example on how that can be done:
<rebus inputQueue="someInputQueue" errorQueue="error" workers="1" maxRetries="5">
<rijndael key="oA/ZUnFsR9w1qEatOByBSXc4woCuTxmR99tAuQ56Qko="/>
<endpoints>
<!-- (...) -->
</endpoints>
</rebus>
where the key is a BASE64-encoded encryption key. For this to run, you need to configure the endpoint to use encryption like so:
Configure.With(....)
.Decorators(t => t.EncryptMessageBodies())
.(...)
If you want help generating the BASE64-encoded encryption key, just run the endpoint once without the element in the XML, then a random key will be generated for you.
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