Ajax-овый импортер на десятки и сотни тысяч товаров.
Я недавно выкладывал на ютуб ролик (смотрим под катом), в котором демонстрировал этот импортер, и вот кратко здесь про него напишу. Для начала задача: выполнить импорт 13 000 товаров (и не просто импорт, а еще и с проверкой существующих товаров, разделов и т.п., и обновлением остатков и цен, если товар уже есть, а еще и отметкой «нет в наличии» тех товаров, которые уже есть в каталоге, но которых нет в файле импорта), при чем так, чтобы уложиться в 30 секунд и 64 Mb памяти. В общем, я сразу решил, что в такие рамки не уложиться, и что надо написать такой модуль, который работал бы в цикле (пока задача не будет выполнена), при этом, чтобы вся логика полностью рулилась на стороне сервера. В общем, вот это как раз и есть такое решение (чуть подробней в ролике). Отмечу только, что это дело очень похоже на стандартный компонент MODx.Console, но это не он. Нативный компонент я попробовал, но отмел из-за того, что он только асинхронные запросы отправляет, не дожидаясь ответа. В общем, морду писал сам.
Добрый день, Николай. А чем именно не понравился стандартный компонент MODx.Console? Я делал на нем импорт 300 000 позиций и нареканий с ним не было. Конечно там может перекосить регистры, на которых он, собственно, и работает, но в целом компонент мне показался довольно стабильным.
Добрый день. А чем именно не понравился стандартный компонент MODx.Console? 1. Тем, что он запросы шлет асинхроннонные, и не дожидаясь ответа, шлет новый запрос. (возможность переключить провайдер в синхронный режим я не нашел. Если вы знаете как, поделитесь, полезно будет). 2. Слишком хитрая система записи логов в файлы и чтения ответов из них. По-моему избыточная сложность. Я ранее уже делал импортер с использованием стандартной консоли MODX-а ( www.youtube.com/watch?feature=player_detailpage&v=fpkfFbInV88#t=44s ), и хочу сказать, что второй вариант мне показался более простым и гибким.
То есть реальных проблем со стандартной консолью не было, просто свое решение задачи? (возможность переключить провайдер в синхронный режим я не нашел. Если вы знаете как, поделитесь, полезно будет). Нет, я ничего подобного в коде не видел, когда мне нужен был этот компонент. Чтобы все это дело заставить дожидаться ответа действительно придется переписывать консоль. А вы как обошлись без передачи логов через файлы между работающим скриптом импорта и Javascript-формой?
То есть реальных проблем со стандартной консолью не было, просто свое решение задачи? Асинхронные запросы без ожидания ответа — это и есть большая проблема. Здесь важно, чтобы каждый запрос обрабатывался последовательно, так как, к примеру, нельзя перейти к шагу импорта записей во временную таблицу, пока эта таблица не очищена. А вы как обошлись без передачи логов через файлы между работающим скриптом импорта и Javascript-формой? Все просто: идет запрос на сервер, и с сервера информация поступает в ответе через стандартное return $this->success($msg, $object);
Асинхронные запросы без ожидания ответа — это и есть большая проблема. Здесь важно, чтобы каждый запрос обрабатывался последовательно, так как, к примеру, нельзя перейти к шагу импорта записей во временную таблицу, пока эта таблица не очищена. В базовой версии это компенсировалось тем, что весь импорт выполнялся в рамках одного процессора, а в нем действия могут выполняться только последовательно. А веб-форма просто проверяла регистр на наличие новых сообщений. Таким образом логика работы процессора не могла нарушиться асинхронными запросами. Все просто: идет запрос на сервер, и с сервера информация поступает в ответе через стандартное return $this->success($msg, $object); Мне непонятен следующий момент. Вы выполняете импорт в процессоре, а во время импорта процессор не может ответить на запрос формы, так как он уже начал свою работу и нужен какой-то промежуточный обмен данными между работающим процессором и формой. Он должен сохранять сообщения о ходе операции, чтобы форма запросом к промежуточному скрипту могла отобразить все сообщения работающего процессора. Так работает стандартная консоль + процессор. Сам процессор кладет сообщения в регистр и форма их потом забирает. Как вы смогли избавиться от промежуточного стека сообщений?
В базовой версии это компенсировалось тем, что весь импорт выполнялся в рамках одного процессора, а в нем действия могут выполняться только последовательно. А веб-форма просто проверяла регистр на наличие новых сообщений. Таким образом логика работы процессора не могла нарушиться асинхронными запросами. А вы условие в топике читали: при чем так, чтобы уложиться в 30 секунд и 64 Mb памяти Уверены, что 30 секунд нам будет достаточно, чтобы прогрузить 13 000 товаров? Эту проблему данный компонент и решает — он в цикле шлет кучу запросов, на каждый из которых может уходить до 30-ти секунд. Таким образом импортер хоть сутки может крутиться и прогрузить хоть миллион товаров. Вы выполняете импорт в процессоре, а во время импорта процессор не может ответить на запрос формы, так как он уже начал свою работу и нужен какой-то промежуточный обмен данными между работающим процессором и формой. Вы в целом не уловили смысла этого решения. Смысл в том, что вся процедура разбивается на кучу шагов. То есть запрос отрабатывает запрос, возвращает ответ, консоль кушает ответ и опять шлет запрос, и т.д. и т.п., пока процессор не вернет «COMPLITED».
Не было возможности посмотреть видео со звуком, а в описании к видео недостаточно информации. Там вы все хорошо объясняете. А по видео слишком уж похоже на стандартный импорт и разницы в подходе не видно. Прошу меня простить за поспешность.
Ничего страшного.
А почему именно 30, а не 40 или 20 сек.? У меня просто была проблема с компонентом от Andchir, в общем при импорте на 30-й секунде была проблема…
Не я это придумал. Это стандартный порог в настройках нгинкса, апача и т.п. В настройках можно его изменить, если VPS или типа того.
Добрый день, Николай. Делаю небольшой магазин на ShopModX. Столкнулся с проблемой импорта товаров из выгрузки на Яндекс.Маркет. Можно ли где-то посмотреть пример как правильно импортировать в ShopModX товары? Сам изучение ModX начал недавно. Хотелось самому разобраться, да вот пока не очень получается с импортом…
Можно чуть подробней про этот «импорт товаров из выгрузки на Яндекс.Маркет»? Экспорт в Я.Маркет не рассчитан на то, чтобы его импортировали потом на сайте. Это чисто выгрузка на яндекс.
Мой клиент является партнером одной фирмы, у которой есть сайт, с этого сайта мне предоставляют выгрузку в Яндекс.Маркет, чтобы я разместил ее на сайте клиента.
Ну, если там выгрузка подробная, то ее можно использовать. Используйте SimpleXML, загружайте их файл и создавайте/обновляйте ресурсы на своем сайте. Если опыта нет и не справитесь, можем написать импортер. Цена 3000 рублей.
Добрый день! Пока нет. Это вещь чисто индивидуальная, настраиваемая на отдельных проектах. Но не исключено появление какой-то более массовой вариации.
Добрый день Николай! Но не исключено появление какой-то более массовой вариации. По прежнему нельзя скачать данный импортер?
Пока что да. Но, думаю скоро появится:)