Connectors Configuration
A SmartWeb connector is a long-lived component that gives D2000 the ability to reach a service running outside the D2000 core — whether it is a Web Push endpoint, an external HTTP API or another SmartWeb node. A watchdog periodically pings the underlying connection; if the ping fails, the connector automatically reconnects.
All connectors are configured under smartweb.application.connectors.*. This page covers the D2 service connector (registers SmartWeb as a D2000 application) and the SmartWeb federation connector (forwards requests to another SmartWeb node). The other connectors are described in:
D2 service connector (core)
The D2 service connector registers SmartWeb as a named application of a configurable D2000 process type. Once registered, D2000 ESL scripts can discover the SmartWeb instance, send it RPC calls and detect when it is offline.
smartweb:
application:
connectors:
coreConnector:
local:
enabled: true
processType: CALC # CALC | KOM | DBM | DIAL | ARCH
processName: "DEMO.SmartWebConnector"
watchdogIntervalMs: 30000 # watchdog ping intervalProperty | Description |
|---|---|
| Enables or disables the connector. |
| The D2000 process type SmartWeb registers as: |
| The unique name under which SmartWeb is registered in D2000. |
| The interval, in milliseconds, between watchdog pings on the D2000 connection. |
How it works
On startup the connector registers in D2000 with the configured
processTypeandprocessName.D2000 ESL scripts can detect
processNameas an active application and send it RPC calls (ExecuteRpc("E.SmartWebEvent", "HandleData", …)).The watchdog periodically pings the underlying connection; on failure the connector automatically disconnects and reconnects.
On shutdown the connector cleanly unregisters from D2000.
SmartWeb federation connector
The SmartWeb federation connector allows one SmartWeb node to forward requests (REST, OpenAPI, fallback API calls) to another SmartWeb node. Typical use cases:
High availability — the primary node forwards requests to a backup node when its own D2000 connection is unavailable.
Multi-tenant deployment — a single entry SmartWeb routes requests to dedicated SmartWeb nodes by tenant or D2000 application.
DMZ separation — a SmartWeb exposed to the internet forwards requests to an internal SmartWeb that holds the actual D2000 connection.
smartweb:
application:
connectors:
smartweb:
mode: LOCAL # LOCAL (no forwarding) | REMOTE (forwarding)
remote:
enabled: true
targetUrl: "https://remote-smartweb.example.com"
apiKey: "remote-node-api-key"
timeoutMs: 30000
ssl:
trustStorePath: config/cert/truststore.p12
trustStorePassword: changeit
serializationFields:
- SESSION_ID
- AUTH_CONTEXT
- REQUEST_BODY
- REMOTE_ADDR
- USER_AGENTProperty | Description |
|---|---|
|
|
| Activates remote forwarding. |
| The HTTPS URL of the remote SmartWeb node. |
| The API key authenticating the local node against the remote node. The remote node must have this key configured in its |
| Request timeout in milliseconds. |
| The truststore used to verify the TLS certificate of the remote node. |
| The fields forwarded with every forwarded request. See the table below. |
serializationFields values
Value | Description |
|---|---|
| Forward the local session ID |
| Forward the authentication context (user name, authentication type) |
| Forward the entire HTTP request body |
| Forward the IP address of the original client |
| Forward the original |
Health checks
The state of every registered connector is part of SmartWeb's health-check endpoint GET /healthcheck. Each connector has its own entry in the response, named NODE_CONNECTOR_<process-name> (dots in the process name are replaced with underscores), with a healthy flag:
{
"D2_API_CONNECTION": { "healthy": true },
"NODE_CONNECTOR_DEMO_SmartWebConnector": { "healthy": true }
}A connector is healthy when it has a live connection or (in a redundant deployment) is running on another node; otherwise it is healthy: false. A disabled connector is not included in the response.