Historian SDK API Changes in Ignition 8.3.3

Overview

Starting in Ignition 8.3.3, the Historian gateway API has been isolated into a dedicated historian-gateway-api module internally. This separation decouples the public SDK APIs from the internal implementation, providing a cleaner dependency surface for third-party module development.


What Module Authors Need to Know

1. SDK Dependency Name Unchanged

The SDK artifact name remains the same:

compileOnly("com.inductiveautomation.ignitionsdk:historian-gateway:8.3.X")

No changes required to your Gradle dependency declarations. The internal reorganization is transparent at the SDK artifact level.


2. Package Imports Remain Unchanged

The class packages have not changed. All API classes remain in:

  - com.inductiveautomation.historian.gateway.api.*
  - com.inductiveautomation.historian.gateway.api.config.*
  - com.inductiveautomation.historian.gateway.api.query.*
  - com.inductiveautomation.historian.gateway.api.storage.*
  - com.inductiveautomation.historian.gateway.legacy.*
  - com.inductiveautomation.historian.gateway.interop.*
  - com.inductiveautomation.historian.gateway.util.*

3. TagHistoryProvider Changes (Breaking)

If you implement TagHistoryProvider<S>, the default getStorageEngine() method has been removed. You have two options:

Option A: Extend LegacyTagHistoryProviderAdapter (Recommended)

A new abstract adapter class handles storage engine management automatically:

  public class MyHistorian extends LegacyTagHistoryProviderAdapter<MySettings> {

      public MyHistorian(GatewayContext context, String historianName) {
          super(context, historianName);
      }

      // Implement TagHistoryQueryInterface methods...
      // getStorageEngine() is automatically provided by the adapter
  }

Option B: Implement getStorageEngine() manually

If you need custom storage engine behavior:

  @Override
  public Optional<StorageEngine> getStorageEngine() {
      return Optional.of(
          TagHistoryStorageEngineBridge.getOrCreate(context, getName())
      );
  }

4. New Helper Classes

HistorianModule - Abstract base class for gateway module hooks that provide historian functionality. Use HistorianModule.get(context) to retrieve the instance and access the HistorianManager:

  HistorianManager manager = HistorianModule.get(context).getHistorianManager();

LegacyTagHistoryProviderAdapter<S> - Abstract base class for legacy historian implementations. Automatically creates and manages a TagHistoryStorageEngineBridge for Store and Forward integration. Extend this class instead of implementing TagHistoryProvider directly.

HistorianUtilities - Static utility methods for converting between legacy and modern query formats, managing query flags, and other common historian operations.


5. Kotlin to Java Conversion

Some classes were converted from Kotlin to Java:

Class Change
HistorianProvider Now a Java record instead of Kotlin class
HistorianExtensionPoint Now a Java abstract class instead of Kotlin abstract class

The API signatures remain compatible, but if you were using Kotlin-specific interop features, you may need to adjust.


Migration Checklist

  • If implementing TagHistoryProvider, either extend LegacyTagHistoryProviderAdapter or implement getStorageEngine() explicitly
  • Rebuild and test your module against Ignition 8.3.3+

If you have questions, please reply to this thread.

4 Likes

Hi Kurt, I tried using the 8.3.3-rc1 library and it looks like I lose access to some of the previous legacy classes. Where is HistorianProviderRecord now? I’m using Gradle, and my toml definition looks like

historian-gateway-api = {module = "com.inductiveautomation.ignitionsdk:historian-gateway", version.ref = "historian-api"}

Unfortunately, it looks like this file wasn't relocated into the historian-gateway-api module. I'll get this fixed ASAP. Thanks.

Hi Kurt, are there any future plans to allow developers the ability to create their own store and forward/quarantine implementations?

@Kurt.Larson

Unfortunately, it looks like this file wasn't relocated into the historian-gateway-api module. I'll get this fixed ASAP. Thanks.

This has been fixed for 8.3.3.

Hi Kurt, are there any future plans to allow developers the ability to create their own store and forward/quarantine implementations?

Yes, this was an unfortunate oversight due to all the 8.3 changes in this area. I'll make a new post once it's possible. I can't give an exact timeline, but I'll try to prioritize it for 8.3.5.