Node.JS и выгрузка каталога из 1С на сайт

Из 1С можно выгружать только измененные объекты, используя планы обмена или версионирование, незачем гонять весь каталог в 26000 товаров каждый раз при загрузке. А маленький файлик с сотней позиций и в xml загружался бы в течении доли секунды

я эту задачу решал 10 лет назад, путем формированием собственного xml, который весил раз в двадцать пять меньше CommerceML. Время парсинга этого файла у мменя занимало не более минут. Был каталог нескольких тысяч наименований.
Далее, я пытался сохранять предыдущие товарные позиции и слал только дифы в том же xml. Благо, я использовал msxml как инструмент создания xml и транспорт. С Дифами выходило хуже, но что-то уже получалось.
Изменения (дифы) были следующие:
— товар временно отсутствовал
— изменилась цена
— добавилась новая товарная позиция.

в общем — это дела давно минувших дней и многие ньюансы уже позабылись.

что касается формата JSON то в эпоху РНР 3, всеми любимого нами расширения php_json не было, ну не текст же парсить :).

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

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

Благодарю за статью (вернее идею в ней).
Попросите Вашего 1Сника объяснить как он сделал свою часть. Мне было бы очень интересно, да и Вам вторая статья ;)

А сам интернет-катало на чем реализован? Node.js? Что происходит после парсинга? Складывается в базу?

не ради холивара, а просто как вариант:

Обмен по xml или json это все хорошо и действительно быстрее стандартных средств (и более гибко), но, это все-равно медленно.
был опыт следующего обмена:
1) из 1С в промежуточную таблицу/БД (она так же может быть в облаке)
2) от туда в таблицу/БД с которой работает сайт
3) сайт берет из своей таблицы/БД

имхо, работа с бд всегда быстрее, чем с файлом.
Зачем делали промежуточную БД? За выгрузку и загрузку отвечали разные люди и что бы из 1с ничего не испортить в боевой бд сайта, решили сделать промежуточный узел

Работа с нативными для языка объектами всегда на порядки быстрее чем со сторонними сущностями, которые еще нужно парсить. У нас так же были ужасные тормоза, когда мы пытались обмениваться из 1С большими данными (двухсторонний обмен). Но как только выгрузку из 1С сделали в JSON, а загрузку в 1С-вском текстовом формате, так все сразу стало летать.

Когда интрегрировался с 1С, тоже выбрал json.
Вот моя рекурсивная функция, которая может преобразовать практически любую структуру данных 1С в json:
pastebin.com/HFaEaETX

А вы заглядывали в изначальный XML, который формировала 1С?

Бывает такое, что программисты 1С сохраняют в формат XML именнос средствами 1С — и в итоге там столько «мусора», что объем чуть ли не в 2-3 раза увеличивается. Это примерно то же самое, что html из MS Word сохранять.
Исходя из постановки исходных данных, имеется 26000 позийций, средний размер позиции в XML можно принять в 2Кб, то есть 52Мб должно быть максимум. Поэтому и говорю, что возможно XML был не оптимальным.

Хотя при таких объемах JSON все равно оптимальнее — правильно сделали, что перешли.

Хотя в своем проекте NodeJS не использовал. Обходились cron-заданием на сервере, которое парсило залитый файл по FTP либо через SSH. Так же в случае SSH можно запустить скрипт удаленно.

В свое время тоже писал по этому поводу статью, но там более глобально: как вообще исключить ручную работу для обновления прайсов. Не сочтите за пиар — тем более, что писалось давно. Но эти «решения» работают в нонстопе уже лет 5 — так что кому-то может будет и интересно.

А как вы с изображениями работаете?

Я в итоге пришел к прямому запросу в mysql из 1c. Уж очень удобная конструкция «on duplicate update»…

Мы делаем так: если большая база, то выгрузка CSV, разбитую на файлы (300-500 строк), дальше 1С дергает на стороне сайта обработчик этих файлов и сообщает о результате. Если нужны точечные корректировки, то используем свой формат на основе XML-RPC. Немного про формат можно почитать в нашем блоге. А вообще, ComerceML — это большая конфетка на палочке, вроде вкусная, но есть ее долго, в карман не засунешь, а выбросить жалко. Как все быстро в итоге у нас работает можно посмотреть в статье про создание ИМ из 1С за 7 минут.

Спасибо за статью. И про замечание по отладке. Свой формат иногда в выигрыше не только по быстродействию, но и по сроку разработки тех или иных фич. В нашем решении 1C-B2B (личный кабинет для партнеров), которое работает с 1С в режиме реального времени то же при кастомизации останавливаемся на json формате. Но когда дело доходит до интеграции с внешним сайтом, CommerceML звучит из уст руководителей ИТ-отделов как безальтернативный вариант. Ну и еще многим известная cms в придачу… А Вы красиво показали про уместность альтернативных технологий.

Вы не думали что у вас php прохо настроен на сервере? На тарифе для известной cms за 700р в мес 7 000 наименований обрабатываются сервером около 3 минут. Но не больше 10 точно.