Kafka Driver

Kafka Driver Diagram

The OAS Kafka driver is both a producer and a consumer, against a cluster running on the local network or a hosted one such as Confluent Cloud. A tag can subscribe to a topic and take its value from the messages on it, and the same driver can publish selected tags to a topic on an interval, on a trigger, or at a time of day.

PropertyDescription
DirectionRead and write. Tags subscribe to a topic through the driver; the driver publishes selected tags to a topic.
TransportKafka protocol to one or more bootstrap servers
SecurityPlaintext, SSL, or SASL - including a Confluent Cloud API key and secret
BufferingStore and Forward, buffered to disk and forwarded when communication is restored
FailoverA second, independent cluster the driver moves to when the primary connection fails
LicensingRequires the Kafka licensed option, on OAS 18.0.0.4 or later

Kafka Consumer

In a consumer configuration you set the Kafka driver parameters to connect to a cluster, then create tags whose Data Source is Kafka. Each tag names the Topic it subscribes to, and takes its value from the messages published there. A consumer tag is a String or a JSON tag, so a JSON payload can be parsed into its members rather than held as text.

Consuming needs no publishing configuration on the driver - a driver interface with nothing selected to publish is a perfectly good consumer.

Kafka Producer

A producer configuration is the same driver with Publish Selected Tags turned on. The tags listed in Tags To Publish are published to a topic on a configurable interval, when a boolean trigger tag changes, or at a set time of day, and the JSON payload each message carries is yours to shape.

Tags can be published individually or combined into a single topic, with the tag identifier, value, quality and timestamp each named by a field you choose. Messages can also be published against a schema instead: ISA-95 Lite, a built-in record aligned with the ISA-95 equipment hierarchy for a unified namespace, or a Custom AVRO Schema of your own, with or without a Confluent Schema Registry.

Connection

A connection is defined by its bootstrap servers and its security protocol. Plaintext is the usual choice for a cluster on the local network; a hosted cluster will want SSL or one of the SASL protocols, where the SASL user name and password are the API key and secret issued by the provider.

Acknowledgement strategy, client identifier and compression are set on the same screen, alongside the batching, buffer, timeout, socket and transaction settings that tune throughput against latency. Each parameter is listed in the Config Reference.

Store and Forward

When the driver cannot reach the cluster, Store and Forward buffers values to a directory on disk rather than discarding them, and forwards them once communication is restored.

Failover

With failover enabled the driver is given a second cluster - its own bootstrap servers, its own security and its own Schema Registry - and moves to it when the primary connection fails.

Videos

Both are on the Videos page.