¶ 6. Внешние системы
¶ 6.1. Понятие Внешние системы
Сущность Внешние системы предоставляет интеграционные возможности для внешних систем/платформ, которым требуется данные от платформы.
Платформа предоставляет следующие способы получения данных:
- Использовать REST API платформы для получения данных по запросу.
- Получать событийную информацию в реальном времени по http протоколу. Этот вариант подходит, например, для ITSM систем, которые используют платформу как event-mng систему, для управления инцидентами и задачами в процессах ITSM.
- Получать поток данных в реальном режиме времени по протоколам MQTT, AMQP (RabbitMQ), Kafka. Этот вариант может использоваться в самых различных сценариях, где требуются данные от платформы.
¶ 6.2. Операции с Внешней системой
¶ 6.2.1. Создание Внешней системы
- Авторизоваться Суперпользователем в платформе
- Загрузить форму в меню Справочник->Справочник внешних систем
- На форме создания
Внешней системызаполнить поля:
- ИМЯ ПРИЛОЖЕНИЯ - это имя будет доступно для перехода в основном меню всех приложений платформы (см. в полоске меню «
...») - ID - код приложения, внутреннее имя внешней системы, используется в топике подписки mqtt.
- url - ссылка перехода на внешнее приложение
¶ 6.2.2. Удаление редактирование Внешней системы
Операции редактирования и удаления записи Внешней системы не требуют пояснений. Отметим, что эти операции доступны только для Суперпользователя.
¶ 6.3. Настройка web-hook для отправки событий
Отправка событий во внешние системы по технологии web-hook требует применения соответствующего модуля интеграции (Inspark.Integration)
Настройка конкретных модулей интеграции см. в соответствующем разделе модули интеграции
Для отправки событий по web-hook следует выполнить следующие шаги:
- Авторизоваться в системе ролью не ниже
Configuration Mng(CA или SA или root). - Зайти в справочник событий на форме события.
- Отметить на форме чек бокс
Экспорт - По кнопке
Выберите внешние системы для экспортаотметьте те внешние системы, которым будут отсылаться это событие.
¶ 6.4. Настройка подписки на брокер MQTT, AMQP
Настройка подписки на брокер см. в соответствующем разделе Руководство по настройке подписки на брокер
¶ 6.5 Общая информация по сертификатам
Есть как бы три таких вот группы по ответственностям: админ 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