Как реализовать оповещение пользователей об освобождении заблокированного документа в 1С?

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

Вариант 1: Использование Регистра сведений для отслеживания очереди

Разберем классический подход с созданием специализированного РегистрСведений. Этот метод позволяет системе «запоминать», кто и какой документ ждет.

1. Создаем РегистрСведений с измерениями: Объект (ссылка на документ) и Пользователь (кто ждет).
2. Когда пользователь пытается открыть занятый документ и получает отказ, предлагаем ему нажать кнопку «Оповестить».
3. При нажатии на кнопку в регистр записывается информация о пользователе и документе.
4. У второго пользователя запускается ОбработчикОжидания, который периодически опрашивает регистр на предмет изменения статуса блокировки.
5. В момент записи или закрытия документа первым пользователем, система проверяет наличие «ждущих» в регистре и отправляет им уведомление, после чего очищает запись.

Важно помнить, что опрос регистра через ОбработчикОжидания создает дополнительную нагрузку на сервер, поэтому мы рекомендуем использовать максимально длинные интервалы опроса.

Вариант 2: Использование Системы взаимодействия (СВ)

Система взаимодействия — это штатный механизм 1С для общения. Мы можем программно интегрировать его в процесс блокировок.

Рассмотрим алгоритм реализации:

1. При возникновении конфликта блокировок, предлагаем пользователю отправить запрос текущему владельцу документа через СистемаВзаимодействия.
2. В документе можно использовать ДополнительныеСвойства для хранения списка пользователей, которые ожидают освобождения объекта.
3. Когда первый пользователь завершает работу, в коде обработки события ПередЗаписью или ПриЗакрытии мы считываем этот массив ожидающих и инициируем отправку сообщения через Обсуждения.

// Пример логики отправки уведомления
Процедура ПослеЗакрытияДокумента(ДокументСсылка)
    СписокОжидающих = ПолучитьСписокОжидающих(ДокументСсылка);
    Для Каждого Пользователь Из СписокОжидающих Цикл
        СистемаВзаимодействия.ОтправитьСообщение(Пользователь, "Документ " + ДокументСсылка + " свободен!");
    КонецЦикла;
КонецПроцедуры

Вариант 3: Решение проблемы «мертвых сеансов»

Одной из главных проблем реализации подобных механизмов является ситуация, когда сеанс пользователя аварийно завершился, а блокировка осталась «висеть». Чтобы избежать этого, нам необходимо использовать РегламентныеЗадания.

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

// Логика проверки активных сеансов
СписокСеансов = ПолучитьСписокАктивныхСеансов();
Для Каждого Запись Из РегистрСведений.ОжидающиеКлиенты Цикл
    Если Не СеансСуществует(Запись.ИдентификаторСеанса) Тогда
        ОчиститьБлокировку(Запись.Объект);
    КонецЕсли;
КонецЦикла;

Методологические рекомендации

Прежде чем приступать к разработке сложных систем уведомлений, проанализируем, не является ли сама необходимость «стоять в очереди» следствием ошибок в бизнес-процессах.

• Оптимистичная блокировка: Попробуйте изменить логику работы так, чтобы документ не блокировался на всё время редактирования. Позвольте пользователям вносить правки одновременно, а при попытке записи проводите проверку на коллизии.
• Разделение данных: Если документ слишком большой, возможно, стоит разбить его на отдельные сущности или использовать Бизнес-процессы, где документ передается по цепочке от одного ответственного к другому, что исключает параллельную работу по определению.

В заключение отметим, что выбор метода зависит от масштабов вашей конфигурации. Для простых задач достаточно СистемаВзаимодействия, для более сложных и отказоустойчивых решений — связка РегистрСведений и РегламентныеЗадания.