Внешняя система

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

Операции с Внешней системой

Создание Внешней системы

1. Авторизоваться Суперпользователем в платформе
2. Загрузить форму в меню Справочник->Справочник внешних систем
3. На форме создания Внешней системы заполнить поля:

• ИМЯ ПРИЛОЖЕНИЯ - это имя будет доступно для перехода в основном меню всех приложений платформы (см. в полоске меню "...")
• ID - код приложения, внутреннее имя внешней системы, используется в топике подписки mqtt.
• url - ссылка перехода на внешнее приложение

Удаление Внешней системы

Операции редактирования и удаления записи Внешней системы не требуют пояснений. Отметим, что эти операции доступны только для Суперпользователя.

Настройка web-hook

Инфо

Отправка событий во внешние системы по технологии web-hook требует применения соответствующего модуля интеграции.

Для отправки событий по web-hook следует выполнить следующие шаги:

1. Авторизоваться в системе ролью не ниже Configuration Mng (CA или SA или root).
2. Зайти в справочник событий на форме события.
3. Отметить на форме чек бокс Экспорт
4. По кнопке Выберите внешние системы для экспорта отметьте те внешние системы, которым будут отсылаться это событие.

Настройка MQTT, AMQP,KAFKA

Инфо

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

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

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

• 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.3.2.38:1883

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

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

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

Примечание

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

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

• JSON;
• ANDROMEDA.

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

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

Если получателю требуется определенный формат измерений/событий, необходимо заполнить данные сервера трансформации, т.е. заполнить следующие поля:

• 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