Когда pull по OData перестаёт работать

Как с подтверждением брони отеля: письмо на почту, звонок администратора и запись в журнале на стойке решают одну задачу, но по-разному переносят ответственность и задержку. Для связки 1С:ERP с внешней WMS та же логика лежит в выборе канала, по которому в учётную базу попадает факт отбора по строкам «Заказа клиента»: закрытие задания на отбор, списание резерва и смена статуса отгрузки не должны зависеть от случайного порядка файлов в каталоге или от того, успел ли оператор обновить список вручную.

Сравнение

Push-событие и pull-опрос по задержке статуса в 1С

Ниже сравниваются четыре распространённых способа доставки подтверждения отбора из WMS в 1С для сценария «одно задание на отбор - одна отгрузка - десятки строк с характеристиками и упаковками». Цифры в таблице приведены как ориентиры с типового проекта (средняя нагрузка, пик в конце смены), а не как норматив платформы. Сравнение намеренно не затрагивает первичную выгрузку задания из 1С в WMS: там другая сторона инициативы и другие ограничения по объёму справочников.

Единый прикладной модуль закрытия отбора позволяет менять транспорт без переписывания проверок количества и серий. На стенде нагрузочного теста имеет смысл прогнать три сценария: одиночное задание, пачка из сорока заданий за минуту и повтор того же IdempotencyKey после искусственного обрыва соединения. Без такого набора выбор канала часто сводится к политике «у соседа так работает», что для резервов и расходных ордеров обходится дороже, чем неделя настройки брокера или HTTP.

HTTP-сервис приёма событий от WMS

WMS отправляет POST после закрытия задания на отбор: в теле передаются идентификатор задания, ссылка на «Заказ клиента» в 1С (GUID или внешний код), табличная часть с фактически отобранными количествами и марками упаковок. В конфигурации создаётся опубликованный HTTP-сервис с методом, который валидирует подпись или статический токен, сверяет строки с незакрытыми позициями заказа и в одной транзакции записывает документ «Расходный ордер на товары» или обновляет статус связанной отгрузки.

Плюсы

• Минимальный разрыв между физическим действием на складе и учётным статусом: внешняя витрина и служба доставки видят «собрано» без ожидания регламента.
• Контракт узкий: только поля, нужные для закрытия отбора, без универсальной модели OData.
• Ошибку WMS получает сразу в ответе (409 при расхождении количества, 404 при неизвестном заказе), что снижает накопление «тихих» расхождений.

Минусы

• WMS должна уметь повторять запрос при таймауте; без согласованного ключа идемпотентности возможны двойные движения.
• HTTP-сервис висит на том же кластере, что и пользователи: всплеск сканирований в конце смены превращается в серию одновременных транзакций записи.
• TLS, ротация секретов и белый список адресов ложатся на инфраструктуру, а не на файловый обмен через SFTP.

На практике HTTP-сервис имеет смысл фиксировать как единственную точку входа для прикладной логики: и очередь, и временный файловый мост в итоге вызывают ту же процедуру «ЗакрытьОтборПоДаннымWMS», чтобы не дублировать проверки расхождений по упаковкам. Таймаут ответа со стороны WMS обычно ставят с запасом относительно p95 длительности транзакции записи ордера; иначе при нормальном проведении клиент уходит в retry и создаёт ложные инциденты в мониторинге.

REST OData как канал подтверждений

Слои от WMS до движений по регистрам

Вариант с публикацией стандартного OData: WMS не пушит событие, а 1С по регламентному заданию «ЗагрузкаПодтвержденийОтбораWMS» опрашивает сущность вроде «Document_ЗаданиеНаОтбор» с отбором по статусу «Выполнено» и метке времени больше последней синхронизации. Альтернатива - OData-прокси на стороне WMS, откуда 1С читает готовые строки факта. Подход удобен, когда в организации уже есть шина OData для отчётности и мобильных клиентов.

Плюсы

• Не нужен входящий HTTP на периметре 1С, если опрос исходит изнутри контура 1С наружу.
• Единый стиль доступа к данным для аналитики и для интеграции: те же фильтры, что в Power BI или внешнем портале.
• Пакетная обработка десятков заданий за один проход регламента снижает число отдельных сеансов по сравнению с потоком одиночных POST.

Минусы

