Довольно часто в разработке на платформе 1С возникает следующая задача: есть конфигурация на управляемых формах, и через веб-сервис или фоновое задание стороннее приложение загружает данные, создавая новые элементы справочника или документы. При этом у пользователей постоянно открыта форма списка этого объекта. Разберем по шагам, как правильно оповестить открытые формы на клиентах о том, что необходимо обновить отображение и показать новые данные.
Основная сложность здесь заключается в архитектуре клиент-серверного взаимодействия. Фоновое задание работает исключительно на сервере, а оповестить нужно формы, которые открыты в клиентских сеансах. Стандартный метод Оповестить() в этом случае не сработает, так как он не умеет передавать сообщения с сервера на клиент. Проанализируем несколько рабочих способов решения этой задачи, от самых простых встроенных механизмов до продвинутых архитектурных паттернов.
Рассмотрим самый простой и наименее трудозатратный способ, который предусмотрен самой платформой. Если у пользователей постоянно открыта форма списка, которая представляет собой динамический список, нам ничего не нужно писать в коде.
В платформе 1С у динамического списка есть стандартное свойство автообновления. Задать его можно прямо в пользовательском режиме (если список формируется стандартно) или в конфигураторе.
Также пользователи могут настроить это самостоятельно: через меню «Еще» -> «Настроить список» (или аналогичные пункты в зависимости от интерфейса) можно задать период автоматического обновления данных.
Важные нюансы: По умолчанию минимальный интервал автообновления в платформе составляет 60 секунд. Если вам требуется более высокая оперативность (например, обновление каждые 5-10 секунд), этот способ может не подойти, так как частое обновление сложных динамических списков создает ощутимую и постоянную нагрузку на сервер СУБД. Кроме того, если у динамического списка указана Основная таблица, платформа пытается кэшировать данные и обновлять их умнее, но между разными сеансами (например, сеанс фонового задания и сеанс пользователя) форма узнает об изменениях только при следующем обращении к серверу или по срабатыванию таймера автообновления.
Проанализируем наиболее современный, оптимальный и «правильный» способ передачи сообщений с сервера на клиент без постоянного опроса базы — использование Системы взаимодействия 1С.
Этот механизм позволяет реализовать полноценные Push-уведомления. Сервер мгновенно «толкает» сообщение клиенту, и клиентская форма моментально на него реагирует. Это исключает задержки и лишние запросы к базе данных, характерные для работы по таймеру.
Разберем логику работы:
СистемаВзаимодействия.СоздатьСообщение().ПриПолученииСообщенияСистемыВзаимодействия.Посмотрим на пример того, как форма может отреагировать на такое сообщение:
&НаКлиенте
Процедура ПриПолученииСообщенияСистемыВзаимодействия(Сообщение, Отказ)
// Проверяем, что сообщение относится к нашему справочнику
Если Сообщение.Текст = "ОбновитьСписокЗаказов" Тогда
Отказ = Истина; // Отменяем стандартное отображение сообщения пользователю
Элементы.Список.Обновить(); // Обновляем динамический список
КонецЕсли;
КонецПроцедуры
Этот метод работает идеально: нет нагрузки от постоянных опросов, а данные на экранах пользователей появляются ровно в момент их создания в базе.
Выясним, что делать, если Система взаимодействия не развернута или по каким-то причинам недоступна. В этом случае мы используем классическую связку: регистр сведений и обработчик ожидания.
Опрашивать сам динамический список или большую таблицу справочника каждые 5 секунд — это убийство производительности. Поэтому мы оптимизируем процесс:
ОчередьОбновленийИнтерфейса. В нем может быть всего одна запись и один ресурс: ВерсияИзменений (тип Число или Дата).ПодключитьОбработчикОжидания(), который будет срабатывать, например, каждые 5-10 секунд.ВерсияИзменений стала больше, чем он помнит, только тогда он вызывает Элементы.Список.Обновить().Нюанс с блокировками: При реализации этого механизма критически важно записывать и читать данные из регистра в режиме неблокирующего чтения. Работа веб-сервиса (момент записи о новом элементе) не должна тормозить чтение этой метки всеми открытыми формами пользователей.
Рассмотрим подход для задач, где критична скорость обновления (Real-time приложения, биржевые стаканы, мониторинги), и стандартных механизмов 1С не хватает. Здесь на помощь приходят внешние компоненты.
Схема взаимодействия выглядит так:
ВнешнееСобытие() модуля формы, после чего форма обновляется.Ограничения: Стоит учитывать, что если ваши пользователи работают через веб-клиент (в браузере), то возможности внешних компонентов сильно ограничены политиками безопасности современных браузеров. Для Web-клиента способы №2 (Система взаимодействия) и №3 (Обработчик ожидания) остаются наиболее стабильными.
Зачастую разработчики пытаются решить эту задачу методами Оповестить() или ОповеститьОбИзменении(). Проанализируем, почему это не приносит результата в описанной архитектуре.
Метод Оповестить() работает только в рамках одного клиентского сеанса. Вы не можете вызвать его на сервере (в фоновом задании) так, чтобы сообщение долетело до клиентских машин.
Метод глобального контекста ОповеститьОбИзменении(ТипЗнч(НоваяСсылка)) работает очень эффективно, но опять же, преимущественно внутри текущего сеанса. Чтобы он обновил списки и кэши для всех пользователей, вызов этого метода должен произойти именно на каждом клиенте. Поскольку сервер не может инициировать это действие напрямую в сеансах пользователей, данный метод бесполезен для фоновых заданий, если только вы не вызываете его программно уже внутри обработчика ожидания на клиенте после получения сигнала об изменениях.
Подводя итог: если вам не нужна посекундная точность — используйте стандартное Автообновление динамического списка. Если нужна оперативность и отсутствие нагрузки — внедряйте Систему взаимодействия. Если система взаимодействия недоступна — стройте архитектуру через Обработчик ожидания и вспомогательный регистр меток времени.