Hello,
I am looking for the best practices in terms of running an API call from within a tag change event inside a UDT. I have a CMMS API call that that pulls in current work orders.
If possible I would like to be able to define how often each call happens inside the UDT's however I hadn't thought about managing concurrent calls.
From reading through some similar posts this is by default limited to 3 threads if called directly in the UDT.
Alternatively I think a gateway scoped script that looks for this specific UDT and calls each sequentially would work as well.
What is the best way to handle this type of thing?
Not just limited for the API. That is the limit for all concurrent tag events in the entire gateway (tag events meaning those defined on a tag, not in a project event). Under no circumstances should you ever make external calls from a tag event, nor wait or sleep in any fashion.
A gateway tag change event would be an appropriate solution, and would automatically singulate API calls for the tags in its list to monitor.
Consider using a tag event that simply puts the affected tagpath into a persistent ConcurrentLinkedQueue (or perhaps a BlockingQueue), and use a timer event to drain the queue, making the API calls from there.
(You will need to learn how to safely use system.util.getGlobals().. Non-trivial, unfortunately, but there are examples here on the forum.)
Thanks, yeah I am not familiar with the system.util.getGlobals()..
Sounds like it may be more straightforward to just crawl the tag tree looking for the specific UDT.
Do you mean at runtime, or just once at design time? If the former, don't. Really. If the latter, look at the tag report tool. It can make a list of tag paths for you to paste in to the gateway tag change event's monitoring list.
Runtime. Thinking about a UDT that is instantiated via MQTT topic from a machine. As equipment is brought online i would pull the work orders daily if they exist. Not talking tons of equipment either but it would skip a step of manually going into the system to set this up each time.
What would the reasons to not have this at runtime be?
Yeah makes sense. For each API call the UDT then parses it into individual tags as well so could add up.
New devices would come online rarely but for each new device I would scan daily for the work orders. I will check out he getGlobals() as well.
Runtime. Thinking about a UDT that is instantiated via MQTT topic from a machine. As equipment is brought online i would pull the work orders daily if they exist. Not talking tons of equipment either but it would skip a step of manually going into the system to set this up each time.