Интеграция — слово давнее, в целом скорее понятное, но давайте уточним, что это значит в практическом плане. Если загуглить: веб-интеграция — это объединение разнородных веб-приложений и систем в единую среду на базе веб.

Почти любая популярная CMS (например, 1С-Битрикс), среди прочих функций обещает быстро и безболезненно синхронизировать базу 1С с новым сайтом. Кажется, что никому не придется вручную переносить гору товаров, остатки будут сами обновляться при каждом заказе, цены — моментально корректироваться, а заказы — автоматически улетать в CRM и обновляться в обратную сторону. Красивая картинка, но на практике всё разбивается о суровую реальность.

Интеграции из коробки, как правило, не хватает. ERP-системы — они же Enterprise Resource Planning, планирование ресурсов предприятия, — часто уже были дописаны какими-то программистами, а штатные протоколы не в состоянии обеспечить все хотелки клиента.

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

Что же может пойти не так? Ответ — всё. В процессе интеграции связаны несколько сторон.

Познакомимся с участниками интеграции сайта с 1C:

• Студия или агентство веб-разработки. Люди там как-то организованы, часто есть ответственный менеджер, за которым прячется его техническая команда. Хотя бывает, что и не прячется.
• Заказчик. Большой босс, который который хочет либо что-то заработать, либо сократить издержки. Заказчиком может выступать коммерческий отдел или отдел маркетинга — всегда по-разному и зависит от того, кому проект более выгоден.
• Специалист или команда по ERP-системе, которые знают инфраструктуру. Они, как правило, перегружены текущими задачами, из-за чего доработки протоколов могут затягиваться. И да, они могут быть на аутсорсе, со своим графиком и сроками.
• Digital-продюсер на стороне заказчика, которому формально поручили управлять проектом, но реальной власти у него может и не быть (наихудший вариант). Хорошо, когда он может любую дверь с ноги открыть, имеет поддержку босса и, может, даже мафии.
• Стейкхолдеры (люди, на стороне заказчика): контентщики, категорийные менеджеры, армия маркетологов, сеошники, и прочие люди, которым с этим потом работать. И у всех есть свои ограничения.

Попытка просто посадить разработчика сайта и программиста 1С рядом со словами «договоритесь» не работает — у них принципиально разные стеки технологий и задачи.

В Сибирикс процесс построен так, что менеджер уполномочен принимать решения и организовывать ресурсы для выполнения задачи. В его голове единая картина по проекту, он отвечает за задачи и цели, за бюджет, за сроки. Хорошо, когда такой же уполномоченный человек есть и на стороне компании заказчика (иногда, в небольших компаниях или при очень высокой щепетильности, это даже сам владелец бизнеса) — так проще договориться.

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

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

Мы тут всё про 1С, потому что это самый частый случай — её, к тому же, иногда можно интегрировать с сайтом штатными средствами. Однако возможности гораздо шире. Веб-сервис можно интегрировать с ERP-системой любого плана. ERP подразумевает целое множество самых разных программных пакетов. От дорогущих решений Oracle и Microsoft, до условно бесплатной CRM-ки.

В зависимости от того, что с чем мы хотим интегрировать, есть несколько сценариев обмена данными:

• текстовый файл/CSV,
• CommerceML,
• XML/JSON,
• промежуточная база данных (MySQL/MS SQL),
• web-сервисы (SOAP/REST),
• NoSQL-решения.

Формат таблиц, содержащий данные в виде текста текста с символами-разделителями (например, точка с запятой) на ячейки и строки. Из него можно быстро импортировать данные в БД сайта — например, контакты клиентов или адреса филиалов. Этот файл формируется и складывается в определенное место, откуда сайт его регулярно забирает и загружает в соответствующую таблицу уже в своей базе.

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

Стандартизированный подвид XML. Также используется для обмена данными в связке «сайт» — «ERP». Очень схож с тем, как работает предыдущий вариант — данные из реквизитов файла XML забираются сайтом в его базу данных, и наоборот. Это самый частый формат обмена с системой 1С, особенно для интернет-магазинов. Стандартом предусматривается использование схем XML, в частности, для обмена:

• каталогами товаров в системах управления каталогом,
• коммерческими предложениями (заказами),
• документами.

Современные движки для сайтов и сама 1С обычно имеют встроенные модули обмена в таком формате. Обмен данными абсолютно под все задачи сайта не всегда получается решить штатно, но эти готовые решения сильно уменьшают объем кода, который пишут и проверяют разработчики с обеих сторон баррикад. Например, не надо писать скрипты старта импорта или экспорта, обработчики полученных пакетов из 1С — всё это уже есть в готовом решении, но с определёнными ограничениями. И, к сожалению, иногда довольно суровыми.

