Обмен 1С с сайтом через API: когда CommerceML уже не справляется

Обмен через API нужен, когда сайту требуются данные в реальном времени, а не раз в час по расписанию: остатки, статусы заказов, персональные цены. CommerceML для этого слишком медленный и неповоротливый, поэтому магазины с высокой нагрузкой переходят на REST или OData.

Чем обмен через API отличается от CommerceML?

CommerceML — это обмен файлами: 1С формирует XML-документ с товарами или заказами, сайт его забирает и обрабатывает. Работает по расписанию, обычно раз в 15–60 минут, и требует, чтобы оба модуля обмена — на стороне 1С и на стороне сайта — понимали одинаковый формат файла.

API-обмен устроен иначе: сайт и 1С обмениваются не файлами, а прямыми запросами через интернет, как два приложения, которые разговаривают друг с другом на лету. Если покупатель кладёт товар в корзину, сайт может тут же спросить у 1С актуальный остаток и получить ответ за доли секунды, а не ждать следующей выгрузки.

В каких случаях без API уже не обойтись?

Есть несколько типичных ситуаций, где CommerceML начинает буксовать:

• магазин продаёт товары с быстро меняющимися остатками — стройматериалы, электронику, скоропортящиеся товары;
• у сайта персональные цены для разных клиентов или B2B-каталог с индивидуальными прайсами;
• нужно синхронизировать статусы заказов в обе стороны почти мгновенно — например, для склада с ручной сборкой;
• ассортимент огромный, и полная выгрузка XML-файла занимает слишком много времени и нагружает сервер.

Если ничего из этого не про ваш бизнес — обычный товарный каталог на несколько сотен позиций и заказы, которые можно обрабатывать раз в час, — CommerceML вполне справится, и городить API-обмен смысла нет.

Что такое REST и OData простыми словами?

Оба протокола — способы «достучаться» до 1С извне. OData — встроенный в 1С стандарт, который позволяет обращаться к базе почти как к таблице: запросить список товаров, отфильтровать по складу, обновить остаток одной командой. Он появился в 1С относительно давно и хорошо документирован, поэтому его часто выбирают как более простой вариант.

REST API — более гибкий подход, где под конкретные задачи пишут собственные обработчики HTTP-сервисов внутри 1С. Это требует больше программирования, зато позволяет отдавать сайту ровно те данные и в том виде, в каком ему удобно, без лишней нагрузки на базу.

Нужен ли отдельный сервер для такого обмена?

Да, и это важный момент. Чтобы 1С могла принимать запросы из интернета, база должна быть опубликована на веб-сервере с постоянным доступом — обычно через специальный модуль расширения веб-сервера. Держать такую конфигурацию на обычном офисном компьютере рискованно: при падении интернета или перезагрузке сайт мгновенно теряет связь с учётной системой, а заказы начинают копиться без обработки.

Поэтому для API-обмена практически всегда нужен выделенный сервер с постоянной работой 24/7 и стабильным каналом связи. Здесь удобно взять готовую 1С в облаке: база работает на защищённых серверах провайдера, доступна из интернета без дополнительной настройки инфраструктуры, а нагрузку можно наращивать по мере роста магазина. Именно так организован сервис «Клауд АйСи» — арендованная 1С в облаке с публикацией по API уже готова принимать запросы от сайта, не требуя от бизнеса своего сервера и системного администратора.

Что будет с производительностью 1С при частых запросах?

Здесь и кроется главный подводный камень API-обмена. Если сайт с большой посещаемостью на каждый клик покупателя дёргает 1С напрямую, база быстро начинает тормозить — особенно если параллельно с ней работают бухгалтеры и менеджеры. Поэтому опытные интеграторы часто ставят между сайтом и 1С промежуточный слой — кеш остатков и цен, который обновляется из 1С по расписанию, а сайт читает именно из него, а не из самой базы. Это сохраняет скорость обмена и одновременно снимает нагрузку с учётной системы.

Интересный факт: сам протокол HTTP, на котором строится любой REST-обмен, был разработан ещё в начале 1990-х как способ передавать гипертекстовые документы между компьютерами — и с тех пор стал универсальным языком, на котором «разговаривают» практически все современные веб-сервисы, включая 1С.

Как передавать заказы обратно в 1С через API?

Схема зеркальная: когда покупатель оформляет заказ на сайте, тот же HTTP-сервис принимает данные — товары, количество, контакты покупателя — и создаёт документ заказа прямо в базе 1С. Важно продумать обработку ошибок: что произойдёт, если 1С в момент заказа временно недоступна. Обычно для этого сайт сохраняет заказ у себя и ставит его в очередь на повторную отправку, чтобы ни один заказ не потерялся из-за короткого сбоя связи.

Можно ли совместить API и CommerceML в одном магазине?

Да, и это распространённая практика. Например, полный каталог товаров с описаниями и картинками выгружается по CommerceML раз в сутки — это не критичные к скорости данные. А остатки и цены, которые должны быть максимально свежими, подтягиваются через API в реальном времени. Такой гибридный подход снижает нагрузку на базу и при этом сохраняет актуальность там, где это действительно важно.

С чего начать настройку API-обмена?

Сначала стоит честно оценить, действительно ли нужен обмен в реальном времени, или достаточно ускорить обычный CommerceML, сократив интервал выгрузки. Если API нужен, порядок такой: разместить базу 1С на сервере с постоянным доступом из интернета, включить и настроить публикацию веб-сервиса (OData или собственный REST-модуль), закрыть доступ авторизацией и ограничением по IP, а затем на стороне сайта написать модуль, который будет отправлять запросы и обрабатывать ответы. На каждом этапе стоит тестировать обмен на небольшом объёме данных, прежде чем включать его на боевом каталоге.