При разработке функционала автоматических уведомлений в 1С разработчики часто сталкиваются с неочевидной проблемой. Разберем типичную ситуацию: мы создаем регламентное или фоновое задание, которое должно отправить пользователю сообщение через Систему взаимодействия. Однако в момент выполнения кода система прерывает работу и выдает исключение: Ошибка работы с Системой взаимодействия: Пользователь не авторизован.
Проанализируем эту ситуацию по шагам, выясним причину возникновения ошибки и рассмотрим несколько надежных способов ее решения, от простых пользовательских до профессиональных программных.
Для начала давайте посмотрим на то, как платформа 1С обрабатывает фоновые и регламентные задания. Если при настройке или программном запуске фонового задания явно не указан пользователь информационной базы, под которым оно должно выполняться, платформа запускает его в специальном системном контексте. В таком "безликом" сеансе текущий пользователь имеет значение Неопределено.
Сервер взаимодействия 1С спроектирован таким образом, что для любой операции (будь то создание обсуждения или отправка сообщения) он жестко требует привязки к конкретному авторизованному пользователю информационной базы. Если мы пытаемся обратиться к объекту СистемаВзаимодействия из сеанса без пользователя, сервер не понимает, от чьего имени совершается действие, и закономерно возвращает ошибку авторизации.
Рассмотрим самое простое решение, которое отлично подходит для быстрой отладки или разовой настройки системы. Суть метода заключается в привязке задания к конкретному пользователю и его ручной инициализации.
Теперь, когда регламентное задание будет стартовать, оно будет выполняться в контексте указанного пользователя, и сообщения будут успешно отправляться.
Отправлять системные уведомления от имени живого человека (например, администратора) — это плохая практика, которая может запутать конечных пользователей. Разберем более профессиональный подход. Создадим отдельного виртуального пользователя, назовем его, например, "Системный робот" или "Уведомитель", и назначим его нашему регламентному заданию.
Чтобы не заходить под этим "роботом" в 1С вручную (тем более, что у служебных пользователей часто отключена возможность интерактивного входа), мы можем зарегистрировать его в Системе взаимодействия программно.
Посмотрим на пример кода, который выполняет такую регистрацию. Эту процедуру достаточно выполнить один раз, например, в обработчике обновления информационной базы или через специальную служебную обработку:
// Получаем ссылку на служебного пользователя ИБ
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("СистемныйРобот");
Если ПользовательИБ <> Неопределено Тогда
УстановитьПривилегированныйРежим(Истина);
// Программная регистрация в Системе взаимодействия
ПользовательСВ = СистемаВзаимодействия.СоздатьПользователя(ПользовательИБ);
ПользовательСВ.Записать();
УстановитьПривилегированныйРежим(Ложь);
КонецЕсли;
После выполнения этого кода наш служебный аккаунт будет навсегда авторизован для Сервера взаимодействия, и регламентное задание сможет без проблем рассылать сообщения от его имени. Для реализации групповых рассылок на базе этого механизма можно использовать готовый пример кода для массовой отправки сообщений.
Среди разработчиков часто возникает спор: можно ли решить ошибку пустого контекста, просто обернув отправку сообщения в вызов УстановитьПривилегированныйРежим(Истина)? Проанализируем этот момент.
Сам по себе привилегированный режим не решает проблему пустого пользователя в регламентном задании. Дело в том, что привилегированный режим отключает проверку прав доступа на уровне записей (RLS) внутри самой базы 1С. Однако Сервер взаимодействия — это внешняя по отношению к базе подсистема, которая использует собственные механизмы проверки токенов и идентификаторов.
Если в текущем сеансе пользователь равен Неопределено, то, какие бы права мы ни повышали внутри платформы, для Системы взаимодействия мы все равно останемся "никем". Поэтому назначение конкретного пользователя регламентному заданию обязательно.
При этом вызов УстановитьПривилегированныйРежим(Истина) действительно необходим, но в другом случае — когда мы программно регистрируем новых пользователей через метод СоздатьПользователя, так как эта операция требует административных прав и обхода ограничений RLS на чтение справочников пользователей.
Давайте резюмируем шаги, которые мы вместе разобрали для настройки стабильной отправки сообщений из фоновых заданий:
УстановитьПривилегированныйРежим для обхода ошибки авторизации — этот метод служит для других целей.Применяя эти простые правила, вы навсегда избавитесь от ошибок авторизации и сможете строить надежные системы автоматических уведомлений в ваших конфигурациях 1С.