[00:00] In this video,  we will explain what the store and forward mechanism supported by Links between nodes is, and how it works. This is a feature that enables users to guarantee that there will be no loss of data in the event of a communication failure between nodes. Should the receiving node is no longer accessible to the transmitting node, that is collecting and sending data, the Store & Forward mechanism will automatically store any event locally on the transmitting nodes disk. Once communication has been restored, all stored data is sent to the receiving node, starting with the oldest data first. Next, we will explain how to configure Store & Forward. First of all, we will go ahead and access the Links configuration for the remote node, which can be found in the Explorer Panel, and then, in the publish section within the Outbound connections, we should make sure that store and forward has been enabled.

[01:00] Buffer size defines the maximum number of events contained in each of the files that are stored on the disk, while Buffer Save Rate specifies the maximum time elapsed before saving the file. The first condition that is met, in terms of what has been configured in these two fields, will determine when to save a new file to the disk. Finally, it’s also possible to define the maximum lifespan of all files saved to the disk, so that once this time has elapsed, the oldest files will automatically be deleted. For this example, it is not necessary to make any modifications here, so the default values will be valid. Next, let’s take a look at how the Store & Forward mechanism works. To do this, we have previously configured a pair of nodes that are connected via Link, in which we are simultaneously historizing some variables in both, a local and a remote Historian instance. These tags are also being published to the central node by the remote node. The Store & Forward feature does not require data to be Historized, but we will use it here anyway, because it will allow us to demonstrate how the mechanism actually works in a nice visual way.

[02:00] Let’s look specifically at a tag with write permissions. If we now go ahead and change its value in the remote node and then move to the real-time section of the central node, we can check that the tag is being correctly published via the Link. We’ll now make several successive changes to the value of the tag on the remote node and verify that these changes are being correctly stored in the historian instances in both nodes. In fact, we will be able to see that the graphs in both nodes are exactly the same. For greater clarity, let’s toggle to table mode, where we can see the values with their corresponding timestamp.

[03:00] Next, we’re going to simulate a loss of connection between nodes. To do so, we will change the port of the Link on the remote node to 3002 and save the settings. Let’s now check in the Links section, located in Diagnosis, that the link has indeed been broken. Now, we’re going to make some further modifications to this variable. If we compare the data tables collected by the Historian modules in both nodes, we will see that in the remote node, data is still being stored while in the central node, it is not. We can observe exactly the same if we switch to chart mode.

[04:00] If we re-establish the connection by entering the correct port on the remote node and hit save, we can see how the remote node sends all the data it is stored whilst communication was down to the central node. Comparing the historical charts, we can confirm that Store & Forward is indeed worked correctly. As I mentioned earlier, in this example we have used Historian for clarity, but it’s important to emphasize that the Store & Forward mechanism is supported for virtually all data types, regardless of the source they come from.