SDKs¶
EEI builds its products on a small family of software development kits: shared libraries that carry one concern, such as resilience or licensing, so that every product gets it the same way and it is fixed once rather than in every product. This page is the current inventory, and the way into each SDK's documentation.
Why the SDKs matter to you¶
Even if you never write code against one, the SDKs are why EEI products behave consistently:
- The same behavior everywhere. Every EEI connector retries, paces itself, reports its health and enforces its license the same way, because it is the same code.
- Fixed once, fixed for all. When Seeq changes its connector platform, or a problem is found in how a connector handles a busy source system, the fix is made in the SDK and reaches every connector.
- Documented openly. You can read how the parts inside the products you run work, not just what they promise.
The inventory¶
| SDK | What it does | For | Languages | Availability |
|---|---|---|---|---|
| Connector SDK | The shared foundation of every EEI Seeq connector: indexing, reading data on demand, health reporting, config protection, license capacity | Engineers who run connectors; IT and OT teams who host them | Java, in EEI's Seeq connectors. Planned: Python, .NET | Built in, documented openly |
| HTTP Resilience SDK | How a connector paces its calls to your source systems: bounded concurrency, back-off, circuit breaking, certificate validation | IT and OT teams, and whoever owns the source system | Java, in EEI's Seeq connectors. Planned: Python, .NET | Built in, documented openly |
| Licensing SDK | Signed, server-bound licenses, verified on your server without contacting EEI | Buyers, IT, security reviewers | Java, in EEI's Seeq connectors. Python, released. In progress: .NET | Built in, documented openly. Customer view: Licensing |
| Secrets SDK | Keeps the credentials a product uses out of its configuration: one store per host, found by connection, managed with the vf-agent tool |
IT and security teams; whoever owns the accounts a product signs in with | Java, in the ABB Knowledge Manager connector. Planned: Python, .NET | Built in, documented openly |
| Plugin SDK | How Category Managers and Tools plug into the VirtualForge platform | Developers building on VirtualForge, inside or outside EEI | Python, used to build EEI's own Tools. Planned: Java, .NET | Open to partners and third parties, as VirtualForge opens |
| Notification SDK | One event contract for operational outcomes, routed to a record, chat, alerting and incident tools | Teams who operate systems and respond to their failures | Python, running EEI's operations. When a product needs them: Java, .NET | Used by EEI operations, documented openly |
What "availability" means here:
- Built in, documented openly. EEI uses the SDK inside its own products, and it ships inside them. You never install it separately, and it is not offered as a kit for outside development. We publish how it works because you run the products it is in.
- Used by EEI operations. EEI runs the SDK to monitor its own services and route its incident notifications. It is not yet inside customer products, and is documented here because it is the core of a VirtualForge capability that is in development.
- Open to partners and third parties. An SDK you will be able to build against yourself, to add your own Tools and Category Managers to VirtualForge. The plugin SDK is the first. Today EEI builds its own Tools with it; it opens to outside developers as the platform does, and its developer documentation will appear here then.
How the SDKs are built¶
Each SDK is its own repository, with one implementation per language beside a shared, written contract that every language must honor. The licensing SDK's Java and Python versions verify each other's licenses, for example. Each is versioned and released independently, and every release goes through the same continuous integration as EEI's products. More on that in Engineering Practice.