Интеграция без боли. Кейсы и лайфхаки больших проектов

Хочу рассказать:

• об опыте переходов с исторических систем на 1C:ERP;

• о подходах к интеграции НСИ;

• о разделении труда на проектах интеграции между аналитиками, разработчиками и архитекторами;

• затронем тему инструментов аналитика при работе на проектах интеграции;

• и расскажу про опыт использования сервисной шины интеграции 1С:Шина.

Опыт переходов с исторических систем

Последние несколько лет мы активно занимаемся переходами на ERP и ERP Управление Холдингом:

• было несколько проектов по переходу с УПП на ERP;

• несколько проектов по интеграции ERP с различными инженерными системами типа СПРУТ и Компас;

• переходы на ERP УХ с исторических систем;

• и интеграции попроще, вроде слива в ERP данных из 20 ЗУП-ов, объединения УТ с Розницей и подобные.

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

Успех на проектах интеграции обеспечивают три ключевых фактора:

• Кадры и управление решают все – однако это необходимое, но недостаточное условие.

• Второй момент – технические решения.

  • Простые грамотные решения могут компенсировать нехватку компетенций.

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

  • Есть поговорка: «Хорошее решение проблемы – когда оно попутно решает и другие вопросы. Плохое решение проблемы – когда решение одного вопроса порождает другие вопросы».

• Третий фактор успеха: инструменты и методики. Можно обойтись и без них, но с ними получается быстрее и удобнее.

Подходы к проектированию интеграций

Как правило, проектирование интеграций происходит в три этапа:

• Сначала мы что-то рисуем на бумаге.

• Потом проектируем структуру нужных объектов в СППР или Business Studio.

• И дальше уже прототипируем, как они должны выглядеть, в конфигураторе 1С или в EDT.

Но я предпочитаю делать наоборот – начать с конца:

• сразу в конфигураторе создать нужные объекты;

• загрузить их в СППР;

• и уже из этого распечатать готовую документацию – при таком подходе документация генерируется, а не пишется.

Дальше о своем подходе расскажу подробнее.

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

• Если требуется интеграция с системой, которая написана не на 1С, мы придерживаемся принципа «Не навреди» или «Работает – не трогай!». Сохраняем существующий в этой системе адаптер без изменений, и дорабатываем только ту часть, которая отвечает за его связь с нашей базой. Не нужно переписывать старые системы, которые исправно работают много лет – это вредно и, как правило, плохо заканчивается.

• А при интеграции с системами 1С часто возникает ситуация, когда, казалось бы, нужно связать всего три конфигурации, 5-10 баз, но для этого используются десятки обработок, написанных в разное время разными людьми. Данные передаются разными способами: где-то через COM, где-то через веб-сервисы. Нет единого подхода, формата, порядок внесения изменений не определен, документации нет, либо она не сильно помогает. В этом случае, как правило, все наработки сразу отправляются в корзину и правила пишутся с нуля на «Конвертации данных» – получается дешевле, быстрее, надежнее и проще для дальнейшей поддержки.

Мифы о Конвертации Данных 2

Про «Конвертацию данных» второй редакции ходит много мифов. Сейчас я вам их попытаюсь развеять:

• Первое, о чём обычно говорят – медленно работает.

  • На самом деле мы делали замеры, скорость «Конвертации данных» второй редакции на 20-30% выше, чем аналогичные типовые обмены на EnterpriseData.

  • В отличие от EnterpriseData, формат КД2 прекрасно распараллеливается. У нас был проект, где мы пробовали распараллелить EnterpriseData (это описано в статье Дмитрия Иванова на Инфостарте), но должных результатов это не дало, поскольку EnterpriseData не предназначена для параллельной работы. Сама идея EnterpriseData хорошая, рабочая, но текущая реализация оставляет желать лучшего. А на КД2 у нас есть успешный опыт настройки многопоточности на нашей шине – мы в многопоточном режиме запускали 25 обменов для проекта в новосибирском филиале «ГазпромНефти». Система справлялась с ускорением 3-5 потоков (дальше возникали блокировки). Замеры показали, что 3-5 потоков дают ускорение в 2,7 раза.

  • Почему еще говорят медленно? Программисты любят отягощать загрузку данных различными тяжелыми обработками – вместе с обменом идет проведение документов, дозаполнение, дополнительно генерируются записи в регистры. Часто заказчики, глядя на это, не понимают, на что уходит всё потраченное время. Здесь нужно разделять «мух от котлет» – если мы замерим чистое время загрузки и сопоставим его с временем проведения, окажется, что у нас обмен длится 30-40% времени, а 60% – это проведение документов.

