Заказ оформлен, покупатель доволен — а в 1С его нет. Или пришло два одинаковых заказа. Или деньги списались, а чек не пробился. Всё это симптомы одной болезни: заказы и платежи отправляются во внешние системы «в лоб», без защиты от сбоев. Пока 1С и платёжка отвечают мгновенно и всегда, это работает. Но они иногда недоступны, тормозят и обрывают связь — и тогда заказы теряются или дублируются.
Разберём инженерно, как сделать передачу заказов в 1С и платёжные системы надёжной: почему синхронная отправка плоха, как очередь с ретраями гарантирует доставку, зачем нужна идемпотентность и что делать с тем, что так и не отправилось. Проектирование и настройку надёжных интеграций закрывает наша автоматизация на 1С.
Коротко
- Синхронная отправка «в лоб» теряет заказы при недоступности 1С или платёжки — нужна очередь.
- Очередь принимает задачу мгновенно, а фоновый обработчик доставляет её с повторами при сбоях.
- Идемпотентность обязательна: без неё ретраи создают дубли заказов и двойные списания.
- Повторы делают с нарастающей задержкой и лимитом, а безнадёжное отправляют в dead letter на разбор.
Почему синхронная отправка ненадёжна
Типичная наивная схема: покупатель нажимает «оформить», и сайт прямо в этот момент шлёт заказ в 1С и запрос в платёжную систему, дожидаясь ответа. Пока внешние системы быстры и доступны, всё хорошо. Проблемы начинаются при любом отклонении от идеала.
1С может быть на обслуживании, платёжка — тормозить, сеть — оборваться на середине. При синхронной отправке это бьёт прямо по покупателю: он зависает на оформлении, видит ошибку или крутящийся индикатор. Хуже того, заказ в этот момент может потеряться: сайт не смог его передать и не сохранил надёжно. Внешние системы недоступны не «никогда», а «иногда» — и именно эти «иногда» рушат синхронную схему. Надёжная интеграция строится из предположения, что внешняя система в любой момент может не ответить.
Очередь как буфер между сайтом и внешней системой
Решение — вставить между сайтом и внешней системой буфер: очередь. Сайт не отправляет заказ во внешнюю систему напрямую, а кладёт в очередь задачу «отправить этот заказ в 1С», и на этом его ответственность перед покупателем заканчивается.
Дальше отдельный фоновый обработчик берёт задачи из очереди и доставляет их во внешнюю систему. Если 1С недоступна — задача остаётся в очереди и повторяется позже. Ключевая выгода: покупатель больше не ждёт внешнюю систему, а заказ гарантированно сохранён и рано или поздно доставлен. Очередь развязывает быстрый пользовательский путь и медленную, иногда падающую внешнюю интеграцию. Это фундаментальный приём надёжных распределённых систем, и он одинаково применим и к 1С, и к платежам, и к любой другой внешней отправке.
Синхронно против асинхронно
Разница между двумя подходами наглядна при сравнении.
| Аспект | Синхронно (в лоб) | Асинхронно (очередь) |
|---|---|---|
| Покупатель ждёт | Внешнюю систему | Только сохранение заказа |
| 1С недоступна | Ошибка, заказ теряется | Задача ждёт в очереди |
| Сбой на середине | Непонятное состояние | Повтор с идемпотентностью |
| Нагрузка на внешнюю систему | Пиками, неуправляемо | Ровным потоком |
| Сложность | Ниже | Выше, но окупается |
Асинхронная схема сложнее — появляются очередь, обработчик, повторы, — но эта сложность окупается надёжностью. Синхронная проще, но её простота обманчива: она работает только в идеальных условиях, которых в реальности не бывает. Для критичных потоков вроде заказов и платежей выбор почти всегда в пользу очереди.
Идемпотентность: защита от дублей
Как только появляются повторы, возникает опасность дублей, и здесь идемпотентность становится обязательной, а не желательной. Сценарий: обработчик отправил заказ в 1С, 1С его приняла, но ответ не дошёл из-за обрыва сети. Обработчик считает, что не получилось, и повторяет — теперь заказ в 1С задвоен.
Идемпотентность решает это: каждая операция несёт уникальный ключ (например, идентификатор заказа), и приёмная сторона по этому ключу распознаёт повтор как ту же самую операцию, а не новую. Повторная отправка заказа с тем же ключом не создаёт дубль — 1С видит, что такой заказ уже есть. То же с платежами: повтор запроса с тем же ключом не списывает деньги дважды. Без идемпотентности ретраи не спасают, а вредят, превращая временный сбой в постоянную порчу данных. Поэтому её закладывают в основу, а не «добавляют потом».
Ретраи с нарастающей задержкой
Повторы тоже нужно делать грамотно. Наивный ретрай «долбить каждую секунду, пока не пройдёт» добивает упавшую систему и мешает ей восстановиться. Правильный подход — экспоненциальный backoff:
- Первый повтор быстро. Через несколько секунд — вдруг был короткий сбой сети.
- Дальше с ростом задержки. Следующий позже, ещё следующий ещё позже — система получает время восстановиться.
- С ограничением попыток. Не бесконечно: после N неудач задача признаётся неотправляемой автоматически.
- С небольшим разбросом. Джиттер (случайная добавка к задержке) не даёт всем задачам биться в систему одновременно.
Такая стратегия справляется с временными сбоями (короткая недоступность 1С проходит незаметно) и не превращает повторы в DDoS упавшего сервиса. Параметры — интервалы и число попыток — подбирают под конкретную интеграцию: для 1С можно повторять дольше, для платёжной сессии окно уже.
Dead letter: куда девать неотправленное
Даже с повторами часть задач в итоге не доставится: внешняя система лежит долго, данные некорректны, произошла невосстановимая ошибка. Такие задачи нельзя ни терять, ни повторять вечно — для них заводят отдельную очередь «мёртвых писем» (dead letter).
После исчерпания попыток задача уходит в dead letter, где ждёт ручного разбора. Это принципиально: заказ не пропал молча и не крутится в бесконечных повторах, забивая систему, — он лежит в понятном месте с историей ошибок, и ответственный человек может разобраться и переотправить. Ненулевой dead letter — сигнал, что что-то системно не так, и его нужно мониторить. Без этого механизма неотправляемые задачи либо теряются, либо забивают очередь, мешая нормальным.
Особенности отправки в 1С
Передача заказов в 1С — самый частый случай асинхронной интеграции, и у него своя специфика. Главное преимущество: заказ в 1С можно доставить с задержкой. Это фоновая синхронизация, и покупателю не нужно, чтобы заказ мгновенно появился в учётной системе.
Поэтому здесь очередь работает особенно естественно: сайт сохранил заказ, показал покупателю успех, а доставка в 1С идёт фоном с повторами. Штатный обмен CommerceML в 1С-Битрикс сам по себе пакетный и асинхронный, но кастомные потоки (мгновенная передача статусов, отдельные события) стоит строить по тем же правилам — очередь, идемпотентность по идентификатору заказа, повторы. Как проектировать такие обмены устойчивыми и безопасными, мы разбираем в статьях про REST-вебхуки и безопасность и про работу с данными на D7 ORM.
Особенности платежей и чеков 54-ФЗ
С платежами и фискализацией правила строже, чем с 1С, потому что здесь есть деньги, сессия пользователя и юридические сроки.
- Привязка к сессии. Оплата происходит «здесь и сейчас», окно повторов уже, чем для фоновой синхронизации в 1С.
- Строгий контроль статусов. Каждый шаг — инициация, оплата, подтверждение — фиксируется, чтобы не потерять состояние платежа.
- Идемпотентность обязательна. Повтор не должен списать деньги дважды — ключ операции критичен.
- Чеки по 54-ФЗ. Непробитый чек — нарушение; сбой фискализации фиксируется, повторяется и при неудаче идёт на контроль.
Принципы те же — очередь, идемпотентность, повторы, фиксация каждого шага, — но контроль жёстче. Заказ нельзя считать полностью завершённым, пока не подтверждены и оплата, и чек. Здесь особенно важен мониторинг: зависший платёж или непробитый чек должны всплывать сразу, а не обнаруживаться при сверке через неделю.
Реализация очередей на 1С-Битрикс
Реализовать очередь на 1С-Битрикс можно на разном уровне сложности — и начинать стоит с простого.
- Таблица задач в базе. На небольших объёмах роль очереди играет таблица: сайт пишет задачу отправки, статус — «новая».
- Фоновый обработчик. Агент 1С-Битрикс или крон берёт новые задачи, выполняет, помечает результат.
- Повторы и статусы. При сбое задача остаётся с растущим счётчиком попыток и временем следующей попытки.
- Dead letter. После лимита попыток статус меняется на «неотправлено», задача уходит на ручной разбор.
- Внешний брокер при росте. Для высоких нагрузок и множества интеграций переходят на специализированный брокер очередей.
Таблица задач с обработкой агентом покрывает большинство магазинов и куда проще внешнего брокера. Усложнять стоит по мере роста, а не заранее. Логику обработчика оформляют собственным модулем, а не правкой ядра — принципы в статье про разработку модуля на Битрикс. Стабильность фоновых процессов зависит и от среды — про это материал об инфраструктуре и хостинге на BitrixVM.
Мониторинг и сверка
Надёжная интеграция без наблюдения — иллюзия надёжности: пока не позвонит клиент, потери незаметны. Поэтому очередь всегда снабжают мониторингом и сверкой:
- Логирование задач. Каждая задача отправки и её статус фиксируются — видно, что доставлено, что нет.
- Размер очереди. Рост числа необработанных задач — сигнал, что доставка отстаёт или встала.
- Контроль dead letter. Ненулевое число «мёртвых» задач означает системную проблему, требующую разбора.
- Регулярная сверка. Заказы на сайте сверяются с заказами в 1С — расхождения ловятся раньше бизнеса.
Мониторинг превращает «кажется, работает» в «точно работает». Сверка — последняя линия обороны: даже если что-то проскользнуло мимо очереди и повторов, регулярное сопоставление сайта и 1С обнаружит потерю до того, как её заметит клиент или бухгалтерия.
Частые ошибки
- Синхронная отправка критичных данных. Заказ шлётся в 1С «в лоб» и теряется при её недоступности.
- Ретраи без идемпотентности. Повторы плодят дубли заказов и двойные списания.
- Повторы без задержки. «Долбёжка» упавшей системы мешает ей восстановиться.
- Бесконечные повторы. Нет лимита и dead letter — неотправляемая задача забивает очередь.
- Потеря неотправленного. После неудачи задача просто исчезает вместо dead letter.
- Заказ завершён до подтверждения оплаты и чека. Платёж или чек зависли, а заказ уже «выполнен».
- Нет мониторинга и сверки. Потери обнаруживаются по звонку клиента, а не по метрикам.
Чек-лист внедрения
- Критичные отправки асинхронны. Заказы и платежи идут через очередь, а не «в лоб».
- Заказ сохраняется первым. Сайт надёжно фиксирует заказ до любой внешней отправки.
- Идемпотентность есть. Каждая операция несёт ключ, повтор не создаёт дубль.
- Ретраи с backoff. Повторы с нарастающей задержкой, джиттером и лимитом попыток.
- Dead letter настроен. Безнадёжные задачи попадают на ручной разбор, а не теряются.
- Платежи под строгим контролем. Статусы фиксируются, заказ не завершается без оплаты и чека.
- Мониторинг работает. Размер очереди и dead letter под наблюдением.
- Сверка регулярна. Заказы сайта и 1С периодически сопоставляются.
Вывод
Надёжная передача заказов в 1С и платёжные системы строится из одного предположения: внешняя система в любой момент может не ответить. Синхронная отправка «в лоб» этого не переживает — она теряет заказы и вешает покупателя на сбоях внешних сервисов. Очередь развязывает быстрый пользовательский путь и ненадёжную интеграцию: сайт мгновенно сохраняет заказ, а фоновый обработчик доставляет его с повторами.
Три вещи делают эту схему рабочей: идемпотентность, без которой ретраи плодят дубли и двойные списания; повторы с нарастающей задержкой и лимитом; dead letter для того, что доставить не удалось. Добавьте мониторинг очереди и регулярную сверку сайта с 1С — и заказы перестанут теряться и дублироваться, а платежи и чеки будут доходить гарантированно. На 1С-Битрикс это начинается с простой таблицы задач и агента, а усложняется по мере роста нагрузки.
