Упорядочили почти 200 интеграционных потоков для работы крупного девелопера: схема «звезда» на базе DATAREON Platform

На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Расскажу, как мы перенесли 197 интеграционных потоков крупного девелопера на DATAREON Platform без остановки рабочих систем — и почему за задачей «перенести работающие обмены» скрывалась ревизия дублирующегося кода, забытых механизмов синхронизации и накопленной бизнес-логики.

Заказчик: девелопер федерального уровня. 

Задачи:

• Централизовать обмен между многочисленными базами 1С, чтобы снизить нагрузку на системы, и уйти от логики интеграций «точка-точка».

• Упростить сопровождение и доработки интеграций.

• Повысить управляемость и прозрачность интеграционного ландшафта.

О компании: комплексно развивает территории в центральной России: строит жилые кварталы, детские сады, школы, поликлиники, спортивные и коммерческие объекты. Это надежный застройщик федерального уровня. 

С чем обратился заказчик

У клиента было большое количество баз 1С: ERP, БИТ.Строительство и другие конфигурации. Обмен между ними шел через RabbitMQ, формально брокер сообщений в ландшафте был, но по сути интеграция оставалась схемой «точка-точка»: каждая система сама формировала отдельное сообщение для каждого конечного получателя и знала обо всех своих адресатах. Брокер только доставлял сообщения, а вся логика маршрутизации и подготовки данных жила внутри баз.

Хуже того, выгрузка для баз с идентичной конфигурацией была реализована в отдельных процедурах: один и тот же объект для нескольких одинаковых баз формировали разные участки кода. Это приводило к колоссальному дублированию кода и усложняло поддержку. Любая доработка одного потока требовала изменений сразу в нескольких местах, риски ошибок росли, а сопровождение становилось неоправдано дорогим.

Клиенту требовалось не точечное улучшение, а системное решение. Мы предложили перейти к архитектуре «звезда» с DATAREON Platform в центре: логику маршрутизации и трансформации вынести в единый управляемый контур, чтобы каждая система взаимодействовала только с шиной и ничего не знала о своих получателях.

Проект включал реализацию 197 интеграционных потоков с различной бизнес-логикой и форматами данных. Срок 3-4 месяца, при этом системы продолжали работать без остановки и обмен нельзя было прерывать.

Что сделали

Провели ревизию существующих интеграций.

По условиям контракта отдельного аналитического этапа в проекте не было: предполагалось, что мы переносим уже работающие обмены на новый инструмент. Реальная архитектура с дублирующимися процедурами стала для нашей команды большим сюрпризом, поэтому разбор пришлось встраивать в ход проекта.

Начали с изучения тел сообщений, которые уходили в разные базы. Быстро выяснилось, что сообщения для одинаковых конфигураций отличаются по составу и структуре, и никто на стороне заказчика не мог объяснить, почему так сложилось. Пришлось тратить время на разборы: как все-таки должно быть правильно, какие расхождения являются осознанной бизнес-логикой, а какие накопились случайно. Задача «перенести интеграцию на другой инструмент» превратилась в большую ревизию существующих интеграций.

Параллельно фиксировали фактическую картину: какие базы участвуют во взаимодействии, какие потоки реализованы, где дублируется логика, какие данные критичны для операционной деятельности, какие интеграции работают под высокой нагрузкой, где есть исторические доработки и нестандартная логика. На основе этого сформировали целевую архитектуру и поэтапный план переноса потоков, чтобы не останавливать рабочие процессы компании.

Автоматизировали разбор интеграционного кода.

Чтобы не тратить дорогое время разработчиков и аналитиков на ручное хождение по конфигураторам, написали парсер на Python. Он выгружал модули исходников конфигураций, связанные с обменом. Помогло то, что интеграция с RabbitMQ во всех базах была реализована по единой архитектуре: расширения имели общую структуру и набор типовых модулей, а специфика каждой конфигурации была вынесена в отдельные частные модули. Благодаря этому расположение и назначение нужного кода были достаточно предсказуемыми для автоматического разбора.