Чем хороша штатная интеграция:

• использует легкочитаемый стандарт CommerceML;
• дает серьезную прибавку к скорости разработки;
• позволяет сэкономить бюджет;
• позволяет менять базовые настройки на уровне администратора, а не разработчика;
• дружит с нативными возможностями CMS, которые критически важны;
• содержит готовые скрипты для интернет-магазина: смарт-фильтр, каталог, заказы, кэширование.

Нештатная интеграция. Например, сайт шлёт запрос статуса заказа по номеру и идентификационному паролю в 1С-ку, в ответ получает кусок XML, который содержит нужный массив данных. Далее он его обрабатывает и выводит пользователю на экран в виде, допустим, таблицы.

Из плюсов такой интеграции: в отличие от штатных обменов пакетами импорта здесь запрос-ответ могут происходить в режиме реального времени. Запросил — получил ответ — передал пользователю.

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

Частая история с внешними сервисами доставки, оплаты, расчёта каких-то данных. Массивы данных по формализованному API шлются в одну сторону и получают от неё соответствующий ответ. Идеально подходят для быстрого запроса и получения информации «на лету».

Сервисы вроде CouchDB, Redis, ApacheHBASE и других. В NoSQL базах структура данных не делится на строгие типы, поэтому если нужно поменять модель данных, достаточно просто отразить изменение в коде приложения. Отличаются большой мощностью хранилища за счёт объединения нескольких серверов быстрой сетью, где каждый сервер обрабатывает только свою часть данных.

Современная интеграция — это давно уже не просто связка «один сайт + одна 1С». Крупный e-commerce строит целые экосистемы, где данные должны синхронизироваться между сайтом, мобильными приложениями, кассовыми аппаратами в розничных точках (Online-to-Offline) и внешними маркетинговыми платформами. Очевидно, что это точно не шаблонная история: готовые коробочные решения под такие задачи просто не подойдут и не справятся с индивидуальной бизнес-логикой крупного проекта.

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

Например, при работе над проектом для крупнейшей сети быстрого питания в Центральном Черноземье (550+ торговых точек), перед нами стояла задача обновить сайт и разработать кроссплатформенное мобильное приложение. Проект работает по логике O2O: каталог в приложении выполняет роль витрины, а сам заказ, оплата и списание бонусов происходят на кассе в офлайн-точке.

Мы реализовали сложный трехсторонний контур интеграции: из 1С забираем актуальные товары и цены для каждого города, параллельно настроили глубокий обмен с маркетинговой платформой Mindbox (где хранятся пользователи и персональные акции) и сервисом гео-данных Hotmaps. В итоге, когда пользователь делает заказ, данные из 1С (о наличии товара на конкретной точке) и данные из Mindbox (о бонусах) мгновенно стыкуются на одном экране под нагрузкой в 160 000+ активных пользователей.

Еще один пример: B2B-маркетплейс SOLOMA. В этом проекте мы также настраивали интеграцию сайта сразу с несколькими независимыми ИТ-системами заказчика, чтобы связать их в общую экосистему:

• Синхронизация каталога в реальном времени (Pimcore + Apache Kafka): Все товары и их характеристики хранятся в специальной PIM-системе клиента. Чтобы сайт моментально узнавал об изменениях, мы связали его с PIM через шину данных Apache Kafka. Как только в базе меняется описание или добавляется свойство товара — сайт мгновенно ловит это событие и сам перестраивает фильтры в каталоге.
• Автоматическая выгрузка в 1С: Как только покупатель меняет реквизиты в личном кабинете или менеджер обновляет статус заказа, сайт автоматически отправляет эти пакеты данных в 1С через ту же шину Kafka. Никакого ручного переноса — бухгалтерия и склад сразу видят актуальные документы.
• Умная обработка изображений (Imaginary): Чтобы не перегружать сервер терабайтами картинок высокого разрешения, мы настроили интеграцию с медиа-сервисом Imaginary. Сайт просто берет ссылку на фото из базы данных, на лету сжимает его до нужного размера и выдает пользователю.

И это не считая стандартных для e-commerce интеграций: интернет-эквайринга для проведения платежей, сервиса DaData для автозаполнения реквизитов и контрагентов, а также CRM-системы для работы менеджеров.

Работа по интеграции делится на 4 этапа:

1. Бриф
2. Протокол интеграции
3. Непосредственно разработка
4. Ввод в эксплуатацию

Делается это на разных стадиях относительно общего таймлайна проекта. Например, протокол, как показывает наша практика, хорошо делать после прототипирования, край — после дизайна.

