Working with a Redundant Historian

The AVEVA Historian SDK provides an interface for sending streamed data to a redundant historian. You can find information on how to create a redundant historian configuration in the AVEVA Historian Administration Guide.

The redundant historian interface is implemented by a multi-historian connection proxy object of class MultiHistorianAccess, which represents an additional abstraction layer duplicating the same original streamed data flow to one or more historian servers pointing to each other as partners.

The MultiHistorianAccess object internally maintains up to two HistorianAccess objects and provides a built-in partner discovery mechanism that gets activated when at least one of the partner historians becomes available.

Each internal HistorianAccess object works independently and can store the data locally in its own folder using its own store/forward engine process if its historian server becomes temporarily unavailable. The discovered partner historian name is preserved in the store/forward folder allowing storing data in the store-and-forward mode on the next startup in case of unavailability of both partners.

IMPORTANT: Storing original streamed data is the only user workflow supported by the MultiHistorianAccess class in the AVEVA Historian SDK. If you need to store original non-streamed or revision data, or perform data retrieval, you have to open separate connections to partner historians using the HistorianAccess class and repeat the same storage or retrieval operation for all partners.