Sending messages

Component: NServiceBus
Standard support for version 5.x of NServiceBus has expired. For more information see our Support Policy.

NServiceBus supports sending different types of messages (see Messages, Events, and Commands) to any endpoint. Messages can be sent either directly from the endpoint or as part of handling an incoming message. When a message arrives at an endpoint, it goes through a pipeline of processing steps.

Outside a message handler

In some cases, messages that need to be sent may not be related to an incoming message. Some examples are:

  • Sending a command when an HTML form is submitted in an ASP.NET application.
  • Publishing an event when the user clicks a button on a GUI application (see Publish and Handle an Event).

To send a message directly from the endpoint:

var bus = Bus.Create(busConfiguration).Start();

var myMessage = new MyMessage();

Unit testing the process of sending a message is supported by the NServiceBus.Testing library.

Inside the incoming message processing pipeline

Messages often must be sent as part of handling an incoming message. When running in a transaction mode that supports it, these send operations take part in the same transaction as that of the message handler, thereby ensuring that the send operation rolls back if the handling of the message fails at any stage of the message processing pipeline.

To send a message from inside a message handler:

public class MyMessageHandler :
    IBus bus;

    public MyMessageHandler(IBus bus)
        this.bus = bus;

    public void Handle(MyMessage message)
        var otherMessage = new OtherMessage();

Overriding the default routing

The default routing for a message can be overridden by specifying a different destination address:

bus.Send(Address.Parse("MyDestination"), new MyMessage());

Sending to self

Sending a message to the same endpoint, i.e. sending to self, can be done by sending a message to any of its own instances:

var myMessage = new MyMessage();

Dispatching a message immediately

While it's usually best to let NServiceBus handle all exceptions, there are some scenarios where messages might need to be sent regardless of whether the message handler succeeds or not, for example, to send a reply notifying that there was a problem with processing the message.

Side effects can occur when failures happen after sending the message. The messages could be retried meaning duplicate messages are created if this code is executed more than once. When messages are sent via immediate disaptch, ensure that the same message identifier gets assigned to them when invoked more than once. Second, due to failures it could happen that messages are sent that contain state which is inconsistent because of failing operations like a storage modification that didn't occur.

This can be done by suppressing the ambient transaction:

using (new TransactionScope(TransactionScopeOption.Suppress))
    var myMessage = new MyMessage();
Suppressing transaction scopes works only for the MSMQ and SQL transports in DTC mode. Other transports, or disabling DTC, may result in unexpected behavior.

Related Articles

Last modified