I'm working on a couple tasks related to historians and history queries, and have encountered some behaviors of remote tag providers (RTPs) that have me stymied: There's no public way to retrieve the gateway name that a RTP is pointing at, nor any public way to retrieve the far end's real tag prov…

My plan is to use reflection on the non-public fields for now, and agitate for a public API in v8.3. This is for a generic utility (coming to the Exchange soon) for which such work-arounds are not really appropriate.

[image] lrose: if not provided then it broadcast the message across the GAN Say what? sendRequest waits for a reply. What happens to all the other replies?

[image] pturmel: What happens to all the other replies Good question. I've never needed to try it with multiple remote servers having exactly the same message handlers. It is just how we have done it, so I thought it was worth mentioning. Nope, turns out, I'm wrong. When I tested this, th…

So, could you use that message handler though with the remoteServer to trigger a messageHandler on the remote server to collect all necessary local data and send it back to the requesting server? Somewhat of a handshake, but ServerA sends a message to ServerB with it's own name, and some payload of…

One of the items needed in a script is the backend gateway name associated with a particular RTP on the frontend side. I don't see how any possible messaging will get that for you. (You would already have that gateway name if you could send a message to it.)

Don't you somehow need to establish 2-way communications in the first place when setting up the GAN, so you would have to be on the remote server when setting it up and just document it at that time? Then once you get that 2-way comms going with message handlers, could automate collecting the data y…

[image] michael.flagler: just document it at that time That's precisely what I'm trying to avoid. Having to document something that the system already knows, for use in other scripts. Which risks documentation getting out of sync and the scripts making errors.

Yeah, I get that part. I thought your end goal in all of this was bypassing the remote history provider and if you would just need to "document" a list/dataset of servers then if you could set up messaging between them to dynamically pull the rest of the info you need so that if anything is changed …

As noted in my OP, the two key pieces of information are Remote gateway name. Real tag provider name in that gateway. An RTP has both of these in its non-public fields. I can't find any public way to grab those two pieces. A third key piece of information, not otherwise automatically available,…