How It Works¶
The Double Agent Connector runs inside the Seeq Agent, on the agent's host. It answers requests from Seeq with work done there, by installed plugins. This page explains the moving parts and what you see in Seeq.
The parts¶
| Part | Where it lives | What it does |
|---|---|---|
| Seeq server | Wherever your Seeq runs | Where people work; where requests are made and results appear |
| Seeq Agent | Inside the protected network | Already connects out to the Seeq server; hosts the connector |
| Double Agent Connector | In the Seeq Agent | Receives each request, reads what it needs from Seeq, runs the selected action, returns the result |
| Plugins | A folder on the agent's host | Provide the actions: the work itself. See Plugins |
| License | A file on the agent's host | Sets how many datasources and how many plugins the connector may use |
A request, step by step¶
- A request is created in Seeq as a signal belonging to the connector's datasource. Its definition carries the request: which Seeq item to work on, which action to run, and that action's parameters. Today requests are set up from a Seeq Data Lab notebook; a form in Seeq Workbench, as a Seeq add-on, is a planned option for end users.
- Someone views the signal, on a trend or in a calculation. Seeq asks the connector for its data, over the agent's existing connection.
- The connector reads what the request needs from Seeq, at that moment, through the agent's own Seeq session: the item's properties and, where the action needs them, its samples.
- The selected action runs on the agent's host, from an installed plugin, within a time limit.
- The result comes back to Seeq as samples and is shown like any other signal. If the request says where its result belongs, the connector files the signal in an asset tree under the connector's own root asset.
If something fails, Seeq shows a plain sentence saying what went wrong, for example that an action is not installed or that a parameter is not valid.
What to expect in Seeq¶
- Results are computed on request. By default the resulting data is not cached in Seeq, because of the dynamic nature of the request: each view asks the connector again, so it reflects the request's context at that moment.
- Changes in Seeq show on the next request. The connector reads context at request time, so after changing a property, refresh the view.
- The asset tree follows the requests. When a request moves its result to another place in the tree, the connector moves it there and tidies up the branch it left. It never removes or rewrites the signals people created.
Security and control¶
- Outbound only. The connector uses the Seeq Agent's existing outbound connection. Nothing new listens for connections on the agent's host.
- Rules-based work only. A request can only select an action an installed plugin provides. The installed plugins, and so what can run, are decided on the agent's side.
- Requests are untrusted input. Everything in a request is written by whoever created the signal. The connector bounds and escapes what it logs, and each action validates its parameters.
- The requester is not yet verified. Seeq does not tell a connector who is viewing a signal, so the requester named in a request is a claim, recorded as such. Limiting which items a connection serves, and verifying who asked, are designed per deployment.
- Plugins run inside the agent's process, with a time limit on each request. Install only plugins you trust.
- Licensed per host, offline: the license file is bound to the agent's host.
What it needs¶
- A Seeq Agent inside the network, at or above the connector's supported Seeq version.
- The connector and the plugins installed on the agent's host, and a license file for that host.
- No inbound firewall change.