.svg)
Отсутствующие данные о брендах и нулевые цены: диагностика обмена 1С с CS-Cart для 50 тысяч товаров
Клиент обратился с несколькими проблемами: у части товаров перестал отображаться производитель, у части товаров цена стала нулевой, а для некоторых позиций на витрине сохранились прошлогодние цены.
Каталог — примерно 50 000 товаров. Обмен штатный, по CommerceML: конфигурация УТ на стороне клиента и штатный модуль обмена на стороне CS-Cart.
Первой гипотезой была ошибка парсера на стороне сайта. После нескольких дней диагностики подтвердилось обратное: парсер работал штатно. Причина каждой из обнаруженных проблем находилась на стороне 1С, хотя в каждом случае проявлялась по-разному.
Классификатор CommerceML
Данные о брендах содержатся только в первом файле
Значение тега <Изготовитель> отсутствовало не у всех товаров, а только у позиций начиная с определённого места в каталоге. Эта закономерность помогла определить причину.
В формате CommerceML 1С помещает общий справочник брендов — блок <Классификатор> — только в первый файл выгрузки. Он присутствует в import_1.xml, а в import_2.xml и последующих файлах передаются только идентификаторы без расшифровки. Предполагается, что принимающая сторона сохраняет справочник в памяти на протяжении всего обмена.
CS-Cart корректно обрабатывал первый файл, но при переходе к следующей порции сбрасывал кэш справочника. После этого сопоставление идентификаторов становилось невозможным.
Проблему можно устранить в настройках 1С. В узле обмена предусмотрен параметр «Количество объектов в одной порции данных». Мы установили значение 0, после чего 1С стала выгружать весь каталог в один файл. При таком режиме классификатор и товары передаются совместно.
Для каталога на 50 000 товаров у этого решения есть ограничение: вместо нескольких небольших файлов формируется один XML-файл большого объёма. Это повышает требования к памяти и времени выполнения на принимающей стороне. В нашем случае такой вариант оказался приемлемым, однако перед его применением необходимо оценить объём каталога и ресурсы сервера.
Режим выгрузки
Выгрузка выполняется восемь часов, но import.xml не формируется
Во время диагностики брендов обнаружилась ещё одна проблема: обмен запускался, но файл import.xml на сервере не появлялся.
1С вывела ошибку базы данных: конфликт блокировок при выполнении транзакции, в результате которого процесс стал жертвой взаимоблокировки. Возник классический deadlock: фоновые процессы SQL-сервера одновременно обратились к одним и тем же таблицам. Процесс 1cv8.exe не завершался штатно, поэтому его пришлось остановить через диспетчер задач Windows.
Затем выяснилось, что узел обмена работал в ограниченном режиме «только цены и остатки». При такой конфигурации ожидаемый файл не должен был формироваться. После переключения узла в режим полной выгрузки состав передаваемых файлов изменился.
Полный цикл выгрузки на сервер занимал около восьми часов, что существенно замедляло проверку гипотез. Поэтому выгрузку перенаправили в локальную папку на компьютере с 1С. Файлы формировались значительно быстрее и становились доступны для непосредственного анализа. Дальнейшая диагностика выполнялась на локальных файлах.
Полная история обмена
Записи начала обмена удалялись из журнала
Диагностику осложняло то, что журнал не содержал полной истории обмена.
В CS-Cart установлен фиксированный лимит на количество хранимых записей о синхронизации. Для стандартных объёмов его достаточно, но для каталога на 50 тысяч товаров лимит оказался недостаточным. Обмен состоит из двух этапов: сначала выполняется import товаров, затем обрабатывается offers с ценами и остатками. Этап offers создавал столько записей, что данные об этапе import удалялись из журнала. К моменту анализа была доступна только завершающая часть процесса, поэтому выводы основывались на неполных данных.
В коде модуля я увеличил лимит настройки config.commerceml.max_log_files в файле ServiceProvider.php. Это позволило сохранить записи до завершения полного цикла и просмотреть весь обмен — от первого файла до последнего.
Проверка исходных данных
Нулевая цена присутствовала в исходных данных
После получения полных локальных файлов и журналов оставалось определить источник некорректных значений.
Я выбрал артикулы проблемных товаров и выполнил поиск через grep в файле offers.xml. Для товаров с нулевой ценой на сайте нулевое значение присутствовало и в исходном XML. Устаревшие цены на витрине также соответствовали значениям в файле. Таким образом, CS-Cart записывал в базу данные без изменений.
Дальнейшая диагностика относилась к стороне 1С. Система передавала некорректный тип цены с названием «Не брать. Поставка с отсрочкой». Причин оказалось две: у номенклатуры изменили вид, а в типовых соглашениях присутствовали дубли. Исправление этих данных передали программисту 1С.
Порядок диагностики
Рекомендуемый порядок диагностики
В первую очередь следует проверить режим узла обмена. Во многих случаях сообщение о том, что сайт не принимает данные, связано с тем, что необходимые данные не включены в выгрузку.
Затем рекомендуется выполнить локальную выгрузку в папку и проверить исходный XML. Ожидание восьмичасового серверного цикла существенно замедляет проверку каждой гипотезы, тогда как локальная выгрузка сокращает цикл диагностики до нескольких минут. Поиск по артикулу через grep позволяет быстро определить, на каком этапе появилось некорректное значение.
Также необходимо убедиться, что журнал содержит полную историю обмена. Настройки хранения, достаточные для магазина среднего размера, могут не подходить для крупного каталога. Выводы, основанные на неполном журнале, могут быть ошибочными.
Программист 1С исправил типы цен на своей стороне, и с тех пор обмен работает без нашего участия.