Before we get straight to the propagation of Nodes or Sources, you need to configure your station. We will take a classic/basic example of a supervisor and two JACEs communicating in both ways.

Station Role concept

You may have a complex architecture made of different layers for your Niagara station. We will take for the rest of this tutorial a basic architecture made of a supervisor and two Jaces. Principles will remain the same, you will be able to adapt them to your existing architecture.

Niagara defines the concept of relation (station role) between two stations. A station has necessarily one of the following relations with another station:

  • Peer
  • Subordinate
  • Supervisor

In the following illustration, the server is the SUPERVISOR of both JACEs (so JACEs are SUBORDINATES of the Sup) and the JACEs are considered as PEERS among them.

Knowing relations between your stations is very important for the model propagation: you can only propagate between stations with a SUPERVISOR /SUBORDINATE relation.


Station connection

Before configuring anything, we must connect the Niagara stations among them.

In the Niagara network, Using the Station Manager, you can discover your stations and add them, all the informations except the credentials will be set. Otherwise, you can manually add them using the "New" Button.
To check if the station has been correctly configured, Trigger the "Ping" action and check the station Health, it should display OK.

You need to parameter the Niagara Network only for the stations you need to use to exchange data. For example: it may be useless to configure the Niagara Network between the two JACEs if it's only an exchange between the supervisor and the JACEs.

The stations must remain connected during the whole propagation process.

Depending on the number of propagated elements, the batch size or the hardware, the propagation can take some time. A solution to keep the connection alive is to set a lower ping frequency value in the NIagara Network's Monitor.

Example


  • Any error will be displayed in the Health Column, correct the displayed error till the Health Column displays Ok (as in the previous screenshot).
  • Make sure that you can Ping the target station from the source station AND VICE VERSA.


Troubleshooting

  • If the Manager displays a "Fail" concerning an SSL Exception in the Health column, go to Platform/CertificateManager and in the Allowed Hosts tab, approve your hosts.
  • Make sure the port and the property useFoxs are compatible.
  • Once you successfully connected a Niagara Station, a peer station will be created automatically on the target station in the Niagara Network. But it will be uncompleted, missing username and password for example. Make sure to finish the configuration of it.


Station Role configuration

Now that you can ping the stations between each other, you have to parameter their respective role. To do that, Niagara provides the Role Manager located in the Sys Def of the Niagara Station (see screenshot below).

You have to set the Desired Role. You may find it a bit confusing at this point: Who is subordinate to whom?

→ It's the role of the Niagara station in the Niagara network (the remote one) with the current station.


Wait for the LastSuccess slot to update before continuing. Status should be ok.

Example

The examples in this page will show you how to configure a source station (in our case the Supervisor) to propagate a Node to a target station (in our case Jace1)


Currently we are in the Supervisor station. Here, we can see the Sys Def of Jace1. It's role is set to SUBORDINATE. The relation goes from the station in the Niagara Network to the current station, meaning that Jace1 is the SUBORDINATE with respect to the Supervisor.

Although a wrong synchronization shouldn't happen, make sure that the role in one station is correctly mirrored in the other station. Example: Here Jace1's role with respect to the Supervisor is SUBORDINATE so Supervisor's role with respect to Jace1 should be SUPERVISOR.

Request time out

The propagations are done through requests. The source station sends a request to the target station and waits for an answer before processing the following propagation request.
Depending of the hardware on the target station and/or the propagation request complexity, the default request time out (1min) might not be enough. If you have time out errors, increase the "Request Time Out" value in the source station's FoxService.