Skip to content

Connectors ++

Connectors ++ is the production-grade capability set that rides along on every EEI connector. We call the result Connectors Made Easy.

Getting data into Seeq is the starting line, not the finish. A basic connector can move items into a datasource; keeping that data current, organized, reliable, and supported at real scale is where most of the engineering lives. That extra engineering is the "++".

Because it lives in a shared foundation rather than being rebuilt per connector, every EEI connector inherits the same capability set — which is why a new connector can be delivered quickly and still arrive at the operational quality of an established one.

Connected Intelligence starts with connection and is the foundation for new value.

The baseline, and the "++"

A connector generally An EEI connector
Gets data into Seeq ✓ ✓
Keeps it current without a full rebuild Some do ✓ wherever the source can report what changed
Organizes without duplicating Often, within its own datasource ✓ including over signals the connector does not own, from several sources at once
Stays fast as volume grows Varies by connector ✓ incremental and parallel indexing, on every connector rather than some
Behaves the same way on every run Varies by connector ✓ one engineered indexing lifecycle, with reporting and monitoring over it
Survives a source system having a bad day — ✓ retry, backoff, and flow control
Protects your configuration — ✓ automatic backups before every load
Can be platform-managed, at your option — ✓ an optional VirtualForge connection, which opens up licensing, updates, and operational analysis without ever being required to run
Comes with support ✓ from whoever built it ✓ EEI support, working directly with Seeq support

Two honest notes about that middle column, because a comparison that overstates the gap is worth less than one that does not.

Seeq's own connectors are good, and several already do some of this. A number of them organize without duplicating, and some index incrementally and in parallel. The difference is usually not whether a capability exists somewhere but whether it exists on every connector, to the same standard — Seeq's connectors are built by different teams at different times, while EEI's all sit on one shared foundation, so a capability added there arrives everywhere at once.

Where a Seeq connector does organize without duplicating, it does so within the context of its own datasource: its data and, optionally, that same source's metadata. Applying metadata to signals a connector does not own — pulled from one upstream system or several at once — is a different job, and it is the one our Metadata Connector exists to do.

Seeq supports the connectors Seeq builds, and that is real support worth having. What varies is third-party connectors: how much a given provider actually offers, and how far Seeq can reasonably assist with code it did not write. That variance — not an absence of support — is what the last row is about, and the section below is our answer to it.

What you get today

Capability What it does for you
Engineered indexing lifecycle One proven implementation shared by every EEI connector — safe writes, orderly updates, and resilience to transient source failures, the same way on every run
Indexing reporting and monitoring Each connector reports its own health and indexing activity into Seeq, as a browsable monitor tree covering run counts, outcomes, and data flow — so indexing status is visible beside the data it produced, rather than buried in an agent log an engineer has to go and find. Self-service dashboards over the same signals are planned
Incremental indexing Where the source system can report what changed, only changed records are updated on a short interval instead of rebuilding — so Seeq reflects what is true now
Dynamic scheduling Configurable full and incremental index schedules, per connector and per datasource
Fast at scale Indexing runs in parallel, so large source systems stand up and stay current as tag counts grow
Resilience under load Retry with backoff, adaptive concurrency, and circuit breaking, so a throttling or flaky source degrades visibly and recovers rather than silently losing data
Structured diagnostics Consistent logging across all connectors, with a per-connector diagnostic mode that can be turned on without restarting the agent
Configuration self-protection A timestamped backup of each datasource's configuration before every connector load — so an accidental reset or edit cannot lose your setup. Restore takes seconds. Native Seeq connectors do not offer this
Built for Seeq Continuous Delivery Designed to keep pace as Seeq evolves, so your connections keep working across platform releases
Tracked against every Seeq release Each new Seeq Connector SDK release is checked automatically against every EEI connector, built and tested against it before adoption, and the platform change absorbed once in the shared layer — so staying current is maintenance EEI performs, not a project you schedule
Licensed, delivered, supported Connectors ship with defined licensing and are delivered and supported by EEI — not handed over as unsupported code

Not every capability is exercised by every source. Incremental indexing, for example, needs a source system that can report what changed; where a source cannot, the connector uses a scheduled full index instead. Each connector's own documentation states what it does.

The optional VirtualForge connection

Every EEI connector can run entirely standalone, and today they normally do. Licensing is a signed license file validated on the agent host with no network call, so a connector inside an isolated OT network — no outbound internet, no dependency on a platform being reachable — is a supported configuration rather than a workaround. Nothing described above needs a connection.

What a connection adds is management: a connector that can reach VirtualForge stops being something an engineer tends by hand and becomes something the platform looks after on your behalf. Most of what that unlocks is in Planned below — automated upgrades, proactive health monitoring, and self-service dashboards all arrive over this one link. Licensing gains the same benefit: an entitlement served from the authoritative record, rather than from a file that has to be reissued and redeployed whenever something about it changes.

The architecture was built for this rather than retrofitted to it. Entitlement validation already sits behind an interface with the online source designed in, so a connected instance will prefer the authoritative record and fall back to its signed file when disconnected — with no change to how enforcement behaves, which is what makes the offline case a genuine peer rather than a stub.

It is also why this is one connection rather than a feature-by-feature integration: the same link is what later platform-side capability arrives over. The one we find most interesting is a connector's logs and operational history becoming something you can get real insight from, instead of something read only after a problem has already happened. To be exact, though: that is a possibility this connection creates, not a commitment. It is deliberately not in the Planned table below, and it has no date.

