Как организовать быстрый обмен остатками и резервирование между УТ 10.3, УТ 11.3 и сайтом

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

В розничных сетях с развитой интернет-торговлей часто возникает задача объединения разнородных систем: распределенной сети розничных магазинов на базе 1С:Управление торговлей 10.3, центральной базы интернет-магазина на 1С:Управление торговлей 11 и веб-витрины (например, на 1С-Битрикс). Основные требования к такой связке — оперативное резервирование товаров под онлайн-заказы самовывоза, актуализация остатков в режиме реального времени и надежный контроль каналов связи с торговыми точками.

Разберем архитектурные ограничения типовых механизмов, выберем оптимальный способ взаимодействия и пошагово реализуем схему резервирования и мониторинга состояния торговых точек.

Ограничения классических механизмов обмена

Проанализируем, почему типовые подходы обмена данными не подходят для задачи оперативного резервирования:

  1. Файловый РИБ через FTP: Стандартный обмен распределенной информационной базы (РИБ) является пакетным и асинхронным. Цикл выгрузки, передачи по FTP и загрузки занимает от нескольких минут до часов. За это время товар в розничном магазине может быть продан покупателю на кассе, что приведет к коллизии.
  2. Прямое COM-соединение: Попытка подключиться к удаленной точке по COM через глобальную сеть (WAN) крайне ненадежна. Любые сетевые задержки или обрывы связи вызывают зависание сеанса в центральной базе.
  3. Входящие веб-вызовы к розничным точкам: Большинство магазинов подключены к интернету через провайдеров с динамическими IP-адресами и находятся за NAT. Это делает невозможным публикацию HTTP-сервисов на стороне локальных баз розницы без построения сложной корпоративной VPN-сети.

Архитектура обмена на базе исходящих HTTP-запросов (Polling)

Оптимальным решением является размещение центрального HTTP-сервиса на стороне УТ 11, к которому локальные базы торговых точек обращаются по инициативе «снизу вверх» (исходящие запросы).

Рассмотрим схему взаимодействия подробнее:

  1. Публикация сервиса в УТ 11: Центральная база публикует методы для приема остатков, выдачи новых заказов на резервирование и фиксации статуса выполнения.
  2. Периодический опрос (Polling): Регламентное задание в каждой локальной базе УТ 10.3 с интервалом в 10–30 секунд обращается к сервису УТ 11 через объект HTTPСоединение.
  3. Двухфазное резервирование:

    При оформлении заказа на сайте в УТ 11 создается предварительный («мягкий») резерв с ограниченным временем жизни (TTL). Точка забирает заказ, проводит документ резервирования в локальной базе и отправляет в УТ 11 подтверждение жесткого резерва либо отказ (если товар поврежден или продан секундой ранее).

  4. Передача изменений остатков: При проведении чеков ККМ или приходных накладных в УТ 10.3 измененные остатки немедленно отправляются HTTP-запросом в УТ 11, откуда транслируются на сайт.

Реализация исходящего запроса на стороне УТ 10.3

Посмотрим на пример кода регламентного задания в УТ 10.3, которое обращается к сервису УТ 11 для получения входящих заказов и отправки локальных остатков:


Сервер = "ut11.company.ru";
Порт = 443;
ИспользоватьSSL = Новый ЗащищенноеСоединениеOpenSSL();

Соединение = Новый HTTPСоединение(Сервер, Порт, , , , 15, ИспользоватьSSL);
Запрос = Новый HTTPЗапрос("/ut11_base/hs/exchange/orders?store_id=" + ИдентификаторМагазина);

Попытка
    Ответ = Соединение.Получить(Запрос);
    Если Ответ.КодСостояния = 200 Тогда
        ТелоОтвета = Ответ.ПолучитьТелоКакСтроку(КодировкаТекста.UTF8);
        // Обработка полученных заказов на резервирование
        ОбработатьЗаказыНаРезерв(ТелоОтвета);
    КонецЕсли;
Исключение
    ЗаписьЖурналаРегистрации("ОбменУТ11", УровеньЖурналаРегистрации.Предупреждение, , , ОписаниеОшибки());
КонецПопытки;

Отслеживание неполадок связи и отключение точек (Heartbeat)

Выясним, как центральной базе УТ 11 и сайту оперативно реагировать на обрыв связи с конкретным магазином:

  1. Регистрация «пульса» (Heartbeat): Каждый регламентный запрос от точки (раз в 1–2 минуты) обновляет реквизит ДатаПоследнейСвязи в регистре сведений СостояниеТорговыхТочек в УТ 11.
  2. Контроль тайм-аута: Регламентное задание в УТ 11 регулярно проверяет разницу между текущим временем и датой последней активности каждой точки.
  3. Блокировка самовывоза: Если точка не выходит на связь более заданного времени (например, 5 минут), УТ 11 устанавливает статус «Офлайн» и передает на сайт команду скрыть данную точку из списка доступных для самовывоза, предотвращая оформление заказов с неактуальными остатками.

Применение очередей сообщений (RabbitMQ)

Если сеть насчитывает более 100 магазинов, прямые частые HTTP-запросы могут создать существенную нагрузку на веб-сервер центральной базы. В качестве альтернативы рассмотрим интеграцию через брокер сообщений:

  1. УТ 11 отправляет события о заказах в индивидуальные очереди очередей брокера (например, RabbitMQ).
  2. Локальные базы УТ 10.3 подключаются к брокеру, вычитывают накопленные сообщения и подтверждают их обработку (ACK).
  3. При временном отключении интернета на точке сообщения не теряются, а сохраняются в очереди до восстановления сетевого соединения.

Использование связки исходящего опроса через HTTP-сервисы или брокер сообщений в сочетании с механизмом Heartbeat позволяет объединить распределенную сеть УТ 10.3 с УТ 11 и сайтом, гарантируя минимальные задержки и защиту от некорректных онлайн-заказов при сбоях связи.

← На главную