Как мы доработали плагин 1С для Webasyst Shop-Script и создали резервный сценарий полного импорта после смены версии 1С УТ 11.5

Резервный импорт и синхронизация фото в Webasyst Shop-Script: как мы усилили плагин 1С

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

В этом проекте сайт работал на Webasyst Shop-Script, а обмен с 1С выполнялся через штатный плагин cml1c. После перехода клиента на 1С:Управление торговлей 11.5 начались проблемы с импортом. Первым заметным симптомом стали фотографии товаров: сами товары, категории и часть структуры каталога приходили, а изображения передавались некорректно или нестабильно. Именно из-за этого задача сначала выглядела как локальная проблема с фото, хотя в реальности она затрагивала сам сценарий обмена.

Именно поэтому этот кейс интересен не только как история про «не передаются фотографии». По сути, он показывает, как из конкретной боли клиента можно вырасти в системное решение: с резервным хранением архивов, отдельным интерфейсом ручного импорта, защитой от пересечений процессов, автоматическим cron-запуском, удалением устаревших фото 1С и подробным отчётом по изменившимся товарам.

Как выглядела проблема на практике

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

Именно такие кейсы самые неприятные в e-commerce. Если импорт не работает вообще — это видно сразу. Если же из 1С приходят товары, характеристики и категории, но ломается один из блоков, например изображения, то проблема может долго жить в серой зоне. Бизнес видит, что обмен «вроде бы работает», а команда проекта получает постоянные последствия:

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

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

🗂

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

Что именно выяснили разработчики штатного плагина

Ключевой поворот в задаче произошёл после того, как разработчики основного плагина Webasyst повторно изучили логи и дали точное техническое объяснение происходящего. Это принципиальный момент, и в статье его важно подчеркнуть отдельно: первопричину установили именно разработчики штатного решения, которые хорошо знают внутреннюю логику плагина cml1c и ожидаемый сценарий CommerceML-обмена.

Они увидели, что обмен со стороны 1С шёл в неправильной последовательности. В логах фиксировалось следующее:

?type=catalog&mode=file&filename=import0_1.xml
?type=catalog&mode=file&filename=import_files/00/0009de1cbf3811ea80d24ccc6a08bebd_3b1e62b2db6011eeba869c6b0022894b.jpg
?type=catalog&mode=file&filename=import_files/...jpg
...

На первый взгляд это может выглядеть логично: сначала XML, потом отдельные изображения. Но для штатной логики плагина это неверный путь. Разработчики чётко объяснили, что на этапе mode=file должен передаваться не XML-файл, а имя ZIP-архива, который загружается в магазин. Плагин ориентируется именно по имени этого ZIP-файла и дальше понимает, откуда извлекать XML и изображения для последующего импорта.

Второй важный вывод: отдельные многочисленные запросы для отправки изображений в магазин вообще не нужны. При правильном сценарии 1С сначала загружает ZIP-архив, а потом вызывает mode=import для XML-файла. В процессе обработки XML сам плагин распаковывает архив и считывает изображения по относительным путям, указанным внутри XML. То есть изображения должны импортироваться как часть общего пакета, а не как отдельный поток файлов.

Как должен выглядеть правильный порядок запросов

?type=catalog&mode=checkauth
?type=catalog&mode=init
?type=catalog&mode=file&filename=...zip
?type=catalog&mode=import&filename=...xml
?type=catalog&mode=import&filename=...xml
...

Именно это объяснение сняло главный вопрос: почему долгое время казалось, что со стороны сайта всё более-менее работает, но фотографии всё равно не доходят корректно. Теперь причина стала прозрачной. Проблема была не в том, что Webasyst «не умеет» обрабатывать изображения, а в том, что после перехода на УТ 11.5 нарушился ожидаемый плагином сценарий передачи данных со стороны 1С.

Какую часть работы сделали мы со своей стороны

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

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

Именно поэтому мы сделали не разовую «заплатку», а целый набор связанных доработок для плагина cml1c в Webasyst Shop-Script:

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

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

Как устроен резервный сценарий импорта

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

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

Что даёт папка cml1c_keep

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

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

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

Отдельно мы предусмотрели защиту от пересечений процессов. Если в момент запуска уже идёт обычный обмен с 1С или уже выполняется резервный импорт, ручной старт блокируется, а администратор видит понятный статус. Аналогично и cron-сценарий не должен запускаться поверх уже идущего процесса. Это критично, потому что в проектах с большими архивами хаос запуска «поверх друг друга» быстро превращается в источник новых ошибок.