• Второй миф: считается, что КД2 не поддерживает «Событийную интеграцию». В действительности поддерживает, вопрос только в кэшировании правил. Загрузка правил конвертации выполняется достаточно долго, например, правила для ERP грузятся несколько секунд, а событийная интеграция – это когда мы по одному объекту отправляем, это миллисекунды. Мы замеряли, КД2 один объект передает за 100 миллисекунд. Если чистое время штатной платформенной сериализации составляет ориентировочно 10 миллисекунд, то с использованием правил обмена – 100 миллисекунд на объект.

Еще один миф – КД2 ориентирована на обмен типа «точка-точка». Это тоже не так.

• Сообщения в формате КД2 переданные в шину, могут быть маршрутизированы для множества получателей с такой же конфигурацией. Пример:

  • База CRM выгружает ДоговорКонтрагента в Шину,

  • В Шине, в зависимости от Организации, указанной в договоре, пакет маршрутизируется по конкретную базу, где ведется эта организация.

• Так же весьма популярна схема «Отправитель <-> MDM <-> Получатель», где:

  • система MDM выступает в роли центра – получается классическая звезда, количество связей минимизировано;

  • все обмены между MDM и системами пишутся на КД2;

  • MDM выступает в роли «канонического формата».

• На Инфостарте есть кейсы по использованию КД2 в связке с RabbitMQ – в частности, доклад Сергея Сорокина.

Преимущества использования «1С:Конвертации данных 2»

• При разработке и изменениях правил обмена не требуется вносить изменения в конфигурации, единственное, что нужно – это доступность обработки УниверсальныйОбменДаннымиXML, которая может быть даже внешней.

• Отладка и разработка правил обмена выполняется независимо от транспорта (Шины) – вы можете менять Шины, у вас разделены прикладная логика и транспортная.

• Нет завязок на версии БСП.

• Надежность. В 2023 году обработке УниверсальныйОбменДаннымиXML исполнилось 20 лет.

• Большой выбор инструментов по объединению, сравнению правил и т.д.

Модели интеграции НСИ

10 лет назад считалось, что при работе с НСИ обязательно должна использоваться централизованная модель – должен быть единый центр НСИ, система MDM.

Сейчас больше склоняются к смешанной системе.

Что касается централизованной модели, то:

• Совершенно не обязательно покупать специализированное решение класса MDM, достаточно выделить в качестве MDM-системы конкретную базу – как правило, это основная рабочая база – и на нее замкнуть ведение НСИ. Более того, в ERP Управления Холдингом уже есть блок согласования заявок на изменение НСИ, а это практически все, что нужно от MDM-системы. Остальные задачи решаются Шиной и правилами обмена.

• Также мы можем сделать чистую копию рабочей базы и использовать ее только для справочников – такой подход мы в свое время применяли в X5 Retail Group, когда «Пятёрочка» сливалась с «Перекрестком», все отлично работает,

• Третий вариант – это «эталонные» метаданные НСИ:

  • Мы собираем поля бизнес-объектов из разных систем и пробуем их объединить в «эталонную» структуру 

  • Эту «эталонную» структуру удобно переместить либо в основную рабочую базу, либо держать в виде отдельной базы, либо сделать ее в виде подсистемы Шины.

Децентрализованная модель НСИ – это когда для каждого типа данных определяется своя мастер-система:

• В Бухгалтерии у вас отвечает за виды НСИ – поставщики, договоры, организации, статьи.

• В Управлении Торговлей – покупатели.

• В ЗУП – мастер-система по сотрудникам и структуре предприятия.

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

Разделение труда

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

• Технический архитектор:

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

  • Выбирает транспорт, настраивает сценарий в Шине, если она есть.

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

  • Кроме этого, архитектор проводит Code Review для правил или коннекторов, когда они готовы.

• Основной объем работ берут на себя аналитики. Сюда входит:

  • Вся работа с заказчиком по согласованию форматов. Существуют разночтения по пониманию слова «формат». Некоторые понимают под этим способ представления данных – такой, как XML, JSON, текстовые файлы или DBF. В нашем понимании, формат – это структура данных, набор взаимосвязанных именованных полей (поля шапки и поля табличных частей). Именно это мы понимаем под словом формат, вне зависимости от того, в каком виде эта структура данных будет представлена: в виде XML, JSON или CSV.

  • Далее аналитики делают мэппинг в «Конвертации данных». Для этого аналитикам не нужно разбираться с «Конвертацией», изучать, как там всё работает, писать код. Они делают только мэппинг полей для конкретных объектов, а также подробно описывают необходимые преобразования – где нужны условия или более сложные вещи.

  • Ещё одной функцией аналитика является постановка задач разработчику – ему передается мэппинг, а разработчик уже дорабатывает правила по постановке.

