При построении распределенных систем часто возникает задача мгновенной передачи данных между базами. Стандартные сценарии обмена по расписанию не всегда подходят, если бизнес-процесс требует реакции «здесь и сейчас». Ситуация осложняется, когда база-исполнитель (Источник) находится за NAT, не имеет публичного IP-адреса и возможности опубликовать веб-сервисы. В такой конфигурации база не может «слушать» входящие HTTP-запросы напрямую. Разберем подробно, как можно решить эту задачу, используя различные технические подходы в среде 1С.
Самый простой и доступный способ — использование встроенного метода ПодключитьОбработчикОжидания. Однако при малых интервалах опроса (например, 1 секунда) возникает риск «наслоения» вызовов: если текущая итерация обработки данных затянулась, платформа может запустить следующую до завершения предыдущей, что приведет к непредсказуемым ошибкам или перегрузке системы. Рассмотрим, как правильно реализовать этот механизм, чтобы избежать подобных проблем.
Проанализируем алгоритм: чтобы вызовы не пересекались, нам необходимо отключать обработчик в самом начале процедуры и включать его заново только после успешного (или аварийного) завершения всей логики. Таким образом, интервал в 1 секунду будет отсчитываться не от начала запуска, а от момента окончания работы кода.
Пример реализации в модуле управляемой формы:
&НаКлиенте
Процедура ЗапуститьМониторинг(Команда)
// Устанавливаем интервал в 1 секунду
ПодключитьОбработчикОжидания("ВыполнитьПроверкуДанных", 1, Истина);
КонецПроцедуры
&НаКлиенте
Процедура ВыполнитьПроверкуДанных()
// Первым делом отключаем обработчик, чтобы исключить повторный вход
ОтключитьОбработчикОжидания("ВыполнитьПроверкуДанных");
Попытка
// Здесь вызывается серверная функция, которая обращается к базе-приемнику
Результат = ПроверитьНаличиеНовыхДанныхНаСервере();
Если Результат.ЕстьДанные Тогда
ОбработатьПолученныеДанные(Результат.Данные);
КонецЕсли;
Исключение
ЗаписатьЛогОшибки(ОписаниеОшибки());
КонецПопытки;
// Включаем обработчик снова только после завершения всех операций
ПодключитьОбработчикОжидания("ВыполнитьПроверкуДанных", 1, Истина);
КонецПроцедуры
Используя параметр Однократно = Истина, мы гарантируем, что система не вызовет процедуру сама, пока мы явно не попросим об этом в конце блока кода. Это делает систему стабильной даже при нестабильном интернет-канале.
Если требуется действительно мгновенная реакция без постоянных «пустых» запросов к серверу, следует рассмотреть использование внешних компонент (Native API). Этот способ позволяет реализовать модель WebSocket клиента прямо внутри 1С. Внешняя компонента может держать постоянное TCP-соединение с сервером-приемником в отдельном потоке.
Выясним причину, почему это эффективно: когда на стороне сервера появляются данные, он отправляет короткий пакет в открытый канал. Компонента ловит этот пакет и инициирует событие в 1С через метод ВнешнееСобытие. Проанализируем преимущества: 1С не тратит ресурсы на постоянные опросы, а код срабатывает только тогда, когда данные реально поступили.
Для реализации этого метода в коде формы используется предопределенная процедура:
&НаКлиенте
Процедура ВнешнееСобытие(Источник, Событие, Данные)
Если Источник = "МойКомпонентОбмена" И Событие = "НовыеДанные" Тогда
// Мгновенная реакция на поступление данных
ОбработатьДанныеПоИдентификатору(Данные);
КонецЕсли;
КонецПроцедуры
Важно: для работы этого метода необходимо наличие внешней компоненты, поддерживающей асинхронную работу с сетью, и серверной части на стороне базы-приемника, способной рассылать уведомления подключенным клиентам.
Рассмотрим ситуацию, когда мы не можем использовать внешние компоненты, но хотим минимизировать задержки и нагрузку на сеть. Здесь на помощь приходит технология Long Polling. Разберем по шагам, как это работает:
Этот метод позволяет добиться почти мгновенной передачи данных, при этом оставаясь в рамках стандартного протокола HTTP. В 1С это реализуется через объект HTTPЗапрос с увеличенным временем ожидания в методе ОтправитьДляОбработки.
Проанализируем более профессиональный подход, который часто применяется в высоконагруженных системах. Вместо прямого соединения между базами используется промежуточное звено — брокер сообщений. База-приемник отправляет уведомление в очередь (Queue), а база-источник «подписывается» на эту очередь.
Посмотрим на плюсы такого решения:
Для работы с брокерами в 1С обычно используются либо готовые внешние компоненты, либо интеграция через REST API брокера. В сценарии с очередями база-источник все равно будет использовать либо короткие опросы очереди, либо Long Polling, но нагрузка на саму базу-приемник при этом будет практически нулевой, так как она только «отдает» данные в очередь и не ждет их обработки.
Выбор конкретного решения зависит от технических ограничений и требований к скорости. Если нужно «быстро и просто», мы рекомендуем использовать оптимизированный обработчик ожидания с корректным отключением и включением процедуры. Для систем, требующих мгновенного отклика и высокой надежности, лучшим выбором станет внешняя компонента с поддержкой внешних событий или интеграция через брокер сообщений.
Помните, что при работе в реальном времени критически важно обрабатывать исключения и разрывы связи, чтобы ваша обработка не «зависла» и не прекратила работу в самый ответственный момент.