Почти любая интеграция 1С с внешней витриной начинается одинаково: ночная выгрузка остатков в файл, загрузка на стороне сайта, все довольны. Работает это ровно до первой корректировки задним числом — и дальше начинается то, ради чего пишется эта статья.
Разберём, где такие обмены рвутся и какая архитектура это переживает.
Проблема снимка
Классический обмен устроен как снимок: в момент T выгружаем остатки по всей номенклатуре, отправляем, витрина обновляется. Логика простая и понятная, но у неё есть свойство, которое обнаруживается не сразу.
1С пересчитывает остатки задним числом. Провели приёмку вчерашним числом — регистр пересчитался, и снимок, отправленный сегодня утром, стал неверным раньше, чем ушёл следующий цикл. На складе с активным движением расхождение копится быстрее, чем его успевает исправить следующая выгрузка.
Дальше это выглядит так: сайт молча торгует нулями по позициям, которые есть, или продаёт то, чего нет. На маркетплейсе второе стоит дороже — там за отмену по вине продавца прилетает штраф.
Увеличение частоты выгрузки не помогает: вы упираетесь в нагрузку на базу и в лимиты API площадок, а корень проблемы остаётся.
Событийная модель
Рабочая альтернатива — публиковать не состояние, а факт изменения. 1С при изменении остатка или цены по позиции публикует событие: что изменилось, когда, на какое значение. Интеграционный слой снаружи это событие обрабатывает.
Что это меняет по сути:
Во-первых, пересчёт задним числом перестаёт быть проблемой — он сам по себе является событием и уходит в очередь наравне с остальными.
Во-вторых, объём трафика падает на порядок: вы передаёте изменения, а не всю номенклатуру каждый цикл.
В-третьих, появляется возможность приоритизации. Событие «позиция ушла в ноль» можно отправлять вне очереди, потому что цена ошибки здесь выше, чем у обычного изменения количества.
Дополнение, без которого модель неполна: staging сырых данных. Все ответы 1С и площадок стоит сохранять как есть, а витрины пересчитывать из них. Тогда при расхождении вы разбираете сохранённые данные, а не пытаетесь воспроизвести состояние, которого больше нет.
Как не открывать 1С наружу
Требование «1С не должна иметь внешнего IP» звучит на каждом втором проекте, и оно разумное. Прямая публикация HTTP-сервисов 1С в интернет — это ваш периметр безопасности, натянутый на приложение, которое для этого не проектировалось.
Схема, которая снимает вопрос: между 1С и внешним миром ставится очередь сообщений. 1С изнутри периметра публикует события в брокер, интеграционный слой снаружи их читает. Входящих подключений к 1С из интернета нет вообще.
Обратное направление — приём заказов — работает так же: внешний слой кладёт заказ в очередь, обработчик на стороне 1С забирает и проводит документ.
Практическая деталь: бизнес-логику имеет смысл держать в HTTP-сервисах на стороне 1С, а не тянуть наружу. Расчёт оптовых цен по уровням, резервы, правила скидок — всё это живёт в конфигурации и меняется вместе с ней. Если продублировать эту логику в интеграционном слое, вы получите два источника правды и расхождение при первом же изменении ценовой политики. OData удобна для первичной выгрузки справочников, но бизнес-логику через неё тащить не стоит.
Лимиты частоты у площадок
Отдельная тема, которую обычно обнаруживают на проде.
Пока изменений мало, событийная модель отправляет их по одному, и всё хорошо. Но приходит массовая смена прайса на пару тысяч позиций — и прямая отправка каждого изменения упирается в ограничения API маркетплейса. Часть запросов отклоняется, и вот у вас снова расхождение, только теперь оно рождено самой системой синхронизации.
Решение — буферизация: изменения копятся несколько минут и уходят пакетами в пределах лимита площадки. Но с одной оговоркой, которая важнее самого буфера: критичные события идут вне очереди. Обнуление остатка не должно ждать в буфере пять минут — за это время успеют оформить заказ на то, чего нет.
То есть буфер не просто сглаживает нагрузку, а разделяет поток по приоритетам.
Сопоставление артикулов — не деталь, а ядро
У 1С, сайта и каждой площадки свой идентификатор номенклатуры. Пока позиций немного, сопоставление живёт в голове менеджера или в его же Excel-файле, и это работает.
Ломается это в момент, когда менеджер уходит в отпуск, а новую позицию нужно вывести на четыре витрины. Без явной таблицы соответствия «1С ↔ сайт ↔ площадка 1 ↔ площадка 2» любая автосинхронизация раскладывает мусор по всем каналам сразу.
Таблицу стоит делать отдельной сущностью с интерфейсом, где сопоставление ведёт менеджер, а не разработчик по заявке. И обязательно — счётчик несопоставленных позиций в мониторинге: рост этого числа означает, что новые товары уходят в никуда.
Сверка обязательна
Событийная модель не отменяет полную сверку, а дополняет её. Раз в сутки имеет смысл сравнивать остатки между 1С и каждой площадкой и отдавать отчёт о расхождениях.
Причина простая: события теряются. Брокер перезапустился, обработчик упал на конкретном сообщении, площадка приняла запрос и не применила его. Без регулярной сверки вы узнаете об этом от покупателя.
Сверка — это ещё и способ измерить качество обмена. Число расхождений за сутки — метрика, по которой видно деградацию до того, как она станет заметной в деньгах.
Наблюдаемость
Минимальный набор, без которого интеграцию нельзя считать законченной:
- логирование каждой операции обмена с сохранением сырых запросов и ответов;
- алерты в мессенджер команды: очередь встала, площадка вернула ошибку, растёт число несопоставленных позиций;
- метрики в дашборде — задержка от изменения в 1С до обновления на витрине, число ошибок, доля расхождения по сверке.
Ключевой критерий: о сбое обмена команда должна узнавать из мониторинга, а не от продавца или покупателя. Если первым о проблеме сообщает клиент, наблюдаемости у вас нет.
Итог
Обмен 1С с внешними витринами ломается не там, где кажется на старте. Файловые выгрузки и снимки остатков выглядят проще, но не переживают корректировок задним числом — а они в реальном учёте есть всегда.
Что стоит закладывать сразу: событийную модель вместо снимков, очередь между 1С и внешним миром вместо публикации 1С наружу, буферизацию с приоритетами под лимиты площадок, явную таблицу соответствия артикулов и ежесуточную сверку. Каждый из этих пунктов добавляется потом дороже, чем на старте.
Николай Мазур, MZR Digital.
Вступайте в нашу телеграмм-группу Инфостарт