Integrates NServiceBus with IBM MQ using the IBM MQ .NET client.
Broker version compatibility
The transport requires IBM MQ 9.0 or later. IBM guarantees that any supported MQ client can connect to any supported queue manager, regardless of version.
The transport ships the IBM-provided managed .NET client (IBMMQDotnetClient) and tracks the latest Continuous Delivery (CD) or Cumulative Security Update (CSU) release rather than pinning to a Long Term Support (LTS) fix pack. The managed client is wire-compatible with LTS queue managers, so customers on an LTS queue manager receive the newest client-side fixes through transport upgrades without needing to change their queue manager.
IBM MQ does not follow SemVer; it uses a four-segment V. scheme with parallel LTS and CD streams. See the IBM MQ versioning FAQ for the full scheme and the IBM product lifecycle page for supported-version dates.
Transport at a glance
| Feature | |
|---|---|
| Transactions | None, ReceiveOnly, SendsAtomicWithReceive |
| Pub/Sub | Native |
| Timeouts | Not natively supported |
| Large message bodies | Determined by queue manager MAXMSGL setting |
| Scale-out | Competing consumer |
| Scripted Deployment | Supported via CLI tool |
| Installers | Optional |
| Native integration | Supported |
| OpenTelemetry tracing | Supported |
| Case Sensitive | Yes |
TransactionScope mode (distributed transactions) | No |
| SSL/TLS encryption and certificate-based authentication | Yes |
| Queue and topic names | Limited to 48 characters |
| Delayed delivery | No. Requires an external timeout storage mechanism. |
| Native message grouping | Not yet implemented |
Configuring the endpoint
To use IBM MQ as the underlying transport:
var endpointConfiguration = new EndpointConfiguration("MyEndpoint");
var transport = new IBMMQTransport
{
Host = "mq-server.example.com",
Port = 1414,
Channel = "DEV.APP.SVRCONN",
QueueManagerName = "QM1",
User = "app",
Password = "passw0rd"
};
endpointConfiguration.UseTransport(transport);
See connection settings for all available connection and configuration options.
Message persistence
By default, all messages are sent as persistent, meaning they survive queue manager restarts. Messages marked as non-durable are sent as non-persistent for higher throughput.
Non-persistent messages are lost if the queue manager restarts before they are consumed.