Bsft.Messaging.RabbitMQ 2.2.0

Bsft.Messaging.RabbitMQ

The RabbitMQ transport of the Bsft.Messaging family: both halves of the wire, the topology the adapter declares for itself on every start, publisher confirms on the way out and a dead-letter park on the way in.

Install

dotnet add package Bsft.Messaging.RabbitMQ

Requires Bsft.Messaging.Abstractions and RabbitMQ.Client, and no further Bsft packages — the adapter is written against the two transport contracts alone and knows nothing about the inbox, the type registry or a handler. A host that consumes also references Bsft.Messaging for the pipeline that reads the source.

Register

services.AddBsftRabbitMQMessaging(configuration, options => options.Subscribe("orders.placed.v1"));
services.AddBsftMessaging(configuration, options => options.AddEvent<OrderPlaced>("orders.placed.v1"));
services.AddBsftConsumerHost();

// or entirely in code, credentials included — which is what the configuration overload exists to avoid
services.AddBsftRabbitMQMessaging(options =>
{
    options.ApplicationName = "orders";
    options.UserName = "...";
    options.Password = "...";
    options.Subscribe("orders.placed.v1");
});

Call it before AddBsftMessaging. The messaging core registers its in-process bus and the loopback its source with TryAdd, so whichever ran first wins; calling this afterwards leaves the application silently delivering its integration events to itself. Every consumed event is declared twice on purpose: Subscribe binds the queue on the broker, AddEvent resolves the name in this process. This registers the transport and not the consuming pipeline — AddBsftConsumerHost adds the host that enumerates the source.

Configure

Subscribe(eventName) adds a binding of the queue to an event name; it is a method rather than a property because declaring the same name twice has to be ignored rather than doubled.

Validation: ValidateOnStart() resolves the connection settings and the topology and reports everything they refuse in one go — an absent application name, host, virtual host, content type, user or password; a port outside the TCP range; a prefetch of zero, which AMQP reads as an unlimited prefetch; a publish channel count below one; a non-positive confirm timeout, recovery interval, heartbeat or continuation timeout; a name that cannot be derived or exceeds the 255 characters AMQP allows; a dead-letter object that is the object it protects; a non-positive dead-letter bound; and an exchange type that does not route on the routing key.

Extend

None. Every seam this adapter has toward the framework is declared in Bsft.Messaging.Abstractions — it implements IMessageBus, IMessageSource and IMessageDelivery and consumes nothing else. Its own interfaces under Abstractions/ (IRabbitMQChannel, IRabbitMQConnection, IRabbitMQTopologyDeclarer, and the rest) are internal: they exist so the property mapping, the confirm handling, the topology declaration and the acknowledgement decisions are testable without a broker, not as a public extension point. A host that wants different behaviour replaces the whole adapter by registering its own IMessageBus and IMessageSource.

The two public types beside the options are RabbitMQQueueType, which is what QueueType is set from, and RabbitMQMessageFormatException, which reports a delivery that never became an envelope — parked immediately rather than retried, because the same bytes would be exactly as unreadable next time.

Documentation

Topic page: docs/messaging.md. Conventions: docs/package-conventions.md.