Как программно определить уникальный идентификатор информационной базы и отличить рабочую базу 1С от копии?

← На главную

При разработке и сопровождении конфигураций 1С часто возникает задача определить, в какой именно базе выполняется программный код: в продуктивной (рабочей) или в тестовой копии. Это необходимо для того, чтобы предотвратить выполнение фоновых заданий, отправку реальных писем клиентам, выгрузку данных на сайт или вызовы внешних веб-сервисов из тестовых баз, развернутых из резервных копий.

Разберем особенности платформы 1С:Предприятие, доступные методы идентификации баз и типовые подходы к решению этой задачи.

Ограничения платформы: существует ли встроенный уникальный ID базы?

Проанализируем устройство платформы 1С. Встроенного глобального идентификатора, который был бы жестко зашит в структуру базы данных и одновременно позволял различать продуктивную базу и ее копию, в языке 1С нет. Идентификатор базы на уровне кластера серверов 1С существует, однако штатно из пользовательского сеанса он недоступен (к нему можно обратиться только через административные интерфейсы RAC/RAS или COM). При этом при разворачивании базы из файла .dt или бэкапа СУБД в новую базу кластера создается новый внутренний идентификатор, а данные внутри самой базы остаются полной копией оригинала.

Идентификаторы, хранящиеся в локальном файле ibases.v8i на компьютере пользователя, относятся лишь к настройкам списка баз конкретного пользователя и не могут служить надежным признаком самой базы (особенно при работе через веб-клиент или с разных рабочих мест).

Поэтому на практике применяются программные алгоритмы проверки параметров подключения и окружения.

Способ 1. Проверка строки соединения информационной базы

Самый распространенный способ — анализ системной функции СтрокаСоединенияИнформационнойБазы(). Функция возвращает строку с параметрами подключения к серверу 1С и имени базы в кластере (для клиент-серверного варианта) или путь к каталогу (для файлового варианта).

Посмотрим на пример базовой функции проверки:


Функция ЭтоРабочаяБаза() Экспорт
    
    СтрокаСоединения = СтрокаСоединенияИнформационнойБазы();
    
    // Проверяем наличие ключевых параметров рабочей базы
    Если СтрНайти(ВРег(СтрокаСоединения), "SRVR=""PROD-SERVER""") > 0 
        И СтрНайти(ВРег(СтрокаСоединения), "REF=""ERP_PROD""") > 0 Тогда
        Возврат Истина;
    КонецЕсли;
    
    Возврат Ложь;
    
КонецФункции

Разберем важные нюансы этого подхода:

Регистр символов: имена серверов и баз могут быть введены пользователями в разном регистре, поэтому обязательно приводите строку к верхнему регистру с помощью ВРег().
Имя сервера и IP-адрес: пользователи могут подключаться к одному и тому же серверу как по имени (NetBIOS или FQDN: prod-server.domain.local), так и по прямому IP-адресу (192.168.1.10). Чтобы избежать ложных срабатываний, надежнее проверять исключительно имя базы (параметр Ref), если имена баз на продуктивном и тестовом серверах различаются, либо нормализовать адрес сервера.

Способ 2. Хранение собственного GUID в константе или регистре

Если требуется присвоить базе постоянный уникальный номер (например, для обмена данными), создадим служебную константу или однострочный регистр сведений.

Разберем по шагам логику работы:

При первом запуске пустой конфигурации генерируем уникальный идентификатор с помощью функции Новый УникальныйИдентификатор() и записываем его строковое представление в константу ИдентификаторИнформационнойБазы.
Исключаем эту константу из состава планов обмена распределенной информационной базы (РИБ), чтобы подчиненные узлы не перезаписывали свои идентификаторы при синхронизации.
При выполнении критичных операций считываем значение константы и сопоставляем его с эталоном.

Посмотрим на пример первичной инициализации идентификатора:


Процедура ПроверитьИнициализациюИдентификатораБазы() Экспорт
    
    ИдентификаторТекущий = Константы.ИдентификаторИнформационнойБазы.Получить();
    
    Если ПустаяСтрока(ИдентификаторТекущий) Тогда
        НовыйГУИД = Строка(Новый УникальныйИдентификатор());
        Константы.ИдентификаторИнформационнойБазы.Установить(НовыйГУИД);
    КонецЕсли;
    
КонецПроцедуры

Важно: этот способ фиксирует идентификатор экземпляра, но если сделать прямую копию базы через бэкап СУБД, значение константы перенесется в копию. Поэтому для распознавания копии его необходимо дополнять проверкой параметров размещения.

Способ 3. Комплексный механизм защиты от работы в копии (подход БСП)

В Библиотеке стандартных подсистем (БСП) реализован комплексный алгоритм контроля перемещения базы:

Фиксация параметров при установке: при первом запуске или подтверждении администратором текущая строка соединения (тип размещения, имя сервера, имя базы) сохраняется в служебных параметрах.
Проверка при старте: при каждом запуске сеанса фактическая строка соединения сравнивается с сохраненной эталонной строкой.
Обработка для файловых баз: в каталоге файловой базы создается специальный служебный файл DoNotCopy.txt. При копировании каталога или несовпадении пути система фиксирует факт перемещения.
Блокировка интеграций: если обнаружено несовпадение параметров, взводится параметр сеанса РаботаСВнешнимиРесурсамиЗаблокирована, а к заголовку программы добавляется префикс [КОПИЯ]. Все регламентные задания по отправке почты, обмену по API и синхронизации проверяют этот флаг и завершают выполнение без ошибок.

Пример проверки состояния блокировки в коде фонового задания:


Если РегламентныеЗаданияСервер.РаботаСВнешнимиРесурсамиЗаблокирована() Тогда
    ЗаписьЖурналаРегистрации(
        "Интеграция",
        УровеньЖурналаРегистрации.Предупреждение,
        ,
        ,
        "Выполнение регламентного задания отменено: база является копией."
    );
    Возврат;
КонецЕсли;

Способ 4. Использование системных переменных окружения сервера

Для надежного разграничения продуктивных и тестовых сред на уровне инфраструктуры можно использовать переменные окружения операционной системы сервера приложений 1С.

Разберем логику:

На продуктивном сервере в операционной системе задается переменная среды, например: ENVIRONMENT_TYPE=PRODUCTION.
На тестовых серверах переменная отсутствует либо имеет значение STAGE или DEV.
На стороне сервера 1С считывается переменная через системный объект WScript.Shell или параметры среды. Если признак продуктивной среды не подтвержден, база автоматически переходит в тестовый режим, независимо от того, какие IP-адреса используют клиенты.

Итоги

Для простых задач и самописных конфигураций достаточно использовать функцию СтрокаСоединенияИнформационнойБазы() с нормализацией регистра и проверкой имени базы. Для масштабных систем рекомендуется использовать типовые механизмы БСП (контроль перемещения базы и блокировку работы с внешними ресурсами), что гарантирует защиту продуктивных данных от случайного вмешательства из тестовых копий.