• Задачи разработчика:

  • По ТЗ и мэппингу от аналитика сделать финальные правила, протестировать их и передать на приемку.

  • Для более сложных случаев может потребоваться разработка коннекторов – в этом случае разработчик будет опираться на проектные решения от архитектора.

Инструменты аналитика

Для проектирования обменов аналитику требуется владеть рядом инструментов:

• Конфигуратор 1С. Да, мы считаем, что аналитики должны иметь базовые знания по объектам 1С и не бояться конфигуратора.

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

• Пустая база 1С. Очень важная вещь для моделирования форматов обмена с любыми системами

  • Для большинства проектов – это откровение: «А чё, так можно было?»

  • Берется пустая чистая база, в нее запускаются аналитики. Если аналитиков много, то делается хранилище – работе с хранилищем можно обучить за 5-10 минут. Достаточно освоить три команды – захватить объект, поместить и откатить. Этого не нужно бояться.

  • В конфигураторе чистой базы 1С аналитик создает объекты метаданных, соответствующие нужной структуре данных – перечня полей, предварительно подготовленного в Excel или вообще в .doc.

  • После того как структура в конфигураторе сформирована, дальше это грузится в «Конвертацию», чтобы составить мэппинг с реальными объектами базы 1С, с которой происходит интеграция. В результате интеграция SAP с 1С решается просто на «Конвертации данных».

• Конвертация данных – это основной инструмент аналитика в части любых интеграций.

  • Здесь необходимы минимальные знания, без написания кода – только мэппинг.

  • Также нужно понимать основные параметры. В частности, реквизиты поиска – для каждого объекта мы можем указать, как его искать: по коду, по наименованию, по ИНН, по трем полям. Здесь важно не перебарщивать, потому что если поиск настроен по неправильным полям и без индексирования, обмен может работать очень долго. Основные тормоза загрузок – это неправильная расстановка полей поиска.

  • Еще аналитику необходимо понимать, на что влияют такие опции, как: «Не создавать новые при загрузке», «Не замещать, если объект найден» и некоторые другие.

• Также для аналитиков будет полезен пакет «Инструменты разработчика» или Infostart Toolkit.

  • Прежде всего, здесь нужен «Универсальный редактор объекта» – он позволяет просматривать весь реквизитный состав любого документа или справочника со значениями. Когда вы работаете с формой, не всегда очевидно, какие данные в ней присутствуют, откуда они берутся, какие хранятся непосредственно в этом объекте, а что подтягивается из регистров. Редактор позволяет увидеть всю структуру данных объекта в наглядном и понятном формате.

  • Аналогичные возможности дает динамический список – это то же самое, что и «Редактор объектов», только в виде таблицы. Можно просмотреть структуру объекта не в том виде, в котором его нам показывает типовое решение, а все поля без исключения с возможностью проанализировать состав колонок и так далее.

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

  • А для ведущих аналитиков высшим пилотажем уже будет владение «Консолью запроса», «Консолью СКД» и написанием несложного кода в «Консоли кода».

Вот так выглядит в конфигураторе пустой базы создание структуры метаданных для обмена с SAP – созданная структура выгружается в «Конвертацию данных» и формируется мэппинг этих объектов с объектами целевой конфигурации.

Задачи аналитика при работе с интеграциями

Еще раз пробежимся по задачам аналитика в проектах по интеграции:

• В первую очередь, это сбор форматов передаваемых данных – в любом виде. Чаще всего заказчики предоставляют информацию о структуре данных в Excel, но иногда умудряются давать в Word или в текстовом виде:

  • Мы анализируем, ЧТО система-источник может передавать – запрашиваем у заказчика тестовую выгрузку из системы, чтобы увидеть, какие данные доступны и в каком виде они передаются.

  • Кроме этого, зная, какие данные нам нужно получать, мы моделируем, КАК эти данные лягут в систему-приемник – отталкиваемся от того, как будто они там уже есть. Для лучшего понимания логики интеграции я всегда советую аналитикам завести данные руками, как будто они переданы из другой системы, и отталкиваться от этого.

