Блог программиста UMI CMS

Интеграция UMI.CMS с 1C: построение обмена для сложных каталогов

Рубрика: Обучение, Решения, Тонкости UMI CMS

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

Например, на складе идёт полная ревизия и переоценка. И в этот момент почему-то обмен «падает».

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

Итак, вот несколько важных моментов:

1. Порционная выгрузка из 1С. То есть на стороне 1С необходимо в обязательном порядке предусмотреть выгрузку не всего каталога, а порций по несколько сотен (иногда тысяч) позиций. Без этого нагрузка на сайт будет непредсказуемой. А так вы точно понимаете что выгружаете 500 позиций за раз и не больше.
   
   Этот пункт потребует разработчика 1С и его участия. В зависимости от компетенции сотрудника, при наличии хороших коммуникаций между командой разработки сайта и разработки 1С, проект обычно занимает от недели до пары месяцев. На срок сильно влияет структурированность базы в 1С, разрозненность информации и прочее.
2. Обязательное логирование. Нужна информация о том, что приходит от 1С и когда. Без этого невозможно хоть как-то осознать где именно возникает проблема.
   
   Этот этап делается на стороне сайта. Тут требуется команда разработки и пристальное внимание к серверу.
   
   Дело в том, что логи — это, зачастую, файлы. А файлы могут очень быстро забить жёсткий диск, что, в свою очередь, приведёт к падению сайта ещё быстрее. Поэтому важно отслеживать этот момент.
3. Вынос «попутных» процессов из обновления товаров. Это один из самых важных элементов, нагружающих ваш сервер и БД. К сожалению, это означает, что после выгрузки из 1С ваши товары станут не сразу меняться для сторонних выгрузок, таких как выгрузка в ЯМаркет или в директ. Но это всё-таки лучше, чем просто уронить сайт и не дать возможность заказывать вообще.
   
   Обычно для этого применяется отказ от модуля стандартного обмена данными в пользу нашего модуля GMC, который может в асинхронном режиме закрыть вопрос с обновлением товара. Но ещё нужна будет доработка в ядре сайта.

Минутка душноты: почему «падает» обмен данными.

Со стороны 1С обмен почти никогда не идёт всем каталогом. Было бы странно каждые 5 минут пересылать весь каталог в 10 тысяч наименований со всеми фотографиями, текстами и прочим.

Поэтому в 1С существует показатель изменения товара. Это как бы галочка, которая сигнализирует «выгрузи меня в следующий раз».

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

Проблема возникает тогда, когда идёт полная ревизия склада. Таких товаров одномоментно становится очень много. И все они прямо в одно мгновение летят на сайт. Сайт говорит «ой» и падает.

Но и сайт причастен к этой проблеме.

Дело в том, что на сайте есть процессы, которые срабатывают прямо в момент изменения товара.

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

И выходит, что каждый товар должен не просто выгрузиться на сайт, но ещё и перегенерировать несколько попутных файлов.

Конечно же 2 процесса дольше, чем 1. Ну, а если в процессе жизни сайта на обновление навешаны ещё процессы, то там вообще караул.

Поэтому доработки требуются с обеих сторон: и от 1С, и от сайта.

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

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

Дальше вам нужно больше клиентов. Значит вам нужен больший маркетинговый бюджет. Значит вы, скорее всего, начинаете платить дороже за 1 лида. Ну и всё, поплыли.

И следующий этап: приходит владелец и говорит «а почему у нас снизилась прибыль в этом году?». А у вас нет ответа.

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

Так стоит ли эту проблему оставлять без решения?