Выгруженный интеграционный код собрали в документацию на MkDocs и разместили на внутреннем портале. В результате аналитик или разработячик мог, не открывая конфигураторы, быстро пройтись по всем процедурам, связанным с конкретным выгружаемым или загружаемым объектом, и сравнить, как один и тот же объект обрабатывается в разных базах.

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

Запустили обмен серией контролируемых переключений.

Поскольку переход шел поэтапно, DATAREON и старые механизмы обмена какое-то время работали одновременно. Уже на первых потоках поймали дублирование контактной информации физических лиц. Причина оказалась в одновременной работе двух механизмов: старого обмена через RabbitMQ и типовой синхронизации 1С. По всей видимости, при переходе с типовой синхронизации 1С на обмен через RabbitMQ типовой механизм не отключили. В результате оба обмена годами работали параллельно и фактически дважды передавали одни и те же данные.

Отдельная сложность возникла из-за отсутствия актуального описания существующей схемы обмена. В ряде случаев объект, поступивший в принимающую базу через DATAREON, после записи автоматически регистрировался к отправке уже типовым механизмом обмена 1С. Это создавало риск зацикливания: данные могли уйти обратно в исходную систему, снова попасть в интеграционный контур и начать циркулировать между базами. Такие зависимости приходилось выявлять уже в процессе перевода конкретных потоков.

Перед миграцией мы сразу предусмотрели порядок отката на старый механизм, и это себя оправдало. После переключения команда следила за архивом сообщений DATAREON и поведением систем-получателей. Если возникала существенная проблема, отдельные потоки возвращались на старую механику, устранялась причина, проводилось повторное тестирование и предпринималась новая попытка перехода.

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

Решили вопрос с «пропущенными» сообщениями.

После первых переносов выяснилась еще одна эксплуатационная особенность. В старой системе часть сообщений считалась пропущенными по бизнес-логике: например, данные связанные с физлицом не передавались, если связанного физического лица не должно было быть в принимающей базе. При этом нужно было сохранить возможность анализировать такие неотправленные сообщения. Решили отправлять их в архив DATAREON.

Заказчик запросил хранение таких сообщений в течение 30 дней, и оказалось, что их очень много. Никто ранее не хранил такие объемы в архиве DATAREON, и у продукта начались технические проблемы. Спасибо поддержке вендора, быстро разобрали инцидент и прислали патч, после чего проект пошел дальше.

Построили мониторинг под службу сопровождения.

По мере роста числа перенесенных потоков возник следующий вопрос: как всем этим пользоваться службе сопровождения? Нужно было отвечать на прикладной вопрос: «Что произошло вот с этим договором, физическим лицом или банковским счетом?». Сервиса аналитики DATAREON на тот момент еще не было, а стандартных средств центра мониторинга для этого не хватало.

Сначала мы построили централизованную систему сбора логов на стеке Loki + Grafana. Но у Grafana есть порог входа для тех, кто с ней не знаком, и команда сопровождения 1С отказалась ей пользоваться. Для них мы сделали отдельную обработку мониторинга DATAREON прямо в привычном интерфейсе 1С, она взаимодействовала с логами в Loki, центром мониторинга DATAREON и с базой 1С. Из нее специалист может просматривать сообщения, переходить к объекту 1С по типу данных и идентификатору либо MDM-ключу, смотреть связанные события журнала регистрации за время обработки сообщения и анализировать отмененные сообщения.

Таким образом, к концу проекта речь шла уже не просто о внедрении интеграционной платформы: вокруг нее сформировался полноценный эксплуатационный инструментарий.

Автоматизировали подготовку документации.

