Hi! Due to my company's use case, I developed a simple scripting module to be able to consume messages from designated queues. Once started, it will act like a service and continously consume messages in the background and write the values to a tag. The only way to stop the consumption is to restart your gateway or to call the shutdown function in the project where the instance was first initiated. This is the first project I've really done, so any ideas for additional features or any feedback is greatly appreciated! Thank you!
Nice work!
I know nothing about RabbitMQ, but I'd generally think a more familiar paradigm for Ignition users would be a project resource where you define an extension function to run whenever incoming messages are received that allows you to process them and do whatever you want, no flattening to the tag system needed.
This is also going to dovetail very nicely with our upcoming event streams feature in 8.3.0 - you could have your module act as a publisher of events and get all the nicer script handling from event streams for "free".
Thanks for the feedback, Paul! Our initial use case for the module was to use scripting to assign incoming messages (whether a JSON formatted string or a numbe) to tags. From there, we could easily bind the tag's value to a property and apply a transform if needed. Over time, we’re aiming to expand its functionality to create a more comprehensive RabbitMQ solution.
I’m really intrigued by your mention of developing an "extension function" as a more intuitive approach for Ignition users to interact with a message broker. As a relatively new developer, I'd love to understand how you'd go about designing such a function. Any guidance or resources you could point me to would be greatly appreciated!
For extension functions, basically just look to what most scripting is in Ignition - some event happened (on the client/gateway/session) - and now we're giving the end user some opportunity to run a script in response.
Anywhere you see this editor:
You're dealing with an extension function.
I don't think we have any complete end-to-end examples of all the required bits of this publicly, unfortunately. Doing this all from scratch would be a significant undertaking - you'd have to explore the project resource system in the Designer (see this example I made) as well as provide a ProjectLifecycleFactory
on the gateway to handle the actual execution of events - using ScriptManager.compileFunction
to "compile" the user authored script into a repeatably callable Java function.
As mentioned - event streams will make this all a lot easier for you, because you'll be able to just register yourself with ES as a "source" of events, and all the project resource and Jython related scaffolding will be handled for you within event streams.
The big advantage for the end user is flexibility. They're free to handle (or ignore) incoming messages, do whatever other actions they want, in a single spot - rather than going through tags indirectly.