Интеграция MDM и ERP через шину DATAREON строится так: MDM — единый источник мастер-данных (номенклатура, контрагенты, организации), ERP на 1С и другие системы — их потребители, а интеграционная шина — транспорт между ними. Шина забирает изменения из MDM, преобразует их в формат каждой системы, гарантированно доставляет и показывает в мониторинге, что дошло, а что нет. Каждая система подключается к шине один раз, вместо отдельной интеграции с каждым соседом.
Ниже — какую роль шина играет в связке ERP, MDM и остальных систем, какие сценарии на ней строят и как подойти к проекту, чтобы он закончился работающими потоками, а не красивой схемой. Что такое DATAREON ESB в целом, я разбирал в статье о том, что такое DATAREON ESB.
Почему интеграции перестают управляться
Типичный ландшафт средней компании: ERP на 1С, MDM для справочников, CRM, система управления складом, ЗУП, сайт или маркетплейсы, иногда отраслевые решения. Системы появлялись в разное время, у разных подрядчиков, и каждая интеграция — отдельный проект со своими форматами и логикой.
При прямых связях число интеграций растёт быстрее числа систем: для n систем, где каждая связана с каждой, их n×(n−1)/2. Для 10 систем это 45 связей. На практике не все связаны со всеми, но тенденция та же: каждая новая система тянет за собой несколько новых обменов, а замена одной — переделку всех её связей.
Последствия знакомы любому ИТ-директору:
- справочники расходятся: один и тот же товар в ERP и на складе с разными характеристиками;
- при сбое неясно, где искать: логи в каждой системе свои;
- изменение формата в одной системе ломает несколько обменов сразу;
- импортозамещение превращается в цепочку переделок интеграций.
Роли в связке: ERP, MDM и шина
| Компонент | За что отвечает | За что не отвечает |
|---|---|---|
| MDM | Правила справочников, дедупликация, «золотая запись», согласование изменений | Доставка в системы, форматы получателей |
| Интеграционная шина | Маршрутизация, преобразование, гарантированная доставка, повторы, мониторинг | Бизнес-правила качества справочников |
| ERP (1С) | Учёт и операции на основе мастер-данных | Ведение справочников, если источник — MDM |
| CRM, склад, сайт | Свои процессы | То же |
Главная ошибка — смешивать роли. Если шина начинает «исправлять» справочники, а ERP параллельно продолжает их вести, единый источник истины пропадает.
Сценарии на шине
Распространение мастер-данных
Новый товар заводится и согласуется в MDM. Шина получает событие, преобразует карточку в формат каждой системы и отправляет в ERP, на склад, в CRM, на сайт. Если склад недоступен, сообщение ждёт в очереди и доставляется после восстановления. Каждая система подтверждает приём.
То же для контрагентов: изменение реквизитов в MDM расходится во все системы, где контрагент используется.
Обратный поток
Не все данные рождаются в MDM. Цена может формироваться в ERP и через шину уходить на сайт; клиент может обновить данные в CRM — тогда изменение проходит проверку в MDM и только затем распространяется дальше. Правило простое: для каждого атрибута один источник.
Оркестрация сквозных процессов
Пример — заказ клиента: заявка в CRM → при необходимости создание клиента в MDM → резервирование в ERP → задание на сборку складу → документы в учётной системе → уведомления клиенту. Шина координирует последовательность, обрабатывает ошибки и сообщает, на каком шаге процесс остановился.
Документооборот и внешние каналы
Обмен с СЭД, почтой, файловыми хранилищами и веб-сервисами тоже удобно вести через шину: одна точка контроля вместо разрозненных скриптов.
Что даёт централизованная схема
- Управляемость. Все потоки видны в одном мониторинге: объёмы, ошибки, задержки.
- Надёжность. Очереди с сохранением сообщений и повторная отправка — данные не теряются при недоступности получателя.
- Независимость систем. ERP не знает о формате CRM. Замена одной системы затрагивает только её подключение к шине.
- Скорость изменений. Новая система подключается к готовым потокам, а не интегрируется с каждым соседом.
Экономический эффект зависит от числа систем и текущего состояния интеграций. Для трёх систем с устоявшимся обменом шина избыточна; для десятка систем с регулярными сбоями — обычно оправдана. Расчёт делают после инвентаризации существующих обменов.
Как подключается 1С
Со стороны 1С варианты такие:
- Адаптер шины — устанавливается в конфигурацию без изменения её кода и обеспечивает отправку и получение сообщений.
- HTTP-сервисы и REST — когда нужна своя логика или нестандартный формат.
- Плановые выгрузки — для систем, где обмен в реальном времени не нужен.
Главное на стороне 1С — не транспорт, а дисциплина: ERP не должна позволять пользователям менять справочники, ведущиеся в MDM; объекты нужно искать по внешнему идентификатору, а не по наименованию; повторно пришедшее сообщение не должно создавать дубль.
План внедрения
| Этап | Содержание | Ориентир по срокам |
|---|---|---|
| Аудит и архитектура | Инвентаризация обменов, источники данных, целевая схема | Несколько недель |
| Инфраструктура | Установка шины, мониторинг, безопасность, резервное копирование | 2–3 недели |
| Пилот | Один показательный, но некритичный поток, параллельно со старым обменом | Несколько недель |
| Перевод потоков | Поэтапный перевод интеграций, отключение старых связей | Месяцы |
Факторы, от которых зависит успех, — больше организационные, чем технические:
- поддержка на уровне руководства: проект меняет ответственность за данные;
- назначенные владельцы справочников и потоков;
- регламент изменения интеграций — никаких «быстрых правок» в обход шины;
- обученные администраторы, которые умеют читать мониторинг.
Типичные ошибки
- Перенос хаоса на шину. Старые обмены переносят один в один, вместе с дублированием и противоречивыми источниками. Сначала договоритесь об источниках данных.
- Нет пилота. Переводят всё сразу — и при первом сбое не понятно, что сломалось.
- Нет владельца. Мониторинг есть, но ошибки никто не разбирает.
- Идентификаторы. Системы сопоставляют объекты по наименованиям — дубли гарантированы.
Как понять, что шина вам нужна
Короткий тест для ИТ-директора. Шина, скорее всего, оправдана, если:
- в ландшафте пять и больше систем, которые обмениваются справочниками или документами;
- есть или планируется MDM, и мастер-данные нужно доставлять в несколько систем;
- сбои обменов случаются регулярно, а их диагностика занимает часы;
- идёт импортозамещение, и системы будут меняться в ближайшие годы;
- обмены пишут разные подрядчики, и общей картины ни у кого нет.
И скорее не нужна, если:
- систем две-три и обмен между ними стабилен;
- все системы — конфигурации 1С, и типовой обмен через планы обмена закрывает задачи;
- нет ресурса сопровождать отдельную платформу: шина — это тоже система, которой нужен администратор.
Промежуточный вариант — начать с аккуратных точечных интеграций через API, но сразу проектировать их так, чтобы потом перевести на шину: единые идентификаторы, очереди, журнал обмена.
Шина не наводит порядок в данных сама по себе. Порядок наводит MDM и правила, а шина делает так, чтобы этот порядок одинаково доходил до каждой системы.
Проектирую и подключаю 1С к шинам данных в рамках услуги интеграционная шина для 1С, а точечные обмены делаю через API 1С.
Коротко
- Интеграция MDM и ERP через шину DATAREON разделяет роли: MDM — качество справочников, шина — доставка, ERP — учёт.
- Шина заменяет паутину прямых связей звездой: каждая система подключается один раз.
- Основные сценарии — распространение мастер-данных, обратные потоки, оркестрация сквозных процессов.
- Для каждого атрибута должен быть один источник, а объекты сопоставляются по внешним идентификаторам.
- Начинайте с аудита и пилота, затем переводите потоки поэтапно.