• Задержка статуса в 1С не может быть меньше интервала регламента; для SLA «до двух минут» при интервале 15 минут OData без доработок не подходит.
• Риск постраничного обхода: при сортировке только по дате часть записей с одинаковой меткой времени может остаться на следующей странице, если не зафиксирован стабильный ключ сортировки.
• Расширение табличной части заказа через OData быстро упирается в права и в объём payload; для марок и серий часто всё равно нужен кастомный HTTP-сервис.

Pull по OData «перестаёт работать» не в смысле падения платформы, а в смысле бизнес-требований: как только служба доставки начинает забирать собранные заказы по таймеру, а не по утреннему регламенту, интервал опроса становится видимым дефектом. Компромисс «OData каждые две минуты» на крупной базе умножает число чтений и нагружает СУБД сильнее, чем редкий пакет, но всё равно хуже, чем событие по факту скана. Имеет смысл хранить в регистре сведений «СостояниеСинхронизацииWMS» не только метку времени, но и последний обработанный Ref задания, чтобы при одинаковых timestamp не терять строки на границе страницы.

Обмен файлами через каталог обмена

Параллельные дорожки WMS, 1С и мониторинга

Классическая схема: WMS выкладывает файл «PickConfirm_<номер>.json» в каталог на SFTP или SMB, регламент 1С забирает, парсит, переносит в документ и перемещает файл в «Processed» или «Error». Формат часто наследуют из старых TMS или из обмена с транспортной компанией, где UI уже привык к «папке исходящих».

Плюсы

• Простая отладка на тестовом контуре: достаточно положить файл руками и посмотреть результат разбора.
• Естественная буферизация при недоступности 1С: файлы копятся, пока база не поднимется.
• Минимальные требования к WMS: достаточно записи файла без стека retry HTTP.

Минусы

• Слабая конкуренция: два процесса не должны читать один файл; нужны mutex на уровне ОС или атомарное переименование.
• Идемпотентность редко встроена: повторная выкладка файла с тем же именем может дважды провести ордер, если регламент не ведёт реестр хешей.
• Задержка и «слепые зоны»: пока файл лежит в «Incoming», оператор в 1С считает заказ «в сборке», хотя на складе он уже закрыт.

Файловая схема остаётся рабочей на этапе опытной эксплуатации, когда WMS ещё не готова к сетевым вызовам, но уже выдаёт структурированный JSON с табличной частью. Критично договориться о схеме имени: включение GUID задания WMS в имя файла снижает риск перезаписи, а суффикс «.tmp» с финальным rename в «.json» сигнализирует регламенту 1С, что запись завершена. Без отдельного каталога «Error» и без уведомления ответственного за обмен операторы начинают вручную дублировать отгрузки в 1С, что хуже любого технического долга интеграции.

Очередь сообщений между WMS и 1С

Матрица «SLA × периметр» для выбора канала

WMS публикует сообщение в RabbitMQ или аналог с routing key «pick.confirmed», отдельный фоновый процесс (ras/ragent или внешний worker на Python) читает очередь и вызывает тот же прикладной код записи, что и HTTP-сервис. Обязательство доставки переносится с «WMS дождалась ответа 200» на «брокер принял ack после успешной обработки». Для команд, которые уже используют очередь для исходящих статусов заказа, симметричный входящий канал часто проще согласовать с архитектурой, чем второй стиль интеграции.

Плюсы

• Развязка по времени: пики сканирования сглаживаются длиной очереди и числом consumer-ов.
• Dead-letter queue сохраняет «ядовитые» сообщения с телом для ручного разбора без потери факта отбора на складе.
• Повторная обработка с тем же message_id не создаёт движений, если в 1С заведён регистр сведений «ОбработанныеСобытияWMS».

Минусы

• Отдельный контур эксплуатации: мониторинг брокера, политики TTL, версии протокола.
• Задержка end-to-end включает и lag consumer; при остановке обработчика очередь растёт, а статусы в 1С отстают непредсказуемо.
• Отладка сложнее, чем у HTTP: нужен доступ к management UI и согласованный формат заголовков.

Очередь оправдана, когда число закрытых заданий за час измеряется тысячами, а кластер 1С уже упирался в конкуренцию за запись по тому же заказу. Ограничение prefetch и явная политика «не больше N необработанных сообщений на consumer» защищают базу от лавины параллельных транзакций; без этого выигрыш по сравнению с HTTP-сервисом исчезает. Симметрия с исходящим потоком статусов отгрузки в ту же шину упрощает трассировку: по correlation id видно цепочку от резерва до факта отбора.

