Full Application Configuration File

This configuration is the default application configuration file based version. Some components that you may replace could very well have their own configuration stores.

To start off add the Shuttle.Esb.ServiceBusSection configuration class from the Shuttle.Esb assembly.

<configuration>
  <configSections>
    <section name='serviceBus' type="Shuttle.Esb.ServiceBusSection, Shuttle.Esb"/>
  </configSections>

It is also possible to group the Shuttle configuration in a shuttle group:

<configuration>
	<configSections>
		<sectionGroup name="shuttle">
			<section name='serviceBus' type="Shuttle.Esb.ServiceBusSection, Shuttle.Esb"/>
		</sectionGroup>
	</configSections>

The most pertinent bit is the serviceBus tag.

  <serviceBus
    cacheIdentity="true"  
    createQueues="true"  
    removeMessagesNotHandled="false"
    compressionAlgorithm=""
    encryptionAlgorithm="">

The IIdentityProvider implementation is responsible for honouring the cacheIdentity attribute.

Use the queueFactories tag to configure how you would like to locate queue factories. By default the current AppDomain is scanned for implementations of IQueueFactory along with all assemblies in the base directory (recursively). These queue factories have to have a parameterless constructor in order to be instantiated.

	<queueFactories scan="true|false">
		<add type="Shuttle.Esb.Msmq.MsmqQueueFactory, Shuttle.Esb.Msmq" />
		<add type="Shuttle.Esb.RabbitMQ.RabbitMQQueueFactory, Shuttle.Esb.RabbitMQ" />
		<add type="Shuttle.Esb.SqlServer.SqlQueueFactory, Shuttle.Esb.SqlServer" />
	</queueFactories>

The messageRoutes tag defines the routing for message that are sent using the IServiceBus.Send method. You will notice that the structure is the same as the forwardingRoutes tag.

    <messageRoutes>
      <messageRoute uri="msmq://./inbox">
        <add specification="StartsWith" value="Shuttle.Messages1" />
        <add specification="StartsWith" value="Shuttle.Messages2" />
      </messageRoute>
      <messageRoute uri="sql://./inbox">
        <add specification="TypeList" value="DoSomethingCommand" />
      </messageRoute>
    </messageRoutes>

The inbox should be specified if the endpoint has message handlers that need to process incoming messages.

    <inbox
      workQueueUri="msmq://./inbox-work"
      deferredQueueUri="msmq://./inbox-work-deferred"
      errorQueueUri="msmq://./shuttle-error"
      threadCount="25"
      durationToSleepWhenIdle="250ms,10s,30s"
      durationToIgnoreOnFailure="30m,1h"
      maximumFailureCount="25" 
      distribute="true|false" 
      distributeSendCount="5" />

For some queueing technologies the outbox may not be required. Msmq, for instance, create its own outgoing queues. However, it should be used in scenarios where you need a store-and-forward mechanism for sending messages when the underlying infrastructure does not provide this such as with a SqlServer table-based queue or maybe even the file system. RabbitMQ will also need an outbox since the destination broker may not be available and it does not have the concept of outgoing queues.

    <outbox
      workQueueUri="msmq://./outbox-work"
      errorQueueUri="msmq://./shuttle-error"
      durationToSleepWhenIdle="250ms,10s,30s"
      durationToIgnoreOnFailure="30m,1h"
      maximumFailureCount="25"
      threadCount="5" />

You can also set the transaction scope behaviour by providing the transactionScope tag. If you want your endpoint to be non-transactional then set the enabled attribute to false. This will improve performance but messsage delivery and processing cannot be guaranteed. If the underlying queueing infrastrcuture does not support 2-phase commit message delivery and processing also cannot be guaranteed.

    <transactionScope
      enabled="true"
      isolationLevel="ReadCommitted"
      timeoutSeconds="30" />

When the endpoint is not a physical endpoint but rather a worker use the worker tag to specify the relevant configuration.

    <worker
      distributorControlWorkQueueUri="msmq://./control-inbox-work"
      threadAvailableNotificationIntervalSeconds="5" />

Since a worker sends thread availability to the physical distribution master the distributor needs to have a special inbox called the control inbox that is used for these notifications.

    <control
      workQueueUri="control-inbox-work"
      errorQueueUri="msmq://./shuttle-error"
      threadCount="25"
      durationToSleepWhenIdle="250ms,10s,30s"
      durationToIgnoreOnFailure="30m,1h"
      maximumFailureCount="25" />

Use the modules tag to configure modules that can be loaded at runtime. These modules have to have a parameterless constructor in order to be instantiated; else add them programmatically if you need to specify parameters.

	<modules>
		<add type="Shuttle.Esb.Modules.ActiveTimeRangeModule, Shuttle.Esb.Modules" />
	</modules>

If you need to make use of the DefaultUriResolver you can specify the mappings as follows:

	<uriResolver>
		<add name="resolver://host/queue-1" uri="msmq://./inbox-work-queue" />
		<add name="resolver://host/queue-2" uri="rabbitmq://user:password@the-server/inbox-work-queue" />
	</uriResolver>

Finally just close the relevant tags.

  </serviceBus>
</configuration>