I'm a little confused (not the first or last) about Gateway Scripts, Gateway projects, etc.
I had a bunch of projects that used client scripts to alarm query for ack/unack counts by displaypath. Trying to follow best practices, so I created a single gateway script that creates a list of display paths (obtained from administrative app), iterates through the list, and writes the two counts to each tag provider (matches display path) for use by individual projects.
It works fine, but I tested this in one particular project, and thusly wrote the gateway script from there, not realizing that gateway scripts are still project resources.
So, whats best practice? Move the script to my administrative project and declare that project as a gateway project? If i do that, does the project library at least appear in the folder under each project? I dont need the actual script to be called or executed in other projects, but from a documentation standpoint, its odd to me that the gateway script i created in one project isnt at least viewable from other projects. Goes back to it being a project resource I suppose.
Would it be better to not iterate through a list and have each project call its own alarmquery on the gateway, passing the tag path and display path to a common function? What I have is working, but wanted to make sure I'm not making it worse than what was built prior. But also, would like some marker in each project where that tag write is originating from.
All projects exist in the gateway. All leaf projects (that is, non-inheritable) can have project-specific gateway event scripts: startup, timer, tag change, message handler, shutdown, and scheduled. (Non-inheritable projects can also have them, but they won't run there, just where inherited--that way lies madness.)
Certain gateway objects, particularly tags, do not belong to any project, and do not naturally have access to library scripts. A single project, not necessarily a leaf project, can be specified as the "Gateway Scripting Project", making its scripts accessible from tag events (attached to the tag) and/or expression tags using runScript().
Consider using project inheritance to organize your project library:
Okay, thanks for the explanation. It mostly follows what I believed to be true. In this particular install, there didnt appear to be a large need for inheritable projects beyond navigation templates. The various projects are very disparate across an entire factory. The commonality is the alarm handling, and thats where I was trying to centralize, and get those nasty system alarm query functions out of the projects and clients. Especially since multiple clients running the same project didnt need to both query the unacked alarms for that display path.
Sounds like i just need to make my administrative project the gateway project for these type functions. But in this case is there any performance advantage from the gateway script writing a pair of tags to 12 tag providers, vs 12 projects calling the gateway function, and each writing their own tag?