Для согласования полей между WMS и модулем записи в 1С полезно держать пример тела события и таблицу соответствия в открытом репозитории 1c-wms-pick-confirm-contract: это не заменяет код в конфигурации, но снижает число споров на этапе приёмки.

Фрагмент обработчика HTTP-сервиса

Функция PickConfirmPOST(Запрос)
    Тело = Запрос.ПолучитьТелоКакСтроку();
    Данные = ПрочитатьJSONВСтруктуру(Тело);
    КлючСобытия = Данные.IdempotencyKey;
    Если РегистрыСведений.ОбработанныеСобытияWMS.УжеОбработано(КлючСобытия) Тогда
        Ответ = Новый HTTPСервисОтвет(200);
        Возврат Ответ;
    КонецЕсли;
    НачатьТранзакцию();
    Попытка
        ЗакрытьОтборПоДаннымWMS(Данные);
        РегистрыСведений.ОбработанныеСобытияWMS.Зафиксировать(КлючСобытия);
        ЗафиксироватьТранзакцию();
    Исключение
        ОтменитьТранзакцию();
        ВызватьИсключение;
    КонецПопытки;
    Возврат Новый HTTPСервисОтвет(200);
КонецФункции

Псевдокод consumer очереди

LOOP сообщение ИЗ очередь pick_inbound
  ЕСЛИ регистр.ОбработанныеСобытияWMS содержит message_id
    ACK без записи
  ИНАЧЕ
    НАЧАТЬ транзакция 1С
    ЗакрытьОтборПоДаннымWMS(тело)
    записать message_id
    КОММИТ
    ACK
  ПРИ ошибка валидации
    NACK без requeue U94; DLQ
  ПРИ временная недоступность 1С
    NACK с requeue, backoff
КОНЕЦ

Как выбрать

• Если SLA требует обновления статуса «собрано» в 1С в течение одной-двух минут после последнего скана, то push через HTTP-сервис или очередь с живым consumer; OData и файлы без учащения регламента не закрывают требование.
• Если периметр запрещает входящие порты на кластер 1С, а исходящий опрос из 1С разрешён, то OData или забор файлов с внутреннего каталога; при этом закладывается явная задержка в интерфейсе заказа.
• Если WMS не умеет надёжный retry HTTP, но умеет только запись в каталог, то обмен файлами с атомарным rename и реестром хешей; переход на HTTP откладывают до модернизации WMS.
• Если в конце смены наблюдаются сотни одновременных закрытий отбора и конкуренция записи на регистре «ТоварыНаСкладах», то очередь с ограничением параллелизма consumer (например, не больше пяти одновременных транзакций записи) предпочтительнее прямого POST на каждый скан.
• Если команда уже стандартизировала исходящие статусы в ту же шину сообщений, то входящие подтверждения отбора в ту же топологию уменьшают число паттернов сопровождения.
• Если объём строк с сериями и марками превышает разумный размер одного OData-ответа, то не расширять публикацию OData, а зафиксировать узкий JSON-контракт в HTTP или в теле сообщения очереди.

Ограничения и когда подход не подходит

Общий знаменатель всех вариантов: граница транзакции в 1С должна совпадать с одним логическим событием WMS. Смешивать в одном вызове закрытие отбора и корректировку маршрута доставки удобно на бумаге, но при частичном сбое сложнее понять, что уже записано. Независимо от транспорта полезно вести журнал интеграции с полным телом запроса (с маскированием персональных данных получателя) и ссылкой на созданный «Расходный ордер на товары».

Ни один канал не заменяет сверку остатков: подтверждение отбора закрывает логистический факт по заказу, но не отменяет периодическую сверку ячеек WMS и регистра «ТоварыНаСкладах». HTTP и очередь плохо сочетаются с ручным редактированием того же заказа в 1С в момент прихода события: нужен явный запрет перепроведения или версионность строк. OData-опрос при жёстком требовании near-real-time без уменьшения интервала регламента остаётся компромиссом только для некритичных статусов. Файловый обмен при обязательном аудите «кто и когда подтвердил» требует подписи файла или журнала на стороне WMS, иначе спорные ситуации сводятся к дате изменения в каталоге. Если WMS и 1С принадлежат разным подрядчикам без общего стенда, начинать с очереди или HTTP без е2е-тестов на идемпотентность обычно дороже, чем временный файловый мост с реестром.

Итог: ситуация и риск