Комментарии 16
Спасибо.
Подобный скрипт имеет смысл и для разработчика сайта, чтобы иметь возможность протестировать процесс обмена. Стандартный инструмент с этим не справляется, т.к. давно отстал от модуля обмена.
Вы настроены реализовать только стандартный протокол? Пакетного режима не будет?
Совершенно непонятно как Ваш инструмент избавит от доработок на стороне сайта. Протоколы, пригодные для программиста 1С, ведет новый модуль обмена сам. Для тонкой диагностики, правда, придется их вести на стороне сайта тоже.
Цель Вашего скрипта в иллюстрация протокола HTTP сомнительна. Нужно уметь читать bash, быть знакомым с программами, использованными в скрипте. Т.е. это совершенно не замена программиста Битрикс и программиста 1С.
Что запуск скрипта возможен только на сервере — это Вы погорячились. Есть люди (я в том числе), которые используют Linux на рабочем ПК. Да и на Windows 10 разрекламирована такая возможность.
Тем не менее, Ваш труд очень полезен.
Подобный скрипт имеет смысл и для разработчика сайта, чтобы иметь возможность протестировать процесс обмена. Стандартный инструмент с этим не справляется, т.к. давно отстал от модуля обмена.
Вы настроены реализовать только стандартный протокол? Пакетного режима не будет?
Совершенно непонятно как Ваш инструмент избавит от доработок на стороне сайта. Протоколы, пригодные для программиста 1С, ведет новый модуль обмена сам. Для тонкой диагностики, правда, придется их вести на стороне сайта тоже.
Цель Вашего скрипта в иллюстрация протокола HTTP сомнительна. Нужно уметь читать bash, быть знакомым с программами, использованными в скрипте. Т.е. это совершенно не замена программиста Битрикс и программиста 1С.
Что запуск скрипта возможен только на сервере — это Вы погорячились. Есть люди (я в том числе), которые используют Linux на рабочем ПК. Да и на Windows 10 разрекламирована такая возможность.
Тем не менее, Ваш труд очень полезен.
Спасибо за комментарий!
Пакетный режим, насколько я понимаю, это исключительно терминология 1С, то есть, имеется в виду рассинхронизация процессов формирования пакетов и их отсылки. Сам протокол обмена данными используется тот же. Поэтому, измения в скрипте могут быть только в том плане, что нужно контролировать появление новых файлов, выгружаемых из 1С, и когда они появляются, начинать выгрузку. Это возможно сделать, но сейчас у меня такой задачи нет, поэтому все желающим и карты в руки :-)
А конфигурации 1С могут быть разные, одна из ситуаций, которая у меня была, это как раз невозможность посмотреть лог загрузки.
Это точно не замена программисту Битрикс, а вот программисту 1С — вполне, чтобы не забирать его время.
Насчёт HTTP протокола, это минимальный вариант скрипта, без комментариев, по которому, конечно, люди, не знакомые с командной строкой Linux, ничего не поймут. Но в том и цель, чтобы показать, что есть простые инструменты для таких задач, и поэтому на github есть тот же скрипт с построчными комментариями, а в следующей статье я хочу дать их в ещё более подробном виде.
Да, я тоже давно отказался от Windows на настольном компьютере. :-)
Пакетный режим, насколько я понимаю, это исключительно терминология 1С, то есть, имеется в виду рассинхронизация процессов формирования пакетов и их отсылки. Сам протокол обмена данными используется тот же. Поэтому, измения в скрипте могут быть только в том плане, что нужно контролировать появление новых файлов, выгружаемых из 1С, и когда они появляются, начинать выгрузку. Это возможно сделать, но сейчас у меня такой задачи нет, поэтому все желающим и карты в руки :-)
А конфигурации 1С могут быть разные, одна из ситуаций, которая у меня была, это как раз невозможность посмотреть лог загрузки.
Это точно не замена программисту Битрикс, а вот программисту 1С — вполне, чтобы не забирать его время.
Насчёт HTTP протокола, это минимальный вариант скрипта, без комментариев, по которому, конечно, люди, не знакомые с командной строкой Linux, ничего не поймут. Но в том и цель, чтобы показать, что есть простые инструменты для таких задач, и поэтому на github есть тот же скрипт с построчными комментариями, а в следующей статье я хочу дать их в ещё более подробном виде.
Да, я тоже давно отказался от Windows на настольном компьютере. :-)
Пакетный режим — это разбиение всего каталога, например, из 10000 товаров на пакеты по 100 товаров. Далее каждый пакет отправляется серией CML файлов. В отличие от стандартного модуля обмена, который идет вместе с 1С, этот пакет уйдет не в двух CML файлах, а в семи (товары-метаданные-группы, товары-метаданные-свойства, товары-элементы, предложения-метаданные, предложения-элементы, остатки, цены). Опять таки, в отличие от стандартного модуля, на каждый из этих семи файлов будет открыта отдельная сессия PHP.
Автор, низкий тебе поклон. Буквально последние дни занимаюсь этим вопросом и оптимизацией чего только можно. Пока выгрузки идут напрямую из 1С на сайт, но уже пришёл к выводу, что лучше отправлять готовый набор файлов вручную. В режиме обмена по изменениям в принципе у меня проблем не возникает… когда их не больше тысячи по товарам. Но на сайте у нас более 130 тысяч товаров, и у компании есть планы по увеличению этого количества до какой-нибудь бесконечности. Если сейчас сайт лежит (а сервер даже не напрягается!) даже при обмене по изменениям 16 тысяч позиций, то что будет дальше — ума не приложу. Настройки периодичности и размера пакетов помогают слабо. Нереально найти такой баланс настроек, при котором сайт не тормозил бы, но товары выгружались и обновлялись быстрее. Можно слегка облегчить обмены, разнеся определённые группы товаров в разные обмены.
Так что лично мне этот материал очень кстати, обязательно испробую.
Так что лично мне этот материал очень кстати, обязательно испробую.
Спасибо! Эти мои обмены имеют в виду, что сайт на стандартном обмене отрабатывает нормально. Если есть проблемы с тормозами на стороне сайта, то, может быть, имеет смысл отказаться от стандартного обмена, и использовать свой механизм.
В этом может помочь знание структуры базы данных Битрикса, а это тема одной из моих следующих статей. Если вам нужно срочно, могу выслать материалы, из которых многое в структуре станет понятно.
Как один из вариантов, можно при загрузке данных подключить другую, дублирующую базу, чтобы стандартная выгрузка происходила туда, и тормозила она, а не основной сайт :-) А уже из неё каким-то быстрым вашим собственным скриптом, вставлять данные в рабочую базу сайта.
В этом может помочь знание структуры базы данных Битрикса, а это тема одной из моих следующих статей. Если вам нужно срочно, могу выслать материалы, из которых многое в структуре станет понятно.
Как один из вариантов, можно при загрузке данных подключить другую, дублирующую базу, чтобы стандартная выгрузка происходила туда, и тормозила она, а не основной сайт :-) А уже из неё каким-то быстрым вашим собственным скриптом, вставлять данные в рабочую базу сайта.
Буду благодарен вам за помощь. Вопрос ещё актуален. Прям мозоль какая-то.
Сейчас у нас есть план-Б, аналогичный вашему: выгружать стандартным модулем обмена из 1С нуменклатуру в файлы. Файлы отдельными скриптами отправлять на сервер, который уже фоном намного быстрее обрабатывает импорт XML. Скрипты, скажем, запускаемые по cron, могут быть как shell-овскими, так и php-шными, но суть в том, что они отправляют запрос битриксу так же, как это делает эска. На битриксе сам компонент импорта каталогов стандартный, не дописывался.
Я запилил свой js-скрипт на базе небезысвестного и чрезвычайно корявого bx_1c_import.php. Импорт таким образом пролетает намного быстрее.
Процедура импорта напрямую из 1С сама по себе тормозная, ибо сначала эска подвисает при подготовке одного пакета, потом готовые файлы пакета отправляет на сайт и уже подвисает он в процессе импорта. Когда количество пакетов идёт на сотни, в каждом около 500 элементов, сайт просто захлёбывается. И чем ближе обмен подходит к концу, тем дольше идёт выгрузка данных файл. При том, что пакеты сразу снимаются с регистрации после его импорта в битрикс (?).
Битрикс 15.5.8 УС Бизнес, 1С 8.2 с модулем обмена 4.0.5.1
Сейчас у нас есть план-Б, аналогичный вашему: выгружать стандартным модулем обмена из 1С нуменклатуру в файлы. Файлы отдельными скриптами отправлять на сервер, который уже фоном намного быстрее обрабатывает импорт XML. Скрипты, скажем, запускаемые по cron, могут быть как shell-овскими, так и php-шными, но суть в том, что они отправляют запрос битриксу так же, как это делает эска. На битриксе сам компонент импорта каталогов стандартный, не дописывался.
Я запилил свой js-скрипт на базе небезысвестного и чрезвычайно корявого bx_1c_import.php. Импорт таким образом пролетает намного быстрее.
Процедура импорта напрямую из 1С сама по себе тормозная, ибо сначала эска подвисает при подготовке одного пакета, потом готовые файлы пакета отправляет на сайт и уже подвисает он в процессе импорта. Когда количество пакетов идёт на сотни, в каждом около 500 элементов, сайт просто захлёбывается. И чем ближе обмен подходит к концу, тем дольше идёт выгрузка данных файл. При том, что пакеты сразу снимаются с регистрации после его импорта в битрикс (?).
Битрикс 15.5.8 УС Бизнес, 1С 8.2 с модулем обмена 4.0.5.1
Скрипты, скажем, запускаемые по cron, могут быть как shell-овскими, так и php-шными, но суть в том, что они отправляют запрос битриксу так же, как это делает эска.Зачем так, если все равно делаете по-своему? Тогда уж импорт по cron PHP скриптом на API Битрикс.
Мне приходилось так делать, когда программист 1С не захотел доделывать модуль обмена со стороны 1С (для нестандартной логики). Кидали из 1С файл по ftp на сервер с сайтом, там по cron разбирали.
на базе небезысвестного и чрезвычайно корявого bx_1c_import.php.Его поезд давно ушел. Был актуален до обмена 3 включительно. На четвертом и далее он может помочь, но нужно понимать что делаешь.
Когда количество пакетов идёт на сотни, в каждом около 500 элементов, сайт просто захлёбывается.Пропускать обработку по контрольным суммам уже пробовали?
Пропускать обработку по контрольным суммам уже пробовали?
Программист 1С понизил объёмы выгрузок иным путём. Специфика нашей компании такова, что в нашу 1с дополнительно парсится нуменклатура сторонних поставщиков, и она каждый день меняется в большом своём количестве. Один такой каталог на 30 тысяч товаров, второй почти такой же, да плюс свой как они вместе взятые. Далее это всё дело летит на сайт, естественно, в режиме изменений, но повторюсь — объёмы колоссальны.
Так вот изначально в 1с теперь залетают только изменившиеся в стороннем прайсе позиции. Т.о. меньше позиций в нашей базе стали помечаться изменёнными, соответственно, и общий объём понизился. Больше никаких изменений на стороне 1с не производилось. Таких настроек даже не имеется, а корячить своё… программист сейчас слишком занят более приоритетными задачами, так что пока корячимся сами, битриксоиды.
На четвертом и далее он может помочь, но нужно понимать что делаешь.
В нашей среде его даже запустить не удалось толком. Он мне помог только состряпать свой скрипт) Взял самый важный кусок и завернул в свой интерфейс.
Если долго импортируются товары — проверьте настройки генерации карты сайты и текущее количество файлов карты
Они не импортируются долго, а экспортируются из 1С в файлы. А импортируются на сайт тяжело. К слову, карты сайта пока нет: лечим как раз структуру каталога, чтобы sitemap'ы генерировать адекватные.
я это к чему. у нас каталог 5-6 тысяч активных товаров, 40-60 тысяч активных предложений.
1С у нас пока что нет, учетная программа на Access'е с БД на MS SQL
Полное время импорта занимало когда-то час, потом 2, 3 и т.д. до 6 часов.
Импорт предложений всегда занимал примерно одно и тоже время 20-30 минут, а время импорта товаров неуклонно росло, несмотря на отсутствие значительного роста количества товаров.
И только через 3 года случайно обнаружили (место стало заканчиваться на хостинге) 102 файлика инфоблока товаров карты сайта. Удалив все и перегенериров карту — получили 1 файл и…
Общее время импорта данных — 50 минут
Выяснили, что при включенной автогенерации карты сайта, он при каждой деактивации товара — ищет ссылку на товар в карте сайта и заменяет ее на… пробелы! А новые товары после превышения лимита на размер файла с данными карты пишет в следующий и следующий файлы.
Все тормоза во времени импорта товаров были связаны с тем, что ему приходилось при каждой деактивации товаров искать ссылку на товар, открывая помещенный в память файл-xml и т.д. пока он не находил нужные данные
Отправил материалы личным сообщением. Да, я тоже начал с bx_1c_import, но так же быстро оставил его...)
— потому что при импорте полностью заполняется таблица b_xml_tree. В начале импорта она пустая.
И чем ближе обмен подходит к концу, тем дольше идёт выгрузка данных файл.
— потому что при импорте полностью заполняется таблица b_xml_tree. В начале импорта она пустая.
потому что при импорте полностью заполняется таблица b_xml_tree. В начале импорта она пустая.Она чистится на каждом пакете. В этом смысл пакетного режима — отдавать по частям каталог.
Ну да, если представить, что каждый такой «пакет» — это полный цикл инкрементальной выгрузки, содержащей часть каталога, то это как раз вписывается в общую логику работы, потому что ведь инкрементальных выгрузок может идти поряд сколько угодно, и в частном случае это будет разбитый на части (пакеты) каталог.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандартный обмен 1С-Битрикс на BASH: инкрементальная выгрузка XML файлов каталога import и offers