Поддержка параллельной выгрузки каталога из 1С на сайт
В силу специфики настройки расписания рано или поздно возникает ситуация, когда одновременно работает два обмена. Это приводит к потере таблицы b_xml_tree и обрушению обмена.
Чтобы выгрузка каталога могла работать в нескольких сеансах обмена одновременно (напомню, профиль обмена можно настроить так, что выгружаться будут только остатки, цены ... и с разным графиком) нужно обеспечить изоляцию сеансов на двух уровнях - файлы и БД (пресловутая таблица b_xml_tree).
Изоляция по файлам возможна, если воспользоваться параметром USE_TEMP_DIR компоненты bitrix:catalog.import.1c.
С изоляцией по БД ситуация запутана. С одной стороны есть API:
С другой стороны, в компоненте обмена оно не используется!!! Кстати, сходу и не найдешь где оно вообще используется.
В поддержке (обращение 2380113 "Поддержка паралелльных выгрузок каталога на сайт") мне сообщили:
Предлагаю переработать логику так, чтобы это было возможно. Предложение касается классического XML обмена. Но может затронуть (надеюсь, что нет) и REST обмен.
Чтобы выгрузка каталога могла работать в нескольких сеансах обмена одновременно (напомню, профиль обмена можно настроить так, что выгружаться будут только остатки, цены ... и с разным графиком) нужно обеспечить изоляцию сеансов на двух уровнях - файлы и БД (пресловутая таблица b_xml_tree).
Изоляция по файлам возможна, если воспользоваться параметром USE_TEMP_DIR компоненты bitrix:catalog.import.1c.
С изоляцией по БД ситуация запутана. С одной стороны есть API:
- \CIBlockXMLFile::StartSession
- \CIBlockXMLFile::EndSession
- \CIBlockXMLFile::GetSessionRoot
С другой стороны, в компоненте обмена оно не используется!!! Кстати, сходу и не найдешь где оно вообще используется.
В поддержке (обращение 2380113 "Поддержка паралелльных выгрузок каталога на сайт") мне сообщили:
| В настоящий момент логика обмена такова, что изменить ее под несколько параллельных потоков выгрузки нельзя. |
Предлагаю переработать логику так, чтобы это было возможно. Предложение касается классического XML обмена. Но может затронуть (надеюсь, что нет) и REST обмен.
© 2001-2022 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Если штатный обмен устраивает,
то можно написать свою простенькую систему очередей. Таблица в БД с сообщениями.
Из 1С приходят запросы на импорт - добавляете в таблицу соответствующую запись.
На сайте уже кроном читаете, или другим способом читаете очередь и импортируете.
Либо можно воспользоваться другими готовыми системами очередей, на базе redis, rabbitmq, tarantool
то можно написать свою простенькую систему очередей. Таблица в БД с сообщениями.
Из 1С приходят запросы на импорт - добавляете в таблицу соответствующую запись.
На сайте уже кроном читаете, или другим способом читаете очередь и импортируете.
Но, все-таки, такие вещи должны быть в штатной комплектации. Что каждый во что горазд можно даже и не писать. Это ясно. Если бизнес заставит, сделаешь и не такое. И ждать не будет ни CommerceML, ни REST.
Но потом написали свой модуль Параллельный и ускоренный обмен с 1С
Как выяснилось, что кроме нескольких баз нужно еще что-то делать с деактивацией. Параллельно деактивации не работают как надо. Для случая, когда параллельно выгружаются товары в один инфоблок тоже надо что-то придумывать.
Да, меня тоже смущают деактивации. Также беспокоят обновления метаданных инфоблоков.
Не использовал Ваш модуль не только из-за цены (хотя, вопросы мне бы задавали). Цена на такой сложной разработке отобьется. Но только если делать обмен с нуля, на новом проекте. У меня уже было много наработок. Внедрять стороннее решение на этом фоне проблематично. Пришлось развивать свое. Отчуждаемым это решение я не делал. Скрипт обмена там один. Никаких настроек параллелизма со стороны сайта не требуется.