• Моделирование сквозных бизнес-процессов во всех интегрируемых системах. Например, чтобы смоделировать, как документ должен автоматически перейти из системы-источника в систему-приемника, аналитик должен руками набить этот документ в одной системе, а потом руками набить этот же документ в другой системе – определиться, в каком виде будет формироваться вход и выход.

• Если интегрируемся с системой не на 1С, требуется фиксация форматов в конфигураторе чистой базы, про которую я говорил – набиваем шаблоны объектов обмена.

• Далее выполняем черновой мэппинг в «Конвертации данных». Мэппинг черновой, потому что аналитик не кодит, он только сопоставляет, пишет условия, описание, результат.

• Следующий этап – это выдача задачи разработчику, который уже доводит правила до ума. Получается, что мы делаем две версии правил – первую версию правил в «Конвертации» делает аналитик, а разработчик копирует ее и делает свою версию уже с кодом.

Шины интеграции ESB

Про шины я рассказываю на Инфостарте уже 10 лет – первый доклад был на конференции INFOSTART EVENT EVOLUTION в 2013 году.

Первая шина, с которой мне довелось работать еще в 2000 году – MS BizTalk Server. Это был совместный проект Microsoft, 1С, Intel и площадки Price.Ru, направленный на создание стандарта обмена коммерческой информацией. В результате появился CommerсeML, а затем и его вторая редакция, автором которой стал я.

Быстрее всех потенциал формата CommerсeML увидела компания Битрикс – за счет этого они как раз и смогли вырасти. Они первыми осознали преимущества CommerсeML и интегрировали его в свои интернет-магазины – связали их с 1С:Торговлей и Склад 7.7, а потом с первой версией 1С:Управления Торговлей 8.

Преимущества использования ESB 1С:Шина

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

По сути, это конструктор, потому что установить 1С:Шину с нуля и сразу запустить обмен не получится – готовых решений пока нет, каждый обмен настраивается в 1С:Шине отдельно.

Однако мы работаем над универсализацией и уже создали прототип универсального коннектора к 1С:Шине. Это расширение, которое можно добавить в любую конфигурацию, чтобы обеспечить передачу в 1С:Шину данных в различных форматах – в формате КД2 и через штатную сериализацию объектов XML или JSON. 1С:Шине неважно, как в нее переданы данные – она поддерживает любой формат.

Технические лайфхаки

Пара технических лайфхаков.

• Планы обмена – один из самых недооцененных объектов в 1С. Его название сбивает с толку, потому что на самом деле он не только про обмен.

  • Более точное название для него – «план регистрации изменений данных», потому что с помощью планов обмена можно регистрировать изменения по заранее определенному составу объектов, и это позволяет решать большое количество задач, не связанных с обменом.

  • Мы часто используем планы обмена для того, чтобы выполнять отложенные действия с объектами в рамках одной базы – регистрируем в плане обмена какие-то документы, а затем через отдельное регламентное задание выполняем с ними нужные действия. При этом совершенно необязательно эти документы куда-то передавать – можно внутри одной базы преобразовать один документ в другой. Например, приходную накладную преобразовать в расходную. Или собрать все объекты, которые зарегистрировались на узле, и объединить в один документ.

• Еще один полезный прием – копирование метаданных между разными конфигурациями.

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

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

  • Таким образом сохраняется структура, имена. Ссылки при этом, как вы знаете, слетают, заменяются на тип «Строка, 10», но это легко исправляется – достаточно вручную поменять этот тип на тот, который в конфигурации-приемнике. В результате исходная структура данных сохраняется, а мэппинг требуется только для полей ссылочных типов.

Вопросы и ответы

Почему вы так хвалили 1С:Шину, если у вас есть своя разработка?

Мы планируем сделать симбиоз: хотим использовать 1С:Шину как идеальный брокер сообщений, а 2iS уже будет выполнять роль обвязки в виде Enterprise Services.

Важно понимать, что 1С:Шина реализована на новой технологической платформе 1С:Предприятие.Элемент, фактически это уже 1С:Предприятие 9.0, т.е. все дальнейшее развитие платформы 1С будет там. Поэтому мы тоже считаем правильным развиваться в эту сторону.

Вы упомянули, что в некоторых случаях централизованная НСИ – это даже вредно. Можете привести практический пример, когда это действительно вреднее, чем децентрализованная НСИ?