В конце проекта стояла задача задокументировать все 197 потоков. Здесь нас снова выручил Python. DATAREON хранит весь интеграционный код и настройки внутри своей конфигурации, а конфигурация лежит в Git. Поэтому ее можно взять из репозитория, распарсить и получить все настройки маршрутов, трансформаций и подключений в структурированном виде.

Мы заранее заложили это в процесс разработки: комментарии, отражающие особенности реализации, разработчики помечали тройным слэшем «///». Парсер собирал такие комментарии и вставлял их в документацию рядом с соответствующими настройками.

В итоге около 80% документации мы получили напрямую из конфигурации DATAREON. Это документация, которая точно соответствует тому, что работает в продуктиве, а не тому, что помнят разработчики: достоверная, актуальная, с перекрестными ссылками между потоками, объектами и правилами. Вручную писали только концептуальную часть и описание эксплуатационных процедур.

Передали компетенцию заказчику.

Требование передать знания внутренней команде стояло с самого начала. 197 потоков были только первой очередью: общее количество потоков в ландшафте оценивалось в 600-800. Делать такой объем силами подрядчика очень дорого, поэтому единственный разумный путь для заказчика: развивать собственную компетенцию по платформе.

Договорились так: на все время проекта заказчик выделяет своего разработчика, и он работает у нас как удаленный сотрудник. Ходит на внутренние проектные встречи, коммитит в наш Git, пользуется нашими внутренними инструментами и наработками и выполняет задачи, которые ему ставит наш ведущий разработчик. То есть не «сидит рядом и смотрит», а делает реальные потоки по нашей проектной технологии.

Здесь нам повезло: специалиста выделили сильного, и получилась настоящая win-win синергия. Он получил от нас экспертизу по интеграционному продукту, инструменты, подходы и проектную технологию. Мы получили опытного разработчика, который знает интегрируемые системы изнутри. А если какую-то систему он не знал, то знал, к кому обратиться и как найти концы. В крупной компании это отдельная непростая задача, и наличие «своего» человека внутри заметно экономило время на согласованиях и поиске ответственных.

В результате заказчик получил не просто обученного администратора, а разработчика, который прошел вместе с нами весь цикл: от ревизии старых обменов до промышленного запуска и мониторинга. Компания снизила зависимость от внешнего подрядчика и готова развивать интеграционный контур своими силами.

Результат:

• Интеграции перевели со схемы «точка-точка» на централизованную архитектуру. Каждая система работает через шину и ничего не знает о своих получателях.

• Нагрузка на базы 1С снизилась: вместо множества параллельных выгрузок данные отправляются один раз, а дальше шина распределяет их по нужным системам.

• Изменения больше не требуют правок в нескольких местах. Логику обмена можно корректировать централизованно, без лишних рисков.

• Убрали дублирование кода и бизнес-правил. Поддержка стала проще и предсказуемее.

• Появился прозрачный мониторинг на двух уровнях: Loki + Grafana для инженеров и обработка в 1С для службы сопровождения. Аналитики видят статусы потоков, ошибки и очереди в режиме реального времени и могут отследить судьбу конкретного объекта. Если возникает инцидент, его можно быстро локализовать и устранить.

• Запуск новых интеграций занимает меньше времени, так как есть единая архитектура и отработанные механизмы.

• На все потоки есть достоверная документация, сгенерированная из конфигурации DATAREON, а значит, не расходящаяся с тем, что работает в продуктиве.

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

Этот проект показал, что интеграционная архитектура напрямую влияет на устойчивость бизнеса. Когда обмены строятся по принципу «быстро подключили и работает», рано или поздно система упирается в предел по масштабируемости: количество связей растет, сложность увеличивается, поддержка начинает стоить дороже развития. И наличие брокера сообщений само по себе от этого не спасает, если логика маршрутизации остается внутри каждой системы. Теперь подключение новых систем или изменение логики обмена не отдельный проект с непредсказуемыми последствиями, а рабочий процесс в рамках единой платформы.