Configuring Store-and-Forward

Sometimes the historian server computer can become unavailable because of a scheduled maintenance or a network communication problem, but at the same time the SDK application might need to process some real-time device data without interruption of the data flow.

To address this scenario, the AVEVA Historian implements a store-and-forward mechanism, allowing the client application to transparently redirect the data flow to a locally running storage process. When the historian becomes available, that locally stored data is forwarded to the historian server.

To configure the store-and-forward mechanism, you must specify the following properties of the HistorianConnectionArgs class instance used during initiation of the historian connection:

• The StoreForwardPath property specifies where the data will be stored locally.

• The StoreForwardFreeDiskSpace property specifies how much disk space should be kept free on the drive.

• The ReadOnly property should be set to false to indicate that data storage is planned to be performed.

Example

HistorianConnectionArgs connectionArgs = new HistorianConnectionArgs();
connectionArgs.ServerName                = "HistorianComputer";
connectionArgs.UserName                  = "MyDomain\\MyUserName";
connectionArgs.Password                  = "MyPassword";
connectionArgs.ReadOnly                  = false;
connectionArgs.StoreForwardPath          = "C:\\MyData";
connectionArgs.StoreForwardFreeDiskSpace = 1024;

When a historian connection gets initiated with such arguments, the managed HCAL starts a child process called aahStorage.exe under the same user account as the SDK application and binds it to that connection and the associated store/forward path, as shown in the following diagram:

If it could be possible that there are several instances of the application running on the same computer, you should make sure that every instance of the application uses its own unique store-and-forward path. Otherwise, only the first launched application instance will be able to take advantage of the store-and-forward subsystem.

Another important point is that the user account under which the SDK application is running should have sufficient permissions to create and use the folder specified as the store-and-forward path.

The same SDK application can open several historian connections to the same or multiple historians, providing a unique store-and-forward path for every connection. A separate child process called aahStorage.exe will be automatically started per each historian connection. You can figure out which process belongs to which historian connection by looking at the command lines of those processes in Windows Task Manager. A command line of every child process will contain the corresponding store-and-forward path.

As soon as the store-and-forward subsystem is initialized properly, which can be confirmed by checking the ConnectedToStoreForward property of the connection instance, all redirection of the tag creation and the streamed data flow happens transparently for the SDK application.

For certain operations, such as storing non-streamed and revision data, deleting tags on the server, or performing retrieval, it is still necessary to have a physical connection to the historian server.

Forwarding previously collected data occurs in the background automatically as soon as there is a physical connection to the historian server. However the SDK application must be up and running in order to have that to happen.

The managed HCAL maintains a heartbeat between a historian connection instance and its store-and-forward engine process. If the SDK application terminates abnormally, the corresponding store-and-forward engine instance will detect that it was abandoned and will shut itself down within a minute.

If the SDK application is not intended to create tags or store data, it neither needs to provide a store-and-forward path, nor open a historian connection in a read-write mode.