Прежде чем сравнивать — важная оговорка: ни один из трёх подходов не «плохой» сам по себе. У каждого есть ниша, в которой он оптимален. Проблемы начинаются, когда бизнес перерастает подход, который выбрал на старте, и продолжает эксплуатировать его вместо того, чтобы пересмотреть архитектуру интеграции.
Три архитектурных подхода к интеграции 1С с маркетплейсом
Исторически интеграция 1С с внешними системами прошла через три поколения подходов. Понимание того, откуда они взялись, помогает объективно оценить, какой годится именно для вашего масштаба.
1. Файловый обмен (выгрузка CommerceML/XML)
Самый старый подход: 1С выгружает файл с остатками и ценами в формате CommerceML или произвольном XML, файл забирает промежуточный сервис или сам маркетплейс через FTP/HTTP. Это надёжно в смысле совместимости — формат понимают почти все системы — но по определению не может быть быстрее, чем интервал между выгрузками файла, обычно от 15 минут до нескольких часов. Для розницы с редко меняющимся ассортиментом (мебель, оборудование) такой задержки достаточно. Для маркетплейса с частыми продажами — нет.
2. Обработка на встроенном языке 1С
Сегодня это самый распространённый подход у интеграторов: внешняя обработка, написанная на встроенном языке 1С, обращается к API маркетплейса напрямую через HTTP-запросы из самой 1С, запускается по регламентному заданию. Формат ближе к «настоящей» интеграции по API, чем файловый обмен, но выполняется внутри той же системы, что и весь остальной учёт.
3. Отдельный сервис на внешнем языке (Symfony-коннектор)
Интеграция выделена в отдельный сервис вне 1С, который обращается к 1С через OData, а к маркетплейсу — через его API, и работает по событийной модели с очередью сообщений. Это подход, который используют высоконагруженные интеграции — например, у крупных ритейлеров с десятками тысяч SKU.
Обработка на встроенном языке 1С: сильные и слабые стороны
Никаких промежуточных слоёв — обработка напрямую читает и пишет в базу 1С, что удобно для несложных сценариев и небольших объёмов.
Запускается внутри самой 1С по регламентному заданию — не нужен отдельный сервер, Docker или очередь сообщений.
Дорабатывать может штатный 1С-специалист без привлечения PHP/Symfony-разработчика — это снижает порог входа для небольшой компании.
Пока обработка ждёт ответ от Ozon API, регламентное задание 1С заблокировано целиком — при недоступности маркетплейса встают вообще все операции внутри этого задания, а не только обмен с Ozon.
Встроенный язык 1С не даёт из коробки паттернов retry с backoff, dead-letter очередей или rate limiter — это либо пишется вручную и плохо покрывается тестами, либо просто отсутствует.
Обработка встроена в конфигурацию или подключена как расширение — при обновлении типовой конфигурации 1С есть риск конфликта, который придётся разбирать вручную.
Логи обычно пишутся в текстовый файл или таблицу внутри 1С — без интеграции с внешними системами мониторинга вроде Prometheus/Grafana узнать о проблеме получится только по жалобе клиента.
Каждый запрос к API маркетплейса выполняется в том же процессе, что и обычная работа пользователей в базе — при большом объёме обмена это может ощутимо сказываться на скорости работы 1С для остальных сотрудников.
Symfony-коннектор: тот же обмен, другая архитектура
Событие (изменение остатка, новый заказ) попадает в очередь и обрабатывается отдельным consumer-процессом. Недоступность Ozon API не блокирует ничего внутри 1С — сообщения просто ждут своей очереди.
Это готовые паттерны Symfony Messenger, а не самописный код внутри обработки — retry с экспоненциальной паузой и очередь для «застрявших» сообщений работают предсказуемо и покрыты тестами фреймворка.
Consumer-процессов можно запустить несколько параллельно — при росте каталога до десятков тысяч SKU это просто увеличение числа воркеров, а не переписывание логики.
Коннектор — отдельный сервис, который общается с 1С через OData. Обновление типовой конфигурации 1С никак не затрагивает код коннектора.
DTO, отдельные классы клиентов API, DI-контейнер — всё это позволяет писать unit- и функциональные тесты так, как это принято в PHP-экосистеме, а не проверять руками после каждого изменения.
Отдельный сервис легко подключается к стандартным инструментам мониторинга — логи, метрики очереди, алерты при росте dead-letter — то, что сложно организовать внутри 1С.
Честно: это плата за гибкость — нужен сервер (или контейнер) под сам сервис и под очередь сообщений. Для магазина с сотней SKU это может быть избыточно, для растущего каталога — оправданная инвестиция.
Штатный 1С-программист, скорее всего, не сможет самостоятельно внести изменения в код коннектора — потребуется либо своя команда с нужным стеком, либо подрядчик.
Прямое сравнение по ключевым критериям
| Критерий | Файловый обмен | Обработка 1С | Symfony-коннектор |
|---|---|---|---|
| Задержка обновления | Часы | Минуты | Секунды |
| Retry при сбое API | Нет | Только если написано вручную | Из коробки |
| Нужна отдельная инфраструктура | Часто нет | Нет | Да |
| Нагрузка на базу 1С | Минимальная | Есть, растёт с объёмом | Нет (вынесена наружу) |
| Кто дорабатывает | 1С-программист | 1С-программист | PHP/Symfony-разработчик |
| Практический потолок по SKU | До ~1 000 | До ~5 000–10 000 | Практически не ограничен |
Цифры по «практическому потолку» — ориентировочные, основаны на типичной нагрузке для розничного каталога с несколькими обновлениями цен/остатков в день; для вашего конкретного сценария (частота обновлений, число площадок) потолок может отличаться в обе стороны.
Как выбрать подход для своего бизнеса
Задайте себе три вопроса:
Сколько у вас SKU и как часто меняются остатки? До пары сотен позиций и обновления раз в час — файлового обмена или простой обработки достаточно. Тысячи позиций с постоянным движением — нужна событийная модель.
Сколько стоит вам одна отменённая заявка? Если штрафы и потери от рассинхрона уже заметны в отчётности — это сигнал, что архитектурный потолок текущего решения достигнут.
Кто будет поддерживать интеграцию дальше? Если в штате есть только 1С-разработчик — миграция на отдельный сервис означает либо обучение, либо привлечение подрядчика на сопровождение.
Часто задаваемые вопросы
Можно ли начать с обработки на 1С и потом перейти на отдельный сервис?
Да, это обычный путь роста. Если данные и бизнес-логика не завязаны намертво на специфику обработки, миграция на отдельный сервис — это в первую очередь смена способа доступа к 1С (через OData вместо внутреннего кода), а не полная переработка бизнес-процессов.
Нужен ли отдельный сервер для Symfony-коннектора?
Да, минимально — виртуальная машина или контейнер, где крутится сам сервис и очередь сообщений (например, через Docker Compose, как в open-source коннекторе). Для среднего интернет-магазина это недорогая часть инфраструктуры по сравнению со стоимостью самого рассинхрона.
Правда ли, что файловый обмен уже устарел?
Не для всех сценариев. Для B2B-каналов, где партнёр сам ожидает прайс-лист в определённом формате раз в сутки, файловый обмен по-прежнему адекватен. Для розничного маркетплейса с частыми продажами — нет, задержка в часы там напрямую конвертируется в отменённые заказы.
Итог
Если каталог небольшой, синхронизация не критична к задержкам в несколько минут, а обновлять конфигурацию 1С вы планируете редко — типовая обработка вполне справится, и городить отдельный сервис не имеет смысла.
Если счёт идёт на тысячи SKU, растёт число заказов, а рассинхрон уже стоит вам штрафов и потери рейтинга — разница в архитектуре перестаёт быть теоретической. Именно поэтому коннектор 1С ↔ Ozon мы делали не как обработку внутри 1С, а как отдельный сервис — с расчётом, что он будет расти вместе с бизнесом, а не упрётся в архитектурный потолок через год.
