// Notes
Stop scripting RabbitMQ inside Ignition.
· 6 min read · Ignition
Plenty of Ignition sites already have a message broker in the building, usually RabbitMQ,
carrying events between services that are not SCADA. Getting Ignition onto that bus normally
means a scripted client parked in system.util.getGlobals(): no reconnect story,
no Designer visibility, and nobody owns it when it stops.
Ignition AMQP
makes the broker a configured connection like any other. Named connections under
Config → Connections, tested at save time, credentials in secret providers,
Event Stream source and handler when you want Designer wiring, and system.amqp.*
when you want scripts.
One connection, many streams
A broker connection is a pipe. Transport only. What a message means belongs to the Event Stream that uses the connection, so you create one stream per message you send or process rather than maintaining a central catalogue. Topology is exchanges, queues and bindings. MassTransit is a preset over that same model, not a parallel code path.
Acknowledgement mode, prefetch, publisher confirms and dead-letter handling are explicit settings. Failed publishes raise real Python exceptions instead of failing quietly.
AMQP, not MQTT
If your estate is already on a UNS over MQTT, stay there. This module is for plants that already run AMQP 0-9-1 / RabbitMQ and need Ignition on the same bus without a Jython client nobody wants to inherit.
The Event Stream module is optional: connections and scripting work without it; the source and handler light up when it is present. €1,600 per gateway, perpetual.
Put RabbitMQ beside a trial gateway. Manual and purchase form are on the product page.
AMQP module on Mustry