В процессе интеграции 1С с интернет-магазином одной из самых острых задач является передача актуальных остатков. Стандартный подход «выгружать всё каждые 15 минут» быстро становится неэффективным, когда номенклатура разрастается до тысяч позиций, а изменения происходят лишь в малой части из них. В этой статье мы разберем, как построить надежную и быструю систему обмена, проанализируем различные архитектурные подходы и выберем наиболее стабильное решение.
При классической схеме обмена 1С каждый раз формирует массив данных по всем товарам. Это создает избыточную нагрузку на сервер 1С при формировании запроса, нагружает канал связи и заставляет базу данных сайта выполнять тысячи лишних операций UPDATE. Рассмотрим вариант оптимизации, предложенный в обсуждении: создание специального регистра сведений для фиксации изменений.
Суть идеи заключается в том, чтобы фиксировать только те позиции номенклатуры, по которым произошло движение. Мы можем создать регистр сведений ОчередьВыгрузки с измерениями Номенклатура и Склад. Как только документ (например, Реализация или Поступление) меняет остаток, запись об этой номенклатуре попадает в регистр.
Алгоритм работы такой системы:
ОчередьВыгрузки.Наиболее «родным» для платформы 1С инструментом решения задачи является использование объекта ПланыОбмена. Это позволяет не создавать велосипеды с регистрами сведений, а использовать оптимизированный механизм регистрации изменений. Разберем по шагам, как это реализовать.
Проанализируем ситуацию: нам нужно отслеживать изменения в регистре накопления ТоварыНаСкладах. Мы включаем этот регистр в состав плана обмена. Теперь при любом движении документа система автоматически будет ставить отметку о том, что данные изменились. В коде выгрузки мы будем использовать метод ВыбратьИзменения().
Важно помнить о критическом нюансе: если мы просто выберем номенклатуру, по которой есть остатки, мы можем забыть о позициях, остаток которых стал равен нулю. Если товар закончился, его обязательно нужно передать на сайт с нулевым значением, иначе на витрине он останется висеть как «в наличии».
Другой надежный способ, упомянутый в дискуссии, — хранение в 1С «снимка» последней успешной выгрузки. Для этого создается регистр сведений, где хранятся значения остатков и цен, которые были переданы на сайт в прошлый раз. Рассмотрим пример логики:
// Получаем текущие остатки из регистров
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Номенклатура, Склад, КоличествоОстаток ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки";
ТекущиеОстатки = Запрос.Выполнить().Выгрузить();
// Сравниваем с данными в РС "ИсторияВыгрузки"
Для Каждого Строка Из ТекущиеОстатки Цикл
СтароеЗначение = РегистрыСведений.ИсторияВыгрузки.Получить(Новый Структура("Номенклатура", Строка.Номенклатура)).Количество;
Если Строка.КоличествоОстаток <> СтароеЗначение Тогда
// Регистрируем необходимость выгрузки
ЗаписатьВЛогВыгрузки(Строка.Номенклатура, Строка.КоличествоОстаток);
КонецЕсли;
КонецЦикла;
Этот метод хорош тем, что он устойчив к изменениям документов «задним числом». Однако сравнение больших массивов данных в цикле может быть медленным. Для оптимизации рекомендуем использовать хеширование данных (например, MD5 от строки, содержащей цену и остаток). Хранение короткого хеша в регистре вместо полных данных значительно ускоряет поиск изменений.
Рассмотрим важный аспект, упомянутый опытными разработчиками: любая «дельта-выгрузка» (только изменения) рано или поздно может привести к рассинхрону. Сайт может «упасть», его могут восстановить из старого бэкапа, или в процессе передачи данных произойдет сетевой сбой. В этом случае ваш «оптимальный» алгоритм будет считать, что на сайте всё верно, хотя это не так.
Рекомендуемая стратегия:
ПланыОбмена или подписки на события.Проанализируем дополнительные факторы, которые помогут сделать обмен еще эффективнее. Выясним причину, по которой даже оптимизированный обмен может тормозить сайт. Часто это происходит из-за слишком мелких изменений. Если у вас на складе 5000 штук товара, нужно ли уведомлять сайт об изменении остатка до 4999? Скорее всего, нет.
Посмотрим на пример внедрения логики «порога значимости»: выгружайте изменения только в том случае, если остаток пересекает критические отметки (например, стал меньше 10, меньше 5 или равен 0). Это позволяет отсечь до 70% лишних транзакций в высоконагруженных системах.
Также не забывайте про доступный остаток. На сайт нужно передавать не физическое количество на полке, а результат функции Остаток - Резерв. Для этого в запросе к виртуальным таблицам 1С следует обращаться к полям ВНаличииОстаток и РезервОстаток.
В завершение разберем вопрос подтверждения данных. Оптимально, если ваш HTTP-сервис на стороне сайта возвращает статус обработки каждого пакета. В 1С следует реализовать механизм переповтора: если пакет не был доставлен, он должен остаться в очереди (в плане обмена) до следующего сеанса связи.