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

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

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

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

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

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

На старте задача выглядела для бизнеса достаточно просто и понятно: после перехода на УТ 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-импортов, чтобы администратор видел реальную картину.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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