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

Красота!
А бывает ли реально так?

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

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

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

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

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

Есть специалист или команда по ERP-системе, которые знают инфраструктуру. И лениво что-то там допиливают при необходимости. Всех несогласных шлют куда подальше. И да, они могут быть на аутсорсе, со своим графиком и сроками.

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

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

Тут сейчас появится кто-то с вопросом, а почему бы нам не посадить разработчика сайта и программиста 1С рядом, и пусть они договорятся?

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

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

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

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

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

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

CSV

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

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

CommerceML

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

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

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

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

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

XML/JSON

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

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

Промежуточная БД (MySQL/MS SQL)

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


Веб-сервисы (SOAP/REST)

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

NoSQL-решения

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

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

Работа по интеграции делится на 4 этапа:
1. бриф,
2. протокол интеграции,
3. непосредственно разработка,
4. ввод в эксплуатацию.

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

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

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

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


Этап 1. Бриф и протокол

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

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

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

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

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


Этап 2. Протокол

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

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


Как составлять

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

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

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

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

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

Имея на руках качественно проработанный протокол интеграции, вы сможете:
1. Гарантировать заказчику, что вся эта нужная хрень на странице будет работать.
2. Четко и однозначно поставить задачу разработчику.
3. Диагностировать и устранять возможные проблемы на этапе отладки.

Иначе будет что-то как-то интегрированное с чем-то, которое как-то работает, но как — знает только программист Василий из деревни Малые Дубняки, который на связи в каждый второй четверг третьего месяца, после дождичка. А вам с этим жить и зарабатывать.


Этап 3. Разработка

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

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

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


Что может пойти не так

Со стороны ERP

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

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

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

Самый хороший метод здесь — светофор. Что красить, надо смотреть по ситуации.


Со стороны разработчика

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


Проблема в протоколе

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

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


Этап 4. Ввод в эксплуатацию

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

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

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

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

Интеграция — это хорошо.
Технологичный сайт — это не продукт. Это процесс:

1. Узнайте, что нужно: заполните с клиентом бриф на интеграцию.
   
2. Запланируйте: сделайте протокол интеграции.
   
3. Интегрируйте: системно и технологично.
   
4. Приготовьтесь к вводу в эксплуатацию: методичная двусторонняя отладка.

Всего-то :)