What is the best way to handle those situations ? Are global query possible using nHaystack on the Web Supervisor ?
Mike JarmyThu 10 Jul 2014
It is possible to do global queries yes, but perhaps not in the way you are thinking.
The most common use case with NHaystack is that there is some remote machine that is not an AX station, that is issuing the requests, and the AX stations in the system are responding. Often times the remote machine will be a commerical product like FinStack (a soon-to-be-released product from J2) . We need a name for this machine, so I'll call it the remote client. It is the remote client that you would do global queries from, not the supervisor.
The remote client will want to either fetch histories from an AX system, or monitor/control points in an AX system, or both.
The simplest set up is a case where you just want to fetch histories from a bunch of jaces, those jaces are actually collecting the histories, and you can reach all of the jaces over the network from the remote client (i.e. there are no firewall issues). In that case, all you need to do is connect directly to each jace from the remote client -- there is no need to involve the supervisor at all. Its usually a lot easier to just bypass the supervisor if you can.
In this relatively simple scenario, your global query is issued from the remote client, which queries each of the jaces in turn, and collates the results for you.
If you want to subscribe to points directly on the jaces, either to monitor them, or control them via the remote client's control engine, the same approach will still work.
Things start to get more complicated when the jaces aren't collecting the histories you want, or they are only collecting some of the histories, or the web supervisor has the histories but the points aren't imported, or you can't reach the jaces because of a firewall but you can reach the supervisor, etc etc.
There is a way to make nhaystack do your bidding for all of these various scenarios, but of course the exact approach you end up taking is site-specific.
A common scenario is that the jaces aren't collecting the histories you want, and you have to reach the jaces indirectly via the web supervisor because of a firewall. In that case what you would do is make sure all the points you care about are imported into the supervisor. Then, from the remote client, you would subscribe to those points on the web supervisor, and start recieving COV changes. You could log those COV changes into the remote client's database, and start creating a history that way.
You could use the same approach to command the points indirectly, by commanding the subscribed points from the remote client, which would command them on the supervisor, which would command the supervisor's imported points via Fox, which would then cause the jace to command its points on its field bus, over say BacNET.
So that was a really long winded answer to your question :-). It is always possible to incorporate an AX System into a remote client's system using NHaystack. The specifics of how you actually get to that point can vary a lot though, depending on a lot of different site-specific factors.
Christian Tremblay Wed 9 Jul 2014
What is the best way to handle those situations ? Are global query possible using nHaystack on the Web Supervisor ?
Mike Jarmy Thu 10 Jul 2014
It is possible to do global queries yes, but perhaps not in the way you are thinking.
The most common use case with NHaystack is that there is some remote machine that is not an AX station, that is issuing the requests, and the AX stations in the system are responding. Often times the remote machine will be a commerical product like FinStack (a soon-to-be-released product from J2) . We need a name for this machine, so I'll call it the remote client. It is the remote client that you would do global queries from, not the supervisor.
The remote client will want to either fetch histories from an AX system, or monitor/control points in an AX system, or both.
The simplest set up is a case where you just want to fetch histories from a bunch of jaces, those jaces are actually collecting the histories, and you can reach all of the jaces over the network from the remote client (i.e. there are no firewall issues). In that case, all you need to do is connect directly to each jace from the remote client -- there is no need to involve the supervisor at all. Its usually a lot easier to just bypass the supervisor if you can.
In this relatively simple scenario, your global query is issued from the remote client, which queries each of the jaces in turn, and collates the results for you.
If you want to subscribe to points directly on the jaces, either to monitor them, or control them via the remote client's control engine, the same approach will still work.
Things start to get more complicated when the jaces aren't collecting the histories you want, or they are only collecting some of the histories, or the web supervisor has the histories but the points aren't imported, or you can't reach the jaces because of a firewall but you can reach the supervisor, etc etc.
There is a way to make nhaystack do your bidding for all of these various scenarios, but of course the exact approach you end up taking is site-specific.
A common scenario is that the jaces aren't collecting the histories you want, and you have to reach the jaces indirectly via the web supervisor because of a firewall. In that case what you would do is make sure all the points you care about are imported into the supervisor. Then, from the remote client, you would subscribe to those points on the web supervisor, and start recieving COV changes. You could log those COV changes into the remote client's database, and start creating a history that way.
You could use the same approach to command the points indirectly, by commanding the subscribed points from the remote client, which would command them on the supervisor, which would command the supervisor's imported points via Fox, which would then cause the jace to command its points on its field bus, over say BacNET.
So that was a really long winded answer to your question :-). It is always possible to incorporate an AX System into a remote client's system using NHaystack. The specifics of how you actually get to that point can vary a lot though, depending on a lot of different site-specific factors.