It stays optional. Connecting is a per-deployment decision, and an air-gapped installation remains a first-class case rather than a degraded one.

Keeping pace with Seeq, concretely

Seeq publishes new Connector SDK releases continuously — roughly monthly. Rather than pinning to a version and revisiting it when something breaks, EEI checks each release against every connector as it lands: what changed, whether it touches anything a connector actually uses, and whether the connector still builds and passes its tests against it. Only then is it adopted.

Two things make that affordable rather than a treadmill. The platform-facing code lives in one shared layer used by every EEI connector, so a Seeq change is adapted once for the whole range instead of once per product. And because every connector is on the same shared layer, they all move forward together.

The visible effect is a connector version number whose first part follows the Seeq SDK line it was built on — which is why it can jump between releases. Each connector's documentation explains its own version numbering and names the Seeq version a release was validated against.

Planned

Forward-looking. These are planned additions to the capability set — committed direction rather than work you can use today. Details, naming, and availability may change, and nothing here is a commitment to deliver a specific feature on a specific date. Where a capability below depends on another product, that product's own status is linked.

Capability What it will do
Automated connector upgrades VirtualForge schedules and delivers new connector versions to the agent hosting them, removing the manual redeployment step
Proactive health monitoring Connectors stream diagnostics to VirtualForge, where automated analysis assesses health and raises issues — so problems are caught early, often before they affect your data
Operational dashboards Connector activity and indexing status, self-service, through ForgeIQ — itself in active development

All three arrive over the optional VirtualForge connection, which is why it is one link rather than three integrations — and why a connector that stays unconnected simply does without them rather than breaking.

Support — what "supported by EEI" actually means

"Comes with support" is the easiest row in the table above to write and the hardest to mean, so here is the commitment in full. It applies to every EEI connector; each connector's own support page adds only what is specific to it — what to include in a report for that source system, and where its logs are.

  • A response commitment and an effort commitment — not a resolution date. We respond within one business day of an issue reaching us, by whichever route: a person who has looked at it, telling you where it stands and what we are doing about it. Not a fix date we cannot honestly predict — a date invented to satisfy a process is worse than no date, because it reallocates your planning around a guess. We say what we do, then we do what we say. If you need something more specific than this, we settle it during contracting rather than during an incident — see Getting Support from EEI.
  • Platform currency is our work, not yours. We track Seeq's releases, assess each one against every connector, and validate before adopting. You do not schedule a project to stay current.
  • Coordinated updates. New versions are delivered and scheduled with you, never applied unannounced.
  • Named validation, not implied ranges. Each release states the Seeq version it was tested against. Where Seeq has not defined a supported window, naming the version we actually tested is more useful than implying compatibility we have not verified.
  • Continuity across upgrades. Item identities are designed to survive a connector upgrade, so existing worksheets, trends, and calculations keep resolving afterwards.
  • We work with Seeq support directly, not at arm's length. Connector problems are usually ambiguous at the moment they are reported — is this the connector, the agent, the source system, or the platform? That ambiguity is exactly where multi-vendor issues stall, each party reasonably believing it belongs to someone else. So it does not matter how you raise it: through us, or through Seeq. We maintain a working relationship with Seeq support and collaborate on the back end to get an issue to resolution from whichever side actually owns it. Working out which vendor to call is not your job, and neither is relaying messages between us.

Where the line is. We support the connector and its behavior against your source system. We do not support the source system itself, the content it holds, Seeq Server (Seeq supports the platform), or the analyses your teams build on the data. Each connector's page states its own boundary precisely — an unwritten one gets discovered at the worst possible moment.

A boundary is not a dead end. Where an issue turns out to sit on Seeq's side of that line, we do not close it and point you at another vendor. We take it to Seeq with the diagnostic work already done, and stay on it until it is resolved. The line describes who fixes what, not where our interest stops.

Reaching us. Through your usual EEI contact, or the resources hub. Where a connector is delivered through a channel partner, that partner is your first line and involves us as needed — either route reaches the same engineers.

Access to your Seeq server

Supporting a connector well means seeing what Seeq sees: the agent and its version, each datasource's status, settings and indexing, and the connector messages Seeq shows. With your agreement, EEI works with an administrator account on your Seeq server for this, under the scope and conditions your security policies require. With it, we can look into an issue as soon as it reaches us, check your datasources during and after an upgrade, and make Seeq-side changes together with your team, rather than relaying each look and each change through you.

If EEI does not have that access today, we would like to arrange it with you, and with Seeq where Seeq hosts your server. Access to the agent host that runs the connector stays with your team either way.

EEI does not need this access, but without it our ability to support our connectors is reduced: each look at the Seeq side goes through your team, and issues take longer to resolve.

What this costs to live with

The reason to care about any of the above is that connectors are usually judged on the day they are installed and paid for every day after. The capabilities that matter over a multi-year life are the unglamorous ones: that a run behaves the same way every time, that a source outage is visible and recoverable rather than silent, that an accidental configuration change is a thirty-second restore rather than a rebuild, and that there is someone to call.

Commercially, the same principle applies — one predictable price rather than per-connector surprises. Connectors Made Easy.

Where to read more

This page is the customer-facing account of what Connectors ++ gives you. A deeper technical reference — the shared connector foundation, its interfaces, and how a connector is built against it — is maintained by our engineering team and will be published alongside the connector SDK documentation. If you need that level of detail before then, ask us.