Как организовать получение и сборку заказов в магазинах: выбор между веб-сервером, регламентными заданиями и мобильным приложением

← На главную

При построении распределенной системы заказов, когда данные поступают от внешних агрегаторов (например, Delivery Club) в центральный узел, а исполняться должны в территориально распределенных магазинах, возникает критический вопрос: как эффективно «протолкнуть» данные в локальные базы. Ситуация осложняется, если в магазинах используются файловые базы 1С:Розница, которые чувствительны к фоновой нагрузке. Разберем основные архитектурные стратегии, их плюсы и минусы, а также способы реализации.

Метод 1. Оптимизация регламентных заданий (Pull-модель)

Традиционный подход заключается в том, что база магазина сама «спрашивает» центральный сервер о наличии новых заказов. Автор темы опасается, что частое выполнение заданий (раз в минуту) вызовет «зависание» интерфейса. Давайте проанализируем ситуацию и выясним причину.

В файловой базе регламентные задания выполняются в контексте одного из клиентских сеансов или специального выделенного сеанса. Чтобы избежать микро-зависаний у кассиров, мы рекомендуем запустить в магазине отдельный сеанс «Робот». Рассмотрим, как оптимизировать сам процесс опроса:

Двухэтапный запрос: Не нужно каждый раз скачивать тяжелый пакет данных. Первым делом выполняется максимально легкий HTTP GET запрос, который возвращает только Истина или Ложь (есть ли заказы для данного ID магазина).
Инициация получения: Только если ответ положительный, выполняется второй запрос на получение полных данных заказа.

Пример реализации легкого запроса:


Функция ПроверитьНаличиеЗаказовНаСервере()
    Соединение = Новый HTTPСоединение("central-server.com",,,,, 5); // Таймаут 5 сек
    Запрос = Новый HTTPЗапрос("/hs/orders/check?storeID=" + КодТекущегоМагазина);
    
    Попытка
        Ответ = Соединение.Получить(Запрос);
        Если Ответ.КодСостояния = 200 Тогда
            Возврат Сокращенно(Ответ.ПолучитьТелоКакСтроку()) = "YES";
        КонецЕсли;
    Исключение
        ЗаписатьЛогСобытий("Ошибка связи с сервером");
    КонецПопытки;
    Возврат Ложь;
КонецФункции

Метод 2. Веб-сервер в каждом магазине (Push-модель)

Этот вариант предполагает, что центральный сервер сам отправляет данные в магазин через HTTP POST. Рассмотрим подробнее технические сложности этого пути:

Проблема белого IP: Большинство магазинов работают на бытовых тарифах интернета без статического IP-адреса. Публикация базы станет невозможной без дополнительных затрат.
Безопасность: Открытие портов наружу в каждом магазине увеличивает риск атак на инфраструктуру.
Администрирование: Настройка и обновление 40 веб-серверов (Apache или IIS) — трудозатратная задача для системного администратора.

Решение: Если вы выбрали этот путь, используйте Mesh-VPN технологии (например, ZeroTier или Tailscale). Они позволяют объединить все магазины и центр в одну виртуальную локальную сеть. В этом случае центральная база сможет обращаться к базе магазина по внутреннему IP-адресу (например, 10.0.1.5), даже если у магазина «серый» IP.

Метод 3. Использование брокеров сообщений (MQTT)

Для исключения «зависаний» файловой базы и обеспечения мгновенной доставки данных проанализируем использование протокола MQTT. Это стандарт для систем интернета вещей (IoT), который идеально подходит для распределенных сетей 1С.

Разберем по шагам, как это работает:

В центре поднимается брокер сообщений (например, Mosquitto).
База магазина при запуске подписывается на «топик» своего магазина.
Как только в центр прилетает заказ, он публикует короткое сообщение в топик.
Локальная база мгновенно получает уведомление.

Для работы с MQTT в 1С обычно используются внешние компоненты. Это позволяет базе находиться в режиме ожидания без постоянных HTTP-запросов, что практически не нагружает ресурсы компьютера.

Метод 4. Мобильное приложение и Push-уведомления

Если для сборки заказов планируется использовать смартфоны или ТСД, лучшим решением станет автономное мобильное приложение. Выясним, как организовать получение данных в нем:

Вместо того чтобы приложение постоянно «стучалось» на сервер, следует использовать сервис Push-уведомлений (Firebase Cloud Messaging). Процесс выглядит так: 1. Центр получает заказ. 2. Центр отправляет Push-сигнал на устройство сборщика. 3. Мобильное приложение, получив Push, в фоновом режиме выполняет синхронизацию (через HTTP-сервис) и загружает данные заказа. 4. Сборщик видит уведомление на экране и приступает к работе.

Этот вариант наиболее современный, так как он не зависит от состояния базы 1С:Розница в магазине в конкретный момент и позволяет сборщику быть мобильным.

Метод 5. Гибридный подход с внешним уведомлением (Telegram)

Рассмотрим практичный совет из обсуждения: использование мессенджера в качестве «будильника». Если автоматизация «на лету» кажется слишком сложной, можно настроить отправку сообщения в Telegram-бот магазина. В сообщении будет кнопка «Принять в 1С». При нажатии на кнопку в Telegram, бот может через ВнешнееСобытие или запись в промежуточную таблицу БД дать сигнал 1С начать загрузку.

Также можно реализовать кнопку «Получить заказ» непосредственно в АРМ (автоматизированном рабочем месте) продавца. В этом случае продавец, видя сообщение в Telegram, сам инициирует обмен. Это на 100% исключает автоматические «зависания» системы в неподходящий момент.

Выводы и рекомендации

Проанализировав ситуацию для 40 магазинов, мы рекомендуем следующие шаги:

Для старта: Оптимизируйте регламентное задание в 1С, вынеся его в отдельный сеанс «Робот», и используйте «легкие» HTTP-запросы для проверки наличия данных.
Для масштабирования: Если планируется внедрение мобильных устройств, делайте ставку на мобильный клиент или приложение с Push-уведомлениями. Это снимет нагрузку с локальных файловых баз.
Для надежности соединения: Если требуется прямая связь «Центр -> Магазин», внедрите VPN-оверлей, чтобы не зависеть от наличия статических IP-адресов в точках продаж.

Использование веб-сервера в каждом магазине (без VPN) является наиболее рискованным и сложным в поддержке вариантом, поэтому его стоит рассматривать в последнюю очередь.