Ignition 8.3: Building a custom tag historian module

3rd Party Modules
1

Hi all,

There is an upcoming historian in Belgium, called Factry, that is looking to build an Ignition historian module, possibly with our help. If we build it, we plan to build it open source, so others can learn from it and contribute to it.

I suggested waiting for Ignition 8.3 since it’s just around the corner. The new in-historian aggregation option in 8.3 could significantly strengthen the use case for such a module.

Seeking Contributions and Advice

We’d love some help building this module! We plan to ask questions here and welcome contributions to the code from the community. Resources like this forum post are already incredibly helpful and have given us a solid starting point, and we have a little experience from when we build our branching component.

Key Questions We Have:

1. Historian Support in 8.3

  • It seems the Ignition 8.3 historian will initially support only QuestDB, with additional historian connections left for us to build.
  • Will there be any examples or documentation on building these connections?
  • Might the QuestDB integration be open-sourced? If yes, this could save us a lot of time and effort.
  • If not, would this module (built for 7.9) be of any use? It's probably a big stretch, but it’s the only resource I’ve found so far where a history provider is being build.

2. Using the Ignition 8.3 API Docs

  • I found the API documentation for Ignition 8.3, but it’s quite extensive.
  • Is this everything needed to build the module?
  • Where should we start, and how can we ensure we’re following best practices during development?

Any advice, examples, or tips would be greatly appreciated.
Looking forward to your thoughts! :blush:

5 Likes
2

I very highly doubt they will open source the QuestDB code. I'm also guessing current/existing historian options of using standard databases will not go away.

Others will have to chime in on the other questions.

2 Likes
3

Eventually yes, but probably not in the short-to-medium term. As in, I wouldn't rely on examples being available for at least six months.

No.

Probably not as helpful as you'd like it to be. The core concepts are similar in very broad strokes, but all of the APIs will be completely different. That example would probably help to make an 8.1 compatible historian, but won't help with 8.3's concepts.

No. The Javadocs are useful reference material but you won't actually be able to build a module until public beta begins and you have access to the SDK to compile against.

This is pretty much too open-ended of a question to answer. The bare minimum starting point would be a working module example that implements a GatewayHook. I'd recommend Gradle as a build system, not out of any particular love for Gradle but because it's where all of our first-party developer time is going. Then you "just" have to implement the historian APIs to hook into the rest of the system. You're, at minimum, going to have to understand our new gateway configuration API, including the new way 'extension points' (in your case, additional historian provider types) are set up, and then the actual historian API itself.
As you get further along, you could talk with our Sales Engineering department, who might have resources to help talk you through more specific implementation details; devs like Kevin H and myself are on the forums but only do public help, pro-bono, very explicitly, and neither of us are really experts in the new historian.

1 Like
4

Hi all,

I’m a colleague of Jasper, and I’m checking in to see if it’s time to move forward with implementing the custom historian module for Ignition 8.3, now that about ten months have passed.

I tried compiling some code based on the 8.3 documentation, but during ./gradlew build I found the following packages missing from SDK 8.3.1:
• 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.api.paths

This seems to be a blocking issue. Do you have any suggestions on how to proceed, or should we continue waiting?

Best,
Gabor

2 Likes
5

Historian related packages are in a separate artifact, because the historian is now a dedicated module and (as much as possible) has been pulled out of the core platform.
You need to add the historian dependency to your build system, as in:

The relevant artifact IDs are historian-common and historian-gateway.

2 Likes
6

Try to stick to just the classes available in the gateway api packages... we're not correctly separating and publishing the historian SDK components right now. This should get cleaned up a bit over the next release or two.

3 Likes
7

Thank you for your quick responses.

However, I’m a bit confused. Kevin, if I understand correctly, your suggestion is to keep using the old API until the new one is cleaned up. That would mean anything we implement now would soon need to be redone.

We’ve been waiting for the new API because we want to avoid duplicating work. But if “soon” isn’t actually that soon—or if the old API will still be supported for a while—it might make sense to continue with the current one.

Could you please clarify the expected timelines? For example, will the old API be deprecated within a year? And do you expect the new one to be stable within the next few months?

Thanks in advance!

8

Use the new API but don't stray outside these packages:

  • com.inductiveautomation.historian.gateway.api
  • com.inductiveautomation.historian.common.model

The artifact being published hasn't been properly split into API and implementation, so there's stuff in there that is not part of the API, not public, will be removed, and never should have been there.

These all exist, so perhaps you don't have your build system / dependencies squared away yet.

1 Like
10

That makes perfect sense now, thanks.

I’ll give it a try shortly and see how far I can get.

11

Hi there,

I’ve managed to implement several historian components (inheriting from AbstractHistorian, AbstractQueryEngine, and AbstractStorageEngine). They compile and load without errors, and my module can create and start historian instances programmatically.

At the moment, I’m only depending on com.inductiveautomation.historian.gateway and common as you suggested.

However, I’m blocked on getting our historian type to appear in the Gateway UI dropdown at Config → Services → Historians → Create New Historian Profile.

What I’ve tried:

  1. Creating a HistorianExtensionPoint implementation and attempting to register it via HistorianManagerImpl.getExtensionPointCollection(). The returned collection appears immutable.

  2. Adding a Java SPI service file at
    META-INF/services/com.inductiveautomation.historian.gateway.api.HistorianExtensionPoint.

  3. Reviewing StandardHistorianCollection and noticing it uses a hard-coded static list of extension points.

Obviously my question now:

What’s the proper way for third-party modules to register custom historian types so they show up in the Gateway UI dropdown? Is there a specific API, configuration, or module hook pattern we should use for extension-point registration in Ignition 8.3.1?

Any guidance would be greatly appreciated!

12

In 8.3 all ExtensionPoints are registered by returning them from GatewayModuleHook::getExtensionPoints.

2 Likes
13

That was it! Great, thanks!