При работе со встроенной справочной системой 1С:Предприятие разработчики часто сталкиваются с ситуацией, когда ссылки на объекты метаданных (справочники, документы, формы) представлены в виде уникальных идентификаторов (GUID). Это создает определенные трудности, если необходимо программно проверить целостность этих ссылок или понять, на какой именно объект ссылается справка, не открывая её в режиме пользователя. В этой статье мы подробно разберем природу этих идентификаторов и изучим несколько способов сопоставления GUID с реальными объектами конфигурации.
Прежде всего, проанализируем, что именно представляет собой GUID в ссылке справки. Важно понимать, что это внутренний идентификатор объекта метаданных. Он отличается от ссылочного идентификатора (UUID), который мы привыкли видеть у элементов справочников или документов в информационной базе. Внутренний ID объекта метаданных фиксируется в момент создания объекта в конфигураторе и остается неизменным при переносе конфигурации через файлы .cf. Ссылки в справке обычно имеют формат v8help://..., где после протокола следует именно этот внутренний идентификатор.
Самый простой и эффективный метод поиска «битых» ссылок (ссылок, указывающих на удаленные объекты) — это использование стандартных инструментов платформы. Рассмотрим, как это сделать правильно, так как обычное тестирование конфигурации по умолчанию может не затрагивать справку.
Разберем процесс по шагам:
Проанализируем результат: платформа автоматически просканирует все HTML-документы справочной информации, извлечет из них ссылки и сопоставит их с текущим деревом метаданных. Если объект, на который указывает GUID, был удален или переименован (в некоторых случаях иерархии), система выдаст предупреждение с указанием конкретного раздела справки и идентификатора проблемного объекта.
Если нам необходимо программно получить карту соответствия «Имя объекта — GUID» для автоматизации своих задач, рассмотрим метод выгрузки конфигурации. При выгрузке в файлы 1С создает реестр всех объектов.
Выполним следующие действия:
ConfigDumpInfo.xml.Этот файл является ключом к решению задачи. В нем содержатся узлы ConfigObject, которые описывают каждый элемент метаданных. Рассмотрим пример структуры такого узла:
<ConfigObject id="53e67303-3700-4744-8843-157945d84950" href="Catalog.Номенклатура.xml"/>
Здесь атрибут id — это тот самый GUID, который используется в справке, а href указывает на имя объекта. Проанализируем, как мы можем программно прочитать этот файл в 1С для поиска нужного объекта:
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.ОткрытьФайл(ПутьКФайлуРеестра);
Пока ЧтениеXML.Прочитать() Цикл
Если ЧтениеXML.ТипУзла = ТипУзлаXML.НачалоЭлемента И ЧтениеXML.Имя = "ConfigObject" Тогда
Идентификатор = ЧтениеXML.ПолучитьАтрибут("id");
ИмяОбъекта = ЧтениеXML.ПолучитьАтрибут("href");
Если Идентификатор = ИскомыйGUID Тогда
Сообщить("Объект найден: " + ИмяОбъекта);
Прервать;
КонецЕсли;
КонецЕсли;
КонецЦикла;
ЧтениеXML.Закрыть();
Рассмотрим ситуацию, когда мы не хотим выгружать всю конфигурацию, а нам нужно получить GUID конкретного объекта программно прямо в коде. Для этого можно воспользоваться сериализацией метаданных в XML. Выясним, как это работает на практике.
При записи объекта метаданных в поток XML платформа выгружает его внутренние свойства, включая идентификатор. Посмотрим на пример кода:
Функция ПолучитьВнутреннийID(ОбъектМетаданных)
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
// Сериализуем объект метаданных
СериализаторXDTO.ЗаписатьXML(ЗаписьXML, ОбъектМетаданных, , , НазначениеТипаXML.Явное);
СтрокаXML = ЗаписьXML.Закрыть();
// В полученной строке XML в атрибутах будет содержаться uuid или внутренний идентификатор
// В зависимости от версии платформы и типа объекта, парсим строку для поиска GUID
Возврат ИзвлечьGUIDИзСтроки(СтрокаXML);
КонецФункции
Этот метод позволяет создать динамическую таблицу соответствий всех объектов метаданных и их GUID в оперативной памяти для последующей проверки ссылок в текстах справки.
Если ваша разработка ведется с использованием 1C:EDT, задача значительно упрощается. В EDT проект изначально хранится в виде набора XML-файлов и папок. Проанализируем структуру проекта: каждый объект метаданных имеет свой XML-файл (например, Catalogs/Номенклатура.mdo).
Внутри такого файла корневой тег всегда содержит атрибут uuid. Рассмотрим пример:
<mdclass:Catalog xmlns:mdclass="http://g5.1c.ru/v8/dt/metadata/mdclass" uuid="53e67303-3700-4744-8843-157945d84950">
<name>Номенклатура</name>
...
</mdclass:Catalog>
Для поиска объекта по GUID достаточно нажать Ctrl+H (глобальный поиск) по всему проекту и вставить искомый GUID. EDT мгновенно найдет XML-описание объекта, которому принадлежит этот идентификатор. Это самый быстрый «ручной» способ сопоставления.
Важно помнить, что ссылки в справке могут вести не только на корневые объекты (например, справочник целиком), но и на их подчиненные элементы: конкретные формы или команды. В этом случае GUID в ссылке будет соответствовать идентификатору именно формы.
Разберем, как это учитывать при программном поиске:
ConfigDumpInfo.xml такие объекты также будут иметь свои записи.Forms или Commands.Мы рассмотрели различные методы работы с идентификаторами в справочной системе 1С. Для быстрой проверки целостности лучше всего подходит штатный механизм проверки конфигурации с включенным флагом проверки логической целостности справки. Для решения сложных задач автоматизации и массового поиска объектов наиболее надежным способом будет анализ файла реестра выгрузки конфигурации (ConfigDumpInfo.xml), так как он содержит полную и структурированную карту всех внутренних идентификаторов системы.