По нашей практике мы можем забрать целиком на себя и настройку ERP и саму интеграцию. Или порекомендовать проверенных специалистов по настройке ERP (но далеко не каждой). Не факт, что корпоративные правила пустят нас в святая святых, так что более классический случай — когда веб или приложение живет отдельно, а ERP — отдельно.

Почему? Потому что второй стороне 100% потребуется время на подготовку площадки, с которой будем интегрировать сайт. Вбить данные, которые не вносили раньше. Возможно, данные из ERP придётся преобразовать в согласованный в протоколе формат — на стороне ERP потребуются выборки из базы, какие-то трансформации или какая-то математика. За это отвечают «обработчики». Специалист на стороне ERP должен их реализовать и проверить, что данные выгружаются в соответствии с протоколом. Это потребует времени.

Случается, что в момент реализации протокола на стороне ERP её внезапно нужно обновлять — мы крайне не рекомендуем делать интеграцию с сайтом и внедрение новой ERP параллельно, иначе вы рискуете пройти пару кругов ада.

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

Без этих данных дать информацию по стоимости и срокам интеграции невозможно — вилка получается такая, что никакой конкретики: от 8 до 80 часов на описание протокола и от 40 до 200 часов на реализацию интеграции (хотя если штатная — то там пару галочек поставил и она типа сама заработала; но это не точно).

Выглядит это примерно так:

Но иногда бывает и так :)

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

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

Протокол интеграции отвечает на ключевые вопросы: какие сущности и какие поля интегрируем, в каком направлении, с какой периодичностью и в каком формате. Также в нём прописывается, что является первичным: сайт, ERP или какая часть данных берётся на сайте, а какая — в ERP.

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

На основе прототипа и ТЗ составляем список сущностей, которые должны использоваться на сайте. К каждой сущности добавляем описание, откуда она берется. Приводим примеры с реальными данными.

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

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

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

• Зеленый: сущность полностью понятна, поля сопоставлены, данные готовы к обмену.
• Желтый: требуется доработка на стороне ERP (например, нужно разложить габариты товаров ДхШхВ в три отдельных поля в 1С для корректного расчета доставки через API логистических служб).
• Красный: бизнес-логика сайта конфликтует с техническими возможностями учетной системы.

Обычно идёт параллельно на стороне клиента (ERP) и студии (сайт).

Однако, когда речь идет об интеграции, вам не избежать коммуникации со всеми сторонами. Могут выявляться проблемы и недоработки, организовать решение которых — задача менеджера. Если эти проблемы идут постоянным потоком, имеет смысл назначить регулярные стендапы, как мы делали на этапе составления протокола, чтобы контролировать результаты до тех пор, пока фонтан проблем не иссякнет.

Работоспособность системы можно сверить и по протоколу. Берем блок, тестируем, и проверяем одну за другой сущности, отмечаем проверенное флажками. Аномалии отмечаем красным, фиксируем проблемы, на чьей они стороне, и ставим задачи на их устранение.

Со стороны ERP
Некорректно передаются данные ERP, например:

• неверно передаются сущности,
• неверно настроено подключение,
• не передаются нужные сущности или наоборот, передаются лишние данные.

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

Со стороны разработчика
Полученные данные не обрабатываются или обрабатываются некорректно. В первую очередь проверяем полученные данные. Если там все окей, начинаем сверяться: всё ли принимающая сторона делает по протоколу? Если нет, устраняем недочеты, проверяем ещё раз.

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

Могут ли быть изменения в протоколе по ходу работы? Да, и это нормально. Сначала добавляем их в смету, затем в протокол.

Вы думаете, после интеграции все волшебным образом начнет работать само? НЕТ.

Тут начинается самое интересное:

1. Деплоймент — размещение сайта на рабочем сервере.
2. Собираем команду со всех сторон на день-два.
3. Методично гоняем обмены туда-сюда.
4. Прогоняем типовые ситуации.
5. Составляем список проблем.
6. Формализуем их в задачи.
7. Ходим по итеративному кругу: сделали задачу — проверили — сделали — проверили.

Это действительно может занимать от пары часов до нескольких недель в зависимости от сложности системы. Садимся и гоняем импорты вживую. Фиксируем проблемы, на чьей они стороне. Исправляем, проверяем. Иначе можно бесконечно спихивать задачи друг на друга, пока проект стремительно протухает, деньги не зарабатываются, а нервы и ресурсы истощаются. Когда не осталось нерешенных вопросов — проект готов к релизу.

Интеграция — это, конечно, хорошо. Но когда мы говорим про высоконагруженный e-commerce и ERP-системы, это история не про «один раз настроил и забыл». Это непрерывный процесс управления архитектурой и рисками, где нужно постоянно держать руку на пульсе.

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