Подсистема интеграции

Подсистема создана для оптимизации процесса разработки новых интеграций.

Основные задачи и возможности:

• Берет на себя инфраструктурный слой по формированию, отправке и получению сообщений.
• Контролирет входящие и исходящие потоки данных.
  • Проверка соблюдения контрактов при приеме и формировании сообщений
  • Мониторинг состаяния подсистемы при помощи Prometheus
• Базовая многопоточность из коробки. Формирование и отправка сообщений в несколько потоков
• Минимальное вмешательство в код основной конфигурации для внедрения
• Произвольные обработчики

Оглавление:

Внедрение и первоначальная настройка

Потоки данных

Подписчики

Каждый исходящий поток может обладать несколькими подписчиками. Подписчики - это системы которые получают сообщения из потока.

Для каждого подписчика могуть быть заданы свои правила сериализации и валидации сообщений.

На данный момент реализованы следующие типы подписчиков:

• Произвольный http-подписчик.
• Подсистема интеграции. Такая же подсистема интегрированная в другой информационной базе.
• RabbitMQ. Подписчик, который отправляет сообщения в очередь RabbitMQ.
• Jrpc 2.0. Подписчик, который отправляет сообщения по протоколу Jrpc 2.0.

Пост-Обработка ответов

Для каждого подписчика можно задать обработчик ответов. Обработчик ответов - это произвольный обработчик, который будет вызван после отправки сообщения. В обработчик будет передан ответ от подписчика, а так же ссылка на исходные данные сообщения.

Валидаиция

В подсистеме реализован механизм валидации сообщений при приеме и отправке. Валидация происходит на основе контрактов, которые описывают структуру сообщения. Формат описания контрактов - OpenAPI 3.0.0

Для хранение данных схем реализован справочник инт_Схемы. В нем хранится информация о схеме, и сама схема в формате JSON. Так же реализовано кэширование схем размещенных в удаленных источниках.

Мониторинг

Основные метрики собираются при помощи Prometheus. Для сбора метрик реализован сервис http://example.com/integration_subsystem/hs/prometheus/polling, который возвращает данные в формате prometheus.

Метрики

• pde_queue_length - количество сообщений в очереди. Считается для каждой очереди в отдельности.

Примеры использования

Добавление нового потока

Создание исходящего потока

1. Создайте новый предопределенный элемент справочника "инт_ПотокиДанных"
2. Определите моменты триггера для отправки сообщений
3. Добавьте в момент триггера событие регистрации сообщения в очереди отправки(см. функцию ЗарегистрироватьСообщение в модуле менеджера очереди исходящих сообщений.)
4. Заполните в режиме предприятия направление потока(Исходящий) и текст обработчика.
5. Добавьте в ТЧ подписчики получателя ваших сообщений.

Планы на будущее

• [ ] Добавить возможность приема сообщений в несколько потоков
• [ ] Добавить поддержку протокола JRPC
• [ ] Добавить поддержку протокола AMQP и rabbitMQ
• [ ] Добавить версионирование обработчиков потоков в GIT
• [ ] Добавить поддержку asyncapi для описания контрактов и добавить валидацию не только пэйлоада, но и метаданных
• [x] Добавить поддержку внешних систем мониторинга
• [ ] Добавить динамические подписки на события по потокам
• [ ] Добавить синтаксическую подсказку по полям требуемых объектов на основании схемы контракта

Разработчикам

Информация для разработчиков подсистемы доступна по ссылке CONTRIBUTING.md

Лицензия