Integrations
CMS integrates in two directions, and not every protocol supports both:
| Protocol | Collection (into CMS) | Delivery (out of CMS) |
|---|---|---|
| HTTP REST | HTTP_GET, HTTP_POST | HTTP_POST, HTTP_PUT, HTTP_PATCH, HTTP_DELETE |
| SOAP | /ws/... endpoint exposed by CMS | HTTP_SOAP |
| MQTT | MQTT_TOPIC_SUBSCRIBER | MQTT_PUBLISH |
| SQL Server | SQL_SERVER | SQL_SERVER_EXEC |
| Oracle | ORACLE | ORACLE_EXEC |
| PostgreSQL (includes TimescaleDB) | POSTGRES | POSTGRES_EXEC |
| SQLite (file-based database) | SQLITE | SQLITE_EXEC |
| InfluxDB (1.8, 2.x and 3.x) | INFLUXDB | INFLUXDB_WRITE |
| MongoDB (includes Atlas, Cosmos DB and DocumentDB) | MONGODB | MONGODB_WRITE |
| SAP RFC/BAPI | SAP_RFC | SAP_RFC_CALL |
| SAP IDoc | SAP_IDOC | — |
| SAP Gateway (OData) | HTTP_GET, HTTP_POST | HTTP_POST, HTTP_PUT, HTTP_PATCH, HTTP_DELETE |
| SAP CPI (Cloud Integration) | HTTP_GET, HTTP_POST | HTTP_POST, HTTP_PUT, HTTP_PATCH, HTTP_DELETE, HTTP_SOAP |
| OPC UA | OPC_UA_TRIGGER | OPC_UA_WRITE |
| Modbus TCP | MODBUS_TRIGGER, MODBUS_POLL | MODBUS_WRITE |
| Sparkplug B (over MQTT) | SPARKPLUG_SUBSCRIBER | SPARKPLUG_CMD |
| PI Web API (AVEVA/OSIsoft) | PI_WEB_API | PI_WEB_API_WRITE |
| Files (directory) | FILE_WATCH | FILE_WRITE |
The table above is about protocol — how data gets in and out. The payload format is a separate decision, and it lives in the Transformer. When the destination speaks a manufacturing standard, the CMS ships the models ready-made: see ISA-95 / B2MML.
Push vs. pull
- Pull (scheduled) — CMS fetches on an interval/cron: HTTP, SQL, Oracle, PostgreSQL, SQLite, SAP RFC, PI Web API, Modbus poll, directory scanning.
- Push (event) — the external system delivers to CMS when something happens: REST/SOAP reception, MQTT, SAP IDoc, OPC UA trigger, Modbus trigger, Sparkplug B.
A plain REST integration needs no dedicated adapter — HTTP_GET/HTTP_POST + Credential +
Transformer covers it. Native adapters exist because SAP, OPC UA, MQTT and Modbus are not HTTP.
PI Web API is the exception that proves the rule: it is HTTP, and the connector does use HTTP underneath — what it adds is knowledge of the PI domain (WebId resolution and caching, time windows, sample quality), not a new transport. That is worth it when the external product has a vocabulary specific enough that hand-writing URLs becomes a recurring source of errors.
What every integration needs
- An External Connection with the server details (except HTTP, which uses a Credential).
- A Collector or Delivery Definition pointing at that connection.
- Optionally, a Transformer to adapt the payload.
- For pull collectors, an active schedule.