The management of the asynchronous transport of messages assumes a DirectDataLink internal service. This is triggered by corresponding interface methods.
There are five main operating modes for the Notification Service:
AMQP mode is used to send JSON messages to either a message broker (e.g. Rabbit MQ with AMQP0.9) or a message maintenance queue (e.g. Universal Messaging with AMQP1.0).
HTTP mode is used to send either JSON or any other supported content type format (e.g. text/Plain, application/JSON) to a REST service via the HTTP protocol.
Kafka mode is used to generate JSON messages at Kafka brokers. From DDL V4.9 and higher, it is possible to configure other modules that communicate via WCF (e.g. Data Collector Access) in order to send their module-specific SOAP messages to KAFKA brokers too. In this case, there are two queues in the notification service:
In-store queue with customer-defined size, 500 by default, which is responsible for sending the new incoming messages;
A queue consisting of the backup files that sends the messages that remained in DirectDataLink due to temporary unavailability of the broker and were not sent to the Kafka broker.
This file-based queue is subject to the following restrictions:
- an OSS project with multi-instance configuration is not supported.
- multiple OSS projects with an instance configuration (the result is also a multi-instance) are permitted. This requires the configuration of separate backup folders.
Solace mode is used to send either the JSON messages of the standard notification service or messages in raw format (XML or DAT) directly from the machine to a queue of the Solace broker. This mode provides the ability to publish messages to a broker list that also implements failover security.
IOTHUB mode (from DDL V5.14 onward) is used to send either JSON messages from the standard notification service or messages in raw format (XML or DAT) directly from the machine to an Azure IoT Hub. By default, the messages are sent via AMQP. However, messages can also be sent to the Azure IoT Hub via MQTT and HTTP. This behavior can be set when configuring the Notification Service. Depending on the communication protocol used, the Notification Service reaches the Azure IoT Hub using the following port number:
Protocol
Port number
Note
AMQP
5671
AMQP via WebSockets
443
This protocol is used as a fallback if the connection to the IoT Hub via the native AMQP TCP port fails (e.g. due to firewall rules or network settings).
MQTT
8883
MQTT via WebSockets
443
This protocol is used as a fallback if the connection to the IoT Hub via the native MQTT TCP port fails (e.g. due to firewall rules or network settings).
HTTP
443
In IOTHUB mode, messages that are larger than 256 KB are rejected by the Azure IoT Hub because there is a maximum message size in the IoT Hub. Reference: IoT Hub quotas and throttling
If plcLogIn messages contain passwords, they are masked before being sent via the Notification Service. This is done both for messages in raw data format and for messages in JSON format.