1) Самый частый сценарий: «каталог в одну сторону, заказы — в другую»
Поток A: 1С → сайт
- номенклатура (товары/услуги)
- характеристики, свойства, картинки
- цены (несколько типов)
- остатки по складам или сводно
Поток B: сайт → 1С
- заказы интернет-магазина
- контрагенты/контакты (по правилам)
- оплаты/доставки (часто — только статусы)
- статусы заказов обратно на сайт (опционально)
2) Способ №1 (по умолчанию): типовой обмен CommerceML
Что это такое
CommerceML + «протокол обмена с сайтом» — классический подход, где 1С и сайт обмениваются пакетами данных (обычно XML), по шагам/командам обмена.
Когда выбирать
- у вас интернет-магазин
- нужны типовые сущности: каталог/цены/остатки/заказы
- нужен быстрый старт без «тяжёлой» разработки API
- у CMS есть готовый модуль обмена (особенно для 1С-Битрикс)
Плюсы
- быстро запускается на типовых конфигурациях
- хорошо подходит для каталогов и заказов
- понятная эксплуатация (регламент обмена, пакеты)
Минусы / ограничения
- обмен пакетный (не всегда real-time)
- сложнее делать нестандартные бизнес-объекты и правила
- чувствителен к качеству справочников и идентификаторам
- сложнее отлаживать «частные» кейсы без логирования
Практические рекомендации
- сразу договоритесь, кто “мастер-данных”:
- справочник товаров и цены обычно мастерятся в 1С
- контент (SEO, тексты) часто мастерится на сайте
- используйте единые идентификаторы (в идеале — GUID/внешние коды)
- разделяйте обмен: каталог отдельно, цены/остатки отдельно, заказы отдельно
- делайте регламент: когда и как часто гоняем обмен, как обрабатываем ошибки
3) Способ №2: интеграция через модуль 1С-Битрикс (CommerceML v2)
Если сайт на 1С-Битрикс, обычно рационально начинать с его стандартных механизмов обмена.
Типовая схема
- 1С выгружает каталог (и отдельно цены/остатки)
- сайт принимает и обновляет каталог
- сайт отдает заказы в 1С
- при необходимости — синхронизируются статусы
Плюсы
- очень распространённый стек, много готовых практик
- поддерживает импорт/экспорт в формате CommerceML v2
- меньше кастомной разработки на старте
Минусы
- кастомизация обмена требует аккуратности (чтобы не сломать при обновлениях)
- важно заранее настроить соответствие полей, статусов, оплат/доставок
4) Способ №3: API-подход через HTTP-сервисы 1С (когда нужен контроль и real-time)
Что это такое
В 1С можно сделать собственные HTTP-эндпоинты: сайт/бекенд обращается к 1С по HTTPS и получает/пишет данные по вашим правилам.
Когда выбирать
- нужен real-time (например, резервы, статусы, персональные цены)
- много нестандарта: сложные правила ценообразования, остатки по складам, ограничения, персональные условия
- нужно аккуратно управлять тем, что именно отдаём наружу
- хотите уйти от пакетного обмена и XML
Плюсы
- гибкость: вы описываете контракт сами
- можно делать тонкие операции: “проверить остаток”, “создать заказ”, “поставить резерв”, “вернуть статус”
- удобнее мониторить и версионировать API
Минусы
- это разработка и сопровождение (контракты, версии, безопасность, нагрузка)
- нужен грамотный контроль ошибок и повторов (idempotency)
Практический “боевой” шаблон
- Сайт создаёт заказ в своём контуре
- Сайт вызывает
POST /orders в 1С → получает order_id из 1С
- Сайт периодически получает статусы через
GET /orders/{id}/status
- 1С через регламентные задания подтягивает оплаты/отгрузки и обновляет статусы
5) Способ №4: REST/OData интерфейс (когда нужно быстро открыть доступ к объектам)
Что это такое
OData в 1С — стандартный REST-подход, который позволяет читать/создавать/изменять данные прикладного решения (в пределах настроек публикации и прав).
Когда выбирать
- нужен быстрый доступ к данным 1С для сайта/витрины/личного кабинета
- нужно “читать много, писать мало”
- вы готовы ограничить набор публикуемых объектов и строго настроить права
Плюсы
- быстрее старт, чем полностью кастомные сервисы
- много готовых клиентов/библиотек
Минусы
- надо внимательно настроить публикацию и безопасность
- не всегда удобно выражать сложную бизнес-логику (часто всё равно упрётесь в кастом)
6) Способ №5: SOAP Web-services (когда требуется совместимость/корпоративные интеграции)
Когда применяют
- исторически сложившиеся интеграции (у партнёров/подрядчиков уже есть SOAP)
- корпоративные контуры, где стандартизированы WSDL/SOAP
- интеграции “по операциям” (создать заказ, получить документ, получить статус)
Плюсы
- зрелый подход, совместимость со многими корпоративными системами
Минусы
- тяжеловат для веб-разработки по сравнению с REST
- сложнее дебажить и поддерживать контракты “на лету”
7) Способ №6: промежуточный слой (очередь/шина/ETL) — когда интеграций много
Когда это нужно
- 1С ↔ сайт — не единственная интеграция (ещё CRM, склад, маркетплейсы, доставки)
- надо разнести нагрузку и сделать обмен устойчивым
- важны ретраи, очереди, “не потерять сообщение”
Как выглядит
- 1С публикует события (изменился товар, изменилась цена, пришла оплата)
- сайт потребляет события из очереди и обновляет витрину
- заказы идут в обратную сторону тоже через очередь/шину
8) Как выбрать подход: быстрый “навигатор”
Выбирайте CommerceML, если
- типовой интернет-магазин
- нужно быстро и “как у всех”
- устраивает пакетный обмен
Выбирайте HTTP-сервисы/API, если
- нужна точность и real-time
- много нестандартных правил
- важна контролируемая архитектура и версионирование
Выбирайте OData, если
- нужно быстро открыть часть данных 1С наружу
- интеграция больше про чтение и витрины
Выбирайте шину/очередь, если
- интеграций много и нужно промышленное качество (SLA, ретраи, события)
9) Обязательные технические требования, которые обычно забывают (и потом страдают)
9.1 Идентификаторы и сопоставление сущностей
- единые ключи (GUID/внешний код)
- правила сопоставления контрагентов (по телефону? email? ИНН?)
- стратегия по дублям (что считаем дублем, кто чистит)
9.2 Идемпотентность и повторы
Если сайт отправил заказ дважды (таймаут/повтор) — 1С не должна создавать две одинаковые продажи.
- используйте “внешний номер заказа” + проверку дубля
- храните “ключ операции” (request_id) и журнал обработок
9.3 Очереди/пакеты/нагрузка
- не гоняйте огромный каталог в пиковые часы
- разделяйте “полную выгрузку” и “дельту”
- оптимизируйте картинки (CDN/отдельный контур хранения)
9.4 Логи и мониторинг
Минимум:
- журнал обмена (вход/выход, ошибки, время, размер пакетов)
- алерты (если обмен упал/завис)
- возможность повторить пакет/сообщение
9.5 Безопасность
- только HTTPS
- отдельные сервисные учетные записи с минимальными правами
- ограничение IP (если возможно)
- подпись/токены, ротация секретов
10) Типовые грабли (и как их избежать)
-
“Справочники в бардаке” → обмен начинает плодить дубли и мусор
Решение: нормализовать номенклатуру, единицы, характеристики, коды.
-
“Сайт и 1С по-разному понимают цену”
Решение: фиксировать правила: типы цен, валюты, НДС, округления.
-
“Остатки не сходятся”
Решение: договориться, что такое остаток для сайта: свободный? с учетом резервов? по складам?
-
“Обмен работает только у одного человека”
Решение: регламент, роли, документация, мониторинг, журналирование.
-
“Хотим всё в real-time, но инфраструктура не готова”
Решение: гибрид: каталог/цены пакетно, критичные операции — через API.
11) Рекомендуемый план внедрения (чтобы сделать нормально)
Этап 1 (1–2 недели): “живой” MVP
- выбрать метод (обычно CommerceML или API на 2–3 операции)
- настроить базовый обмен каталогом и заказами
- включить логи и простой мониторинг
- проверить сценарии: оформление заказа, отмена, оплата, частичная отгрузка
Этап 2 (2–6 недель): устойчивость
- дельта-обмен, оптимизация производительности
- обработка ошибок и повторов
- правила по дублям и идентификаторам
- выверка цен/остатков/статусов
Этап 3 (6–12 недель): масштабирование
- расширение на персональные цены, резервы, бонусы
- очереди/шина (если нужно)
- аналитика качества интеграции (ошибки, задержки, SLA)
Итог
Практически всегда выигрывает подход “по-взрослому”:
- типовой обмен (CommerceML) — для базовой механики магазина
- API (HTTP-сервисы) — для критичных операций и нестандарта
- OData/REST — для витрин и чтения
- очередь/шина — когда нужен промышленный контур интеграций
Главное — не выбор технологии сам по себе, а дисциплина: идентификаторы, правила данных, логи, повторы, безопасность и регламент эксплуатации.