Как подготовить интернет‑магазин к росту: 6 правил надежной интеграции сайта с 1С

Когда интернет‑магазин только начинает работать, обмен с 1С может быть довольно простым. Из 1С на сайт приходят товары, цены и остатки, обратно отправляются заказы.

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

С такой ситуацией мы столкнулись при работе над интернет‑магазином строительных товаров. В его базе 211 761 товарная позиция. Между сайтом и 1С передаются товары, цены, остатки, акции, заказы и данные дисконтных карт. К магазину также подключены интернет‑эквайринг, оплата в кредит и рассрочку, «Долями», несколько служб доставки и автоматическое заполнение реквизитов компаний.

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

Для магазина, где одновременно идут онлайн- и офлайн‑продажи, даже пять минут могут быть критичны. Представим, что на сайте купили последний товар. Информация об этом еще не успела попасть в 1С, а за это время тот же товар продали в офлайн‑точке. Возможна и обратная ситуация: товар уже купили в магазине, а на сайте он все еще отображается в наличии.

Поэтому типовой обмен пришлось адаптировать под объем данных и требования к скорости. В итоге около 80% обменов с 1С переработали.

Этот проект показал: дело не только в количестве товаров. Важнее, как магазин работает с ценами, остатками, скидками и заказами и что произойдет, если один из процессов даст сбой.

Разберем шесть вещей, которые стоит проверить, если интернет‑магазин растет или вы только готовитесь к интеграции с 1С.

Шаг 1. Сначала наведите порядок в данных

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

В нашем проекте основной системой стала 1С. Там хранятся товары, цены, остатки, информация о складах, скидках и дисконтных картах. Сайт получает эти данные из 1С, показывает их покупателям, а оформленные заказы отправляет обратно.

Но автоматический обмен работает только с той информацией, которую система умеет найти.

Например, в карточке клиента в 1С есть отдельное поле для телефона. Если сотрудник укажет номер там, 1С сможет передать его дальше. Если записать тот же номер в комментарии, сотрудник его увидит, а автоматический обмен уже нет.

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

До интеграции проверьте несколько реальных карточек товаров и клиентов:

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

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

Шаг 2. Проверьте, что еще остановится при одном сбое

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

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

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

Обсудите с интегратором:

• какие данные будут передаваться между 1С и сайтом;
• какие из них можно объединить в один поток;
• какие лучше передавать отдельно;
• что перестанет обновляться, если один из обменов остановится.

Шаг 3. Решите, какие данные должны обновляться быстро

Не все данные нужно передавать между 1С и сайтом с одинаковой скоростью.

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

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

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

Обсудите с интегратором:

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

Шаг 4. Проверьте, сколько на самом деле занимает обновление

Допустим, цены и остатки должны быстро появляться на сайте. Теперь стоит проверить, сколько времени проходит от изменения в 1С до обновления на сайте.

За это время 1С должна подготовить и отправить данные, а сайт принять и обработать их. Задержка может появиться на любом этапе.

В нашем проекте мы столкнулись сразу с двумя причинами задержки.

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

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

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

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

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

Если данные обновляются медленно, попросите команду проверить:

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

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

Шаг 5. Проверяйте не только ошибки, но и успешные обновления

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

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

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

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

Попросите команду показать, как это контролируется сейчас:

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

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

Шаг 6. Заранее решите, как восстанавливать данные после аварии

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

Для интернет‑магазина это большой срок. За несколько дней меняются цены и остатки, появляются новые товары и заказы. Если просто развернуть старую копию, сайт вернется в состояние двух- или трехдневной давности.

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

Поэтому сценарий восстановления лучше разобрать заранее.

Выясните вместе с командой:

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

Можно проверить себя одним вопросом: если сегодня придется восстановить сайт из вчерашней копии, что мы потеряем и откуда вернем актуальные данные?

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

Главное

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