Допустим, у нас есть ЗУП, и все регламенты в компании прописаны под работу в этой системе. Есть процедура кадрового учета, как заводить сотрудника. Более того, сделана интеграция ЗУП с Active Directory: как только человек выходит на работу, и администраторы настраивают для него учетную запись в AD, это все сразу же отображается в ЗУП. И как только на него заведены все кадровые документы по приему на работу, он появляется как сотрудник и после этого передается в другие системы, фигурируя там как физ. лицо.

Если бы мы попытались централизизовать НСИ и выстроить все эти процедуры в какой-нибудь MDM-системе, нам пришлось бы заново воспроизводить в ней кусок ЗУП. А зачем это делать, когда для этого уже есть специализированное решение?

То же самое с 1С:ДО – если у нас конфигурация, где ведется учет договоров с многоступенчатой процедурой для их согласования, нам неудобно повторять эту всю процедуру в системе MDM.

Это вредно с точки зрения трудозатрат и результата. Если у нас есть в какой-то системе готовые процедуры, зачем нам их переносить в MDM или делать лишнюю передачу.

Вы показывали скриншот со структурой метаданных системы SAP, для которой в последующем формируются правила конвертации в КД2. Каковы последующие шаги? Как эти правила используются для выгрузки данных из 1С в SAP?

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

Единственное отличие: в конфигураторе используются красивые русские имена, удобные для мэппинга, и нет этих закорючек SAPовских. На самом деле они есть, но сидят в поле «Синоним». То есть просто это объекты-посредники, скажем так, транспортные.

Вы сказали, что 1С:Шина вам нравится больше, чем тот же RabbitMQ. А это в случае, если мы интегрируем именно 1С-овские системы? Или в случае, если у нас 1С-овских систем 20%, то все равно 1С:Шина лучше?

Сейчас у 1С:Шины возможностей и гибкости больше, чем у того же RabbitMQ. Даже визуальный интерфейс, где рисуется графическая схема, выглядит более современно по сравнению с RabbitMQ. Обмен настраивается нагляднее.

Более того, с выходом каждой новой версии в 1С:Шине увеличивается количество доступных для схемы узлов, каждый из которых решает свою задачу:

• Например, есть узел «маршрутизатор»: его задача преобразовывать один формат в другой.

• Из коробки поддерживается узел с адаптером для того же RabbitMQ.

• Есть узел для файловых каталогов – можно просто добавить на схему узел, указать, из какого каталога забирать файлы, а 1С:Шина сама их заберет и что-то с ними дальше сделает, куда-то их дальше по схеме передаст.

• Данные можно передавать как есть, в бинарном виде, либо можно их внутри 1С:Шины разобрать и преобразовать.

Насколько быстро можно научить специалиста, который даже «Конвертацию» не знает, тому, чтобы он сделал интеграцию через 1С:Шину и «Конвертацию»?

«Конвертация данных» и 1С:Шина – все-таки разные вещи.

«Конвертация» хороша тем, что ее знает большинство программистов, она существует уже 20 лет, и ее знание входит в базовые требования к компетенциям 1С-разработчиков

А с 1С Шиной сложнее. У нее выше порог вхождения, потому что там используется свой язык, 1С:Исполнитель – это развитие языка 1С. Он строго типизированный, у него короче синтаксис, он более упрощен. В этом плане порог вхождения довольно высок, простому программисту будет сложнее, он будет с этим возиться больше времени, чем просто сделать обмен на «Конвертации данных».

Здесь надо исходить от задачи.

• Если обменов много или нужен быстрый обмен, то лучше подойдет 1С:Шина.

• Если обменов меньше десятка, то их можно сделать без 1С:Шины, просто на правилах «Конвертации данных».

• Либо можно использовать 2iS:Интеграцию, нашу шину, которая из коробки поддерживает КД2, тогда разработчику не нужно ни с чем дополнительно разбираться. Если у вас есть правила «Конвертации данных», вы покупаете шину 2iS:Интеграция, загружаете в нее правила, указываете систему источник, систему приемник, и из коробки запускается обмен. При этом даже в сами конфигурации не нужно вносить изменения – достаточно, чтобы там был план обмена, который вам нужен. И это одно из преимуществ, которое подкупает клиента при выборе шины – поддержка КД2 «из коробки» и нет необходимости вносить изменения в конфигурации 1С. Разве что иногда лучше добавить новый план обмена, это удобнее, чем использовать полный план обмена или неподходящий.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.