До внедрения сервера сообщений:
Для обмена между разными конфигурациями в арсенале 1С ников есть:
• КД 2
• КД 3 (если там БСП или ручное внедрение этой части + напильник)

Для обмена между 1С и не 1С ничего типового нет. Выбор разнообразен:
• Обмен через произвольные файлы. Транспорт разнообразен: фтп, сетевая шара, бакет на s3 и т.п.
• Общение по HTTP с определенным API

Чем это все плохо?
• Большой зоопарк решений, нет общего архитектурного решения. Нет прозрачности.


После внедрения коннектора:

Для обмена между разными конфигурациями используется обмен в XML через схему данных. (А лучше бы конечно JSON у нас реализовать).
Для обмена с внешними системами произвольный формат.
Транспорт через Kafka платформ (брокеры, схем регистри, контрл центр и т.п.).


Что даст внедрение сервера сообщений?
• Стандартизация архитектуры обмена, тем самым снижение затрат при внедрение в поток новых данных
• Единая точка мониторинга
• Уменьшение трения при взаимодействии 1С и не 1С (экономия на ресурсах и времени)
• Обмен ~ в реальном времени (все зависит от передаваемых данных и сложности алгоритмов их трансформации)

• • Хранение истории обмена

До внедрения сервера сообщений:
Есть несколько способов реализовать такой обмен. Способы:
• РИБ
• КД 2 / КД 3
• Универсальная выгрузка / загрузка (с напильником)

Точка отказа:
• Обновления конфигурации в РИБ
• Изменение структуры данных в КД 2
• Изменение схемы КД 3
• Изменение конфигурации в принципе (Универсальная выгрузка / загрузка)


После внедрения коннектора:
Для каждого объекта метаданных формируется устойчивая схема обмена (из источника), при загрузки не распознанные реквизиты игнорируются (устойчиво к изменениям).
У схем есть версия, можно заранее готовиться к изменениям и реагировать на них в коде при "миграции".


Зачем внедрять коннектор:
• Снижение затрат на внедрение обмен
• Устойчивость к изменениям структуры метаданных
• Снижение затрат на сопровождение. Опсы смотрят в единую точку контроля и мониторинга.

До внедрения сервера сообщений:
Работа с журналом регистрации в 1С обычно тяжелая и длительная операция.
Для более оперативной работы с ним (а часто это не одна система 1С), требуется эти данные слить в какое-то озеро данных (в 1С нет озера данных с нормальным полнотекстовым поиском).


До внедрения сервера сообщений:
Подсистема умеет разбирать журнал регистрации 1С из 1С (не нужны внешние инструменты) и отправляет поток событий в кафка платформ.
Затем можно обращаться к кафка через ksql, события с ошибками обрабатывать в кафка
 и отправлять в sentry / v8error, общий поток событий отправлять в стек ELK для быстрого поиска (как раз то озеро данных, упомянутое выше).


Что даст сервер сообщений?
• Уменьшение нагрузки на приложение 1С
• Единая точка работы с журналом 1С (через кафка в ELK)
• Контроль работы приложений 1С (когда мы знаем о проблемах). Опсы будут рады, что они узнают о проблемах не от пользователей систем.

До внедрения сервера сообщений:
Для мониторинга метрик, например APDEX требуется либо самим пушить события на внешний сервис (например zabbix),
либо публиковать свой HTTP сервис для публикации метрик, например, для прометеуса. В итоге для отправки метрик в несколько мест нужно дублировать поток данных.


После внедрения коннектора:
Публикация метрик будет производиться в кафка (без дублирования данных). Затем из кафка их можно будет выгребсти:

• В доску BI (например powerBI) через кафка стрим
• Отправить метрики в ЭЛК (есть конннектор)
• Прометеус может забрать метрики из кафка через ksql
• В заббикс будет публиковаться поток данных.


Что даст сервер сообщений?
• Прозрачная архитектура и потоки данных (экономия на развитии)
• Нет разношерстных решений (экономия на развитии и сопровождении)
• Есть логирование потока данных (на сколько мы хотим его хранить для опсов)
• Снижение нагрузки на 1С (не надо дублировать и отправлять данные по несколько раз)