sam.donche@edge Sam Donche
← notes

// 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

← all notes