Стандартный обмен по CommerceML — рабочая лошадка, но у неё есть предел. Рассказываем, как понять, что вы упёрлись в потолок, и что даёт переход на обмен через REST API: на замерах, без религиозных войн.
Когда CommerceML хватает
Где потолок
CommerceML — это XML-файлы, которые собираются на стороне 1С, выгружаются на сайт и разбираются целиком. При 100 000+ SKU файл выгрузки весит сотни мегабайт, разбор съедает минуты процессора, а изменение одного товара всё равно тащит за собой пакет. Наши замеры на стенде (1С:УТ 11.4, Битрикс 23.x, 120 000 SKU):
Архитектура REST-обмена
Со стороны сайта создаётся вебхук с правами на catalog и sale, со стороны 1С — регламентное задание, которое при изменении документа/номенклатуры ставит событие в очередь и отправляет на сайт пачками через batch. Идемпотентность — по GUID объектов: повторная отправка того же GUID не создаёт дубликат.
Гибрид — наш выбор по умолчанию
Мы почти всегда делаем гибрид: первичную загрузку каталога — CommerceML-ом (надёжно, проверено), а оперативные дельты (остатки, цены, статусы заказов) — вебхуками по REST. Так заказчик получает и быструю реакцию на изменения, и простой откат к стандартному обмену, если что-то пойдёт не так.