Как мы довели резервный импорт до автоматического cron-запуска

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

Cron не имитирует нажатие кнопки в браузере. Он запускает серверную CLI-команду плагина, поэтому не зависит от открытой страницы, авторизации администратора и длительности одной браузерной сессии. Процесс может идти десятки минут, а страницу административной панели в это время можно закрывать или обновлять.

Перед началом запуска выполняется несколько проверок:

• есть ли в cml1c_keep новый ZIP-архив;
• не был ли этот архив уже успешно обработан;
• не выполняется ли в данный момент штатный обмен с 1С, ручной импорт или другой cron-процесс;
• можно ли безопасно создать временную рабочую копию архива;
• получен ли финальный результат всех этапов импорта.

Если уже идёт другой импорт, новый процесс не запускается поверх него. Если последняя версия архива уже успешно обработана, она не импортируется повторно без необходимости. При появлении нового ZIP-файла cron берёт именно его, создаёт рабочую копию и передаёт её штатному механизму обработки плагина.

Пример реального автоматического импорта

Один из последних запусков по расписанию завершился следующим результатом:

Cron успешно отработал
Проверка: 30.07.2026 03:28:25
Архив: v8_48EA_7e79.zip
Общее время: 00 ч 28 мин 12 с

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

Почему обновить фото недостаточно: синхронизация и удаление устаревших изображений

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

Это принципиально отличается от обычного импорта файлов. Загрузить новое изображение — значит обработать то, что присутствует в текущем XML и архиве. Удалить старое — значит корректно определить, что раньше фотография относилась к этому товару и управлялась обменом с 1С, но в новой полной выгрузке её больше нет.

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

Вместо массовой перезагрузки мы реализовали точечную синхронизацию:

1. после включения функции система запоминает состав фотографий 1С для каждого обработанного товара;
2. при следующей полной выгрузке строится новый список изображений этого же товара;
3. система сравнивает предыдущий и текущий наборы;
4. неизменившиеся фотографии остаются на месте и не загружаются повторно без причины;
5. новые изображения импортируются штатным способом;
6. удаляются только те старые фотографии 1С, которых больше нет в актуальной выгрузке.

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

Что происходит, если удалена главная фотография

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

Поэтому после фактического удаления мы добавили отдельное восстановление связей:

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

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

Почему удаление сделано управляемым

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

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

Как контролировать результат импорта и изменения фотографий

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

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

В отчёте доступны:

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

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

Почему инструмент уже не только про фотографии

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

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

Если на стороне 1С обмен разделён на несколько пакетов или несколько этапов, то при наличии соответствующего архива мы уже не ограничены только сценарием «спасти фотографии». Мы можем использовать тот же резервный подход и для повторной обработки последующих архивов — например, с остатками и ценами. Это и есть главный переход от частного решения к системному.

Именно поэтому в статье важно писать честно и широко: мы начали работу из-за фото, но создали инструмент, через который теперь фактически может проходить весь резервный импорт. То есть результат значительно превосходит исходную локальную боль клиента.

Какую пользу это дало клиенту и бизнесу

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

Теперь у клиента есть:

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

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

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

Вывод

После перехода клиента на 1С:УТ 11.5 обмен с сайтом на Webasyst Shop-Script через плагин cml1c начал работать некорректно. Первым заметным симптомом стали фотографии товаров, из-за чего задача сначала воспринималась как локальная проблема изображений. Однако повторный анализ логов со стороны разработчиков штатного плагина показал реальную причину: нарушился сам ожидаемый порядок передачи данных из 1С. Вместо загрузки ZIP-архива и последующего импорта XML-файла сайт получал неверную последовательность запросов, включая лишнюю отправку отдельных изображений.

Получив это объяснение, мы не стали переписывать базовую механику плагина с нуля, а сосредоточились на том, чтобы со стороны сайта создать практический резервный инструмент. Мы добавили хранение архивов в папке cml1c_keep, сделали интерфейс ручного импорта, реализовали безопасный повторный запуск через рабочую копию, внедрили контроль параллельных процессов и довели cron-сценарий до полноценного автоматического импорта с сохранением финального результата.

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

В результате проект получил не просто временный обходной путь для фотографий, а полноценный управляемый сценарий резервного импорта, который при необходимости может использоваться для всего обмена: товаров, категорий, характеристик, изображений, а также последующих архивов с остатками и ценами. Реальный автоматический запуск обработал 37 130 товаров и 12 598 изображений за 28 минут 12 секунд, импортировал 51 новое изображение и удалил 2 устаревшие фотографии 1С.

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