@Kevin.Herron @PGriffith
Is it possible to restart gateway network connections via script?
I.e. press this button:
I want to give operators access to this from clients while we’re still trying to resolve performance issues so that I don’t have to take lots of calls in the early hours of the morning to press this button myself
Mmm, not easily. It’s a private method on the GatewayNetworkManager you get from GatewayContext::getGatewayAreaNetworkManager and it takes the record ID as a parameter, not the name of the connection.
I’m almost there, I just don’t know how to get the id. On the available connections collection items I’ve tried getting getId, getLocalUUID and some others. The restart connection method is looking for an id of type Java.lang.Long 
any clues?
I’m pretty sure it’s the ID of the row in the internal database, if that helps.
Yep!
I may have had a bit more help with this one 
Thanks all!
from com.inductiveautomation.ignition.gateway import IgnitionGateway
from com.inductiveautomation.ignition.gateway.gan import WSConnectionSettings
from simpleorm.dataset import SQuery,SQueryMode
# Parameters
target_host = "outgoing-connection-hostname"
target_port = 8060
# Obtain PersistenceInterface
gateway = IgnitionGateway.get()
pi = gateway.getPersistenceInterface()
gan_manager = gateway.getGatewayAreaNetworkManager()
# Setup a query
query = SQuery(WSConnectionSettings.META, SQueryMode.SREAD_ONLY)
query = query.eq(WSConnectionSettings.Host, target_host)
query = query.eq(WSConnectionSettings.Port, target_port)
# Issue query
record = pi.queryOne(query)
if record is not None:
record_id = record.getId()
gan_manager.restartConnection(record_id)
When I try to implement this code I get the following errors for line 1 and 2: “ImportError: No module named gateway”
And for line 3 : “ImportError: No module named simpleorm”
What could I be doing wrong?
Also, would this work for either outgoing or incoming connections?
Thanks for any help, I’m looking for exactly this function!
Gateway scope only. Won’t work in the script console, which is Designer scope (a variant of Vision Client scope).
I'm curious as to how someone becomes aware of and finds info on com.inductiveautomation.ignition.gateway.IgnitionGateway?
IgnitionGateway is not listed as a package, module or member of com.inductiveautomation.ignition.gateway in the Ignition javadocs.
IgnitionGateway is an internal "implementation" class. You aren't supposed to program against it.
The proper way to do something like this is to write a module, where you will be delivered a (documented) GatewayContext object in your setup hook and can use that to get access to the (supported from module development) managers that represent various subsystems.
None of what Nick wrote is supported from scripting. Your resource for discovery is these forums.
Sneak edit: Scooped ya, Phil
I saw you were typing. I just wasn't fast enough. 
@PGriffith, so is there is no "proper" way to get a GatewayContext object for gateway scripting, outside of developing a module?
The use case I was looking into was finding a way to list all configured gateway network connections and their status since that does not seem to be available through the system functions. I managed to pull some detail by making a revised version of @nminchin's script above using trial-and-error and guesswork (see below)... but it would be great to have better documentation on the attributes for each object used (particularly for class com.inductiveautomation.metro.impl.ConnectionWatcher), or a supported/approved way to get at the same detail.
BTW, I am aware of the very limited status info available in the system tags at [System]Gateway/Gateway Network.
from com.inductiveautomation.ignition.gateway import IgnitionGateway
gateway = IgnitionGateway.get()
pi = gateway.getPersistenceInterface()
gan_manager = gateway.getGatewayAreaNetworkManager()
gan_connections = gan_manager.getAvailableConnections()
gan_connections_info = []
for connection in gan_connections:
gan_connections_info.append({
"certificateChain" : connection.certificateChain
,"class" : connection.class
,"currentIncomingMessages" : connection.currentIncomingMessages
,"currentOutgoingMessages" : connection.currentOutgoingMessages
,"direction" : connection.direction
,"id" : connection.id
,"inboundConnection" : connection.inboundConnection
,"incomingOneMinRate" : connection.incomingOneMinRate
,"lastCommTime" : connection.lastCommTime
,"lastError" : connection.lastError
,"localUUID" : connection.localUUID
,"outgoingDescription" : connection.outgoingDescription
,"outgoingOneMinRate" : connection.outgoingOneMinRate
,"pingTime" : connection.pingTime
,"remoteId" : connection.remoteId
,"remoteNetworkAddress" : connection.remoteNetworkAddress
,"remoteServerAddress" : connection.remoteServerAddress
,"routedServers" : connection.routedServers
,"sessionId" : connection.sessionId
,"state" : connection.state
,"status" : connection.status
,"toString" : connection.toString()
})
return {
"gan_connection_info": gan_connections_info
# ,"gan_manager_attributes" : ( type(gan_manager), dir(gan_manager) )
# ,"gan_connection_attributes" : ( type(connection ), dir(connection ) )
# ,"ignitionGateway_attributes": ( type(gateway) , dir(gateway ) )
# ,"ignitionGatewayPersistentInterface_attributes": ( type(pi), dir(pi) )
}
No, because IA doesn't promise to keep SDK APIs backwards compatible, and implementation details do change from time to time. Module authors are expected to suck it up deal with it.
However, there are publicly available free modules that expose a gateway/designer/vision context, like my Integration Toolkit module and Paul's open source Ignition Extensions.
Just know that anything you do in jython with a context object is subject to breakage on Ignition upgrades, and IA support will ignore your whining about it.
For a concrete example:
For basically all of Ignition's lifetime, we've been using SimpleORM and an internal database, though the 'flavor' of that internal DB has changed from HSQLDB to SQLite. We also take great pains to make supported operations continue to work even when you upgrade Ignition.
So if the things you're doing in that script were supported, but we ditched SimpleORM (as we are in 8.3.0, when gateway config is moving to the filesystem), we would have to spend even more engineering effort adapting all of the scripting you had in place to "bridge" all the calls to whatever new system we come up with. Now expand that example to literally everything else in the gateway, designer, and client, across every version, across the entire history of Ignition.
We have to have some line in the sand as far as guaranteed support; what we've come up with is allowing access to these internal details (we don't make any effort to prevent you from doing things like you and Nick are doing here), but also not making it easier - because the "right" thing to do is for us to make a better first-party API that is supported (and maintained) that solves the problem(s) you might have. For everything we can't/won't/haven't done first party, you've got the forums.
So the "right" solution would be an ideas post or a support ticket that describes your problem, and we'll collate that together with everyone else's feedback and decide on a future path for the product forward.
@PGriffith and @pturmel, thanks for taking the time to provide detailed responses and improve my understanding.