Публикация данных

В разделе о платформе дано подробное описание Внешней системы.
Описание протокола приведено в разделе для разработчиков.

Настройка публикации

Публикация данных поддерживается на брокеры MQTT, AMQP,KAFKA

Инфо

Платформа отправляет данные по mqtt, AMQP, Kafka в роли клиента внешнего брокера. Перед настройкой подписки необходимо уточнить параметры подключения к брокеру.

1. Авторизоваться cуперпользователем root в платформе
2. Загрузить форму в меню Внешние системы->Публикация данных
3. Выбрать запись конкретной внешней системы.
4. На форме Публикация данных выбрать подпункт меню: Подписка MQTT, Подписка AMQP, Подписка Kafka
5. Создать запись подписки:
   5.1. MQTT, ввести данные подключения:
   - url mqtt брокера;
   - логин/пароль;
   - порт.

Виды авторизации:

• TRUST(1) - Авторизация не требуется;
• PASSWD(2) - Авторизация с помощью логина и пароля;
• TLS12(3) - Авторизация TLS v1.2

Если брокер не требует авторизации, следует указать тип авторизации authType = TRUST(1) (доверенная авторизация, характерна для брокеров находящихся в одной сети, управление доступов в таком случае осуществляется средствами брэндмаура или политиками безопасности на уровне портов/приложений)
Если на брокере настроен ACL плагин HTTP авторизации, по логину и паролю - следует задать тип авторизации authType = PASSWD(2) и значения brokerUser и brokerPassword.

Для TRUST(1) и PASSWD(2) коннект задается, как показано ниже

tcp://<имя хоста/адрес>:<порт>, 
Например:
tcp://10.0.0.1:1883

Если на брокере установлена поддержка авторизации с открытым ключом TLS v1.2 - следует указать тип авторизации authType = TLS12(3) и загрузить сертификаты в атрибуты:

• certCa (корневой CA сертификат для авторизации брокера)
• cert (сертификат клиента, с которым мы будем авторизовываться в брокере)
• certKey (приватный ключ сертификата клиента)

Сертификаты загружаются в виде текста их содержимого и сохраняются как есть без каких-либо преобразований.

Примечание

Так же следует корректно задать brokerUrl, в данном случае он должен начинаться с протокола SSL и содержать имя машины для подключения, например "ssl://ubuntu20:8883". При этом машина брокера (в этом примере ubuntu20) должна быть доступна в сети по этому имени и имя должно соответствовать записи "Common Name" клиентского сертификата (и брокерного, соответственно, тоже).

ssl://<dns имя хоста/адрес>:<порт>, 
Например:
ssl://ubunta20:8883

Поддерживается два формата передачи данных:

• JSON;

• ANDROMEDA.

  5.2. AMQP, ввести данные подключения

  • адрес брокера;
  • логин/пароль;
  • порт;
  • виртуальный хост.

  5.3. Kafka, ввести данные подключения:

  • dns Имя хоста:порт.

<dns имя хоста/адрес>:<порт>, 
Например:
ubunta20:9092

Примечание

Вместо имени хоста можно указать IP адрес, но служба DNS должна знать имя хоста (кафка оперирует именами а не адресами)

Формат передачи данных и событий см в разделе разработки

6. Нажать кнопку Параметры, и выбрать в модальном окне список параметров, которые требуются передать.

Параметры сервера трансформации измерений/событий (опционально):

В том случае, если:

• требуется, чтобы публикация шла в специальные топики/очереди;
• требуется прием команд от внешних систем;
• необходимо поддержать определенный формат измерений/событий.

необходимо заполнить следующие поля:

• ТОПИК ДЛЯ ОТПРАВКИ ИЗМЕРЕНИЙ/СОБЫТИЙ - имя топика/очереди, в который публикатор передает измерения;
• ТОПИК ДЛЯ ПРИЕМА КОМАНД - имя топика/очереди, в который получатель передает команды обратно публикатору$
• ТОПИК ДЛЯ РЕЗУЛЬТАТА ВЫПОЛНЕНИЯ КОМАНД - имя топика/очереди, в который публикатор передает измерения:
• HTTP URL СЕРВЕРА ТРАНСФОРМАЦИИ ИЗМЕРЕНИЙ/СОБЫТИЙ - адрес сервера трансформации измерений для преобразования данных в формат внешней системы.

Общая информация по сертификатам

Есть три группы по ответсвенностям: админ CA, брокер, клиент.

Админ CA, который хранит корневой сертификат CA и сложный секретный ключ к нему. Он его может сгенерировать или где-то получить, это его ответсвенность.

• ca.crt
• ca.key

Брокер, который хранит свой приватный ключ broker.key. На основании этого ключа запрашивает у админа CA сертификат (создает запрос сертификата broker.csr и отправляет его каким-то образом админу CA), тот генерирует ему подписанный сертификат broker.csr и отправляет назад). Таким образом у брокера:

• ca.crt
• broker.crt
• broker.key

Клиенты брокера, каждый хранит свой приватный ключ client.key. Аналогично брокеру, они формируют запрос к админу CA на создание сертификата, при этом в запросе указывают имя "Common Name" то же что указал брокер в запрос своего сертификата (он должен как-то им сообщить). Админ CA формирует клиенту клиентсткий сертификат client.crt. Таким образом у клиента:

• ca.crt
• client.crt
• client.key