При администрировании серверов 1С часто возникает задача автоматизации: например, нужно собрать отчет о состоянии всех баз в кластере, проверить, у каких из них включена блокировка регламентных заданий или установлен код разрешения доступа (PermissionCode). Однако стандартный подход через соединение с агентом сервера (ConnectAgent) зачастую возвращает лишь краткую информацию, такую как имя и описание базы, оставляя остальные поля пустыми. В этой статье мы подробно разберем, как обойти это ограничение и получить доступ ко всем свойствам информационной базы.
Рассмотрим ситуацию: вы подключаетесь к агенту сервера, получаете список кластеров, авторизуетесь в нужном кластере и вызываете метод GetInfoBases(). На выходе вы получаете массив объектов. Проанализируем состояние этих объектов: у них заполнено только свойство Name. Все остальные важные параметры — PermissionCode, ScheduledJobsDenied, SessionsDenied — возвращают пустые значения или значения по умолчанию. Это происходит не из-за ошибки в коде, а из-за архитектуры безопасности 1С:Предприятия.
Для защиты данных в платформе реализована двухуровневая модель доступа к административным функциям:
Прежде всего, нам необходимо создать COM-объект и подключиться к агенту сервера. Выясним причину, по которой нельзя сразу подключиться к базе: нам нужно знать, на каком порту работает хотя бы один рабочий процесс кластера. По умолчанию агент работает на порту 1540, а рабочий процесс может занимать порты 1560 и далее.
Рассмотрим пример кода для инициализации соединения:
// Создаем коннектор
Connector = Новый COMОбъект("V83.COMConnector");
// Подключаемся к агенту сервера
СоединениеСАгентом = Connector.ConnectAgent("ServerName");
// Получаем кластеры (обычно он один, берем первый индекс)
МассивКластеров = СоединениеСАгентом.GetClusters();
ТекущийКластер = МассивКластеров[0];
// Авторизуемся в кластере (если установлены логин/пароль администратора кластера)
СоединениеСАгентом.Authenticate(ТекущийКластер, "AdminUser", "AdminPassword");
Теперь нам нужно найти работающий процесс. Проанализируем ситуацию: метод GetWorkingProcesses(ТекущийКластер) вернет нам список всех процессов. Нам подойдет любой, у которого свойство Running имеет значение 1 (или Истина).
Когда мы определили адрес и порт рабочего процесса (например, "tcp://ServerName:1560"), мы можем использовать метод ConnectWorkingProcess. Именно этот объект IWorkingProcessConnection открывает нам путь к детальным параметрам информационных баз.
Разберем по шагам дальнейшие действия:
// Получаем список процессов кластера
Процессы = СоединениеСАгентом.GetWorkingProcesses(ТекущийКластер);
СтрокаСоединенияСПроцессом = "";
Для Каждого Процесс Из Процессы Цикл
Если Процесс.Running = 1 Тогда
// Формируем строку вида tcp://host:port
СтрокаСоединенияСПроцессом = "tcp://" + Процесс.HostName + ":" + Формат(Процесс.MainPort, "ЧГ=0");
Прервать;
КонецЕсли;
КонецЦикла;
// Устанавливаем соединение с рабочим процессом
СоединениеСПроцессом = Connector.ConnectWorkingProcess(СтрокаСоединенияСПроцессом);
Это самый важный этап, на котором многие разработчики застревают. Даже если вы подключились к рабочему процессу, вызов GetInfoBases() все равно может вернуть пустые параметры, если вы не "представились" базам.
Важный нюанс: Чтобы прочитать PermissionCode заблокированной базы, вам нужно добавить авторизацию администратора этой информационной базы в объект соединения с процессом. Это делается методом AddAuthentication. При этом само подключение к базе (создание сессии) не происходит, поэтому блокировка входа в базу не мешает нам читать настройки.
Посмотрим на пример кода:
// Если у базы есть администратор, нужно добавить его данные
// Если пользователей нет, этот шаг можно пропустить, но для
// гарантированного доступа к защищенным полям лучше вызвать:
СоединениеСПроцессом.AddAuthentication("АдминБазы", "ПарольАдмина");
// Теперь получаем список баз через рабочий процесс
СписокБаз = СоединениеСПроцессом.GetInfoBases();
Для Каждого ТекущаяИБ Из СписокБаз Цикл
// Теперь нам доступны все свойства объекта IInfoBaseInfo
Сообщить("База: " + ТекущаяИБ.Name);
Сообщить("Блокировка заданий: " + ТекущаяИБ.ScheduledJobsDenied);
Сообщить("Код разрешения: " + ТекущаяИБ.PermissionCode);
КонецЦикла;
После успешной авторизации через IWorkingProcessConnection, объект IInfoBaseInfo предоставляет нам полный спектр данных. Проанализируем наиболее полезные свойства:
ScheduledJobsDenied: Булево значение. Если Истина, регламентные задания в базе отключены.PermissionCode: Строка. Тот самый секретный код, который позволяет зайти в базу, когда она заблокирована.SessionsDenied: Булево значение. Указывает, заблокировано ли начало новых сеансов пользователями.DeniedMessage: Текст сообщения, который видит пользователь при попытке входа в заблокированную базу.DeniedFrom / DeniedTo: Время начала и окончания плановой блокировки.dbServerName: Имя сервера СУБД (SQL-сервера).dbName: Имя конкретной базы данных на SQL-сервере.Если работа с COM-объектами кажется излишне сложной или возникают проблемы с регистрацией библиотек comcntr.dll (например, из-за разной разрядности сервера и клиента), рассмотрим ситуацию использования утилиты rac. Это консольное приложение, которое общается с сервером 1С через службу ras (сервер администрирования).
Команда для получения информации о базе будет выглядеть так:
rac infobase --cluster=ID_кластера info --infobase=ID_базы
В выводе этой команды вы получите текстовый список всех параметров, включая scheduled-jobs-deny и permission-code. Этот метод часто считается более современным и надежным для сценариев автоматизации на Python, PowerShell или Bash.
Подведем итог: для программного чтения кода разрешения или состояния блокировки заданий в 1С 8.3 недостаточно использовать ConnectAgent. Мы должны обязательно выполнить соединение с рабочим процессом кластера (на портах 1560+) и использовать метод AddAuthentication. Только в этом случае интерфейс IInfoBaseInfo раскроет все свои поля. Помните, что административные интерфейсы работают даже тогда, когда база заблокирована для обычных пользователей — это и позволяет нам программно управлять параметрами доступа.