Итак начнем

Вначале краткий ликбез по тому как храняться описания метаданных 1С. Все описания метаданных базы данных хранятся в таблице Config, изменения внесенные в конфигурацию  конфигуратором  (изменения можно вносить также с помощью Enterprise Integrator) сохраняются в таблице ConfigSave. После обновления конфигурации записи из таблицы ConfigSave заменяют записи из таблицы Config.

Структура обоих этих таблиц одинакова. В качестве ключа представлено поле FileName  в этом поле храниться уникальный идентификатор объекта метаданных ( в данном случае это это может быть как какой-то прикладной объект, так и некоторые свойства этого объекта, такие как Макеты и Формы). Подробнее..

Нас в данном случае будут интересовать записи таблицы Config, в которых описаны реквизиты, табличные части и прочие свойства метаданных. В форме объектов конфигурации данные записи будут иметь имя «Метаданные» и будут подчинены непосредственно объекту конфигурации (описание метаданные существуют также для форм но кроме названия и версий форм они содержат мало интересного).

В версии 8.0 все записи с именем «Метаданные»(описание метаданных), всех!! объектов метаданных были объединены в одну (metadata)-эта запись была самой большой в конфигурации, что и затрудняло ее редактирование.

Цели

Для изменения метаданных объекта конфигурации достаточно:

• отредактировать запись описания метаданных;

• изменить версию объекта конфигурации и всей конфигурации(используется запись Versions);

Посмотрим, что же содержит в себе запись описания метаданных.

Структура запись похожа на Xml файл где вместо разделителей <> разделители {} Элементы, содержавшие набор однотипных объектов содержат флаговый идентификатор(45е46cbc-3…… или любой другой), после которого перечислено количество объектов в элементе (22).

На рисунке изображен один из 22, элемент набора записей, который характеризует реквизиты объектов метаданных. Этот блок текста представляет собой внутренне значение реквизита метаданных. (Жаль что объекты метаданных не сериализуются, в противном случае вероятно данный блок текста можно было бы, получить используя следующую конструкцию ЗначениеВСтрокуВнутр(Метаданные.Документы.АВСКлассификация.Реквизиты.Комментарий)) . Изменяя состав элементов содержащихся в блоке, мы меняем состав реквизитов метаданных или их свойства в том случае если меняем значения элементов блока.

Общий подход

Поле того, как мы определились с целями, поговорим о текущей реализации.

Не так сложно получить (прочитать внутреннее значение элементов метаданных) как их отредактировать с учетом требований.EnterpriseIntegrator предлагает следующее универсальное решение.

Внутреннее представление можно представить в виде структуры значений, содержащие списки значений. В списки значений помещаются однотипные объекты элементов, во главе которых стоит флаговый идентификатор, по этому флаговому идентификатору и определяются, какое свойство объектов метаданных перечислено в списке (таблица соответствий, Флаговый идентификатор-Свойство находится Настройка - Объекты конфигурации - Обозреватель объектов). Список значений, свойств объектов метаданных, формируется таким образом, чтобы при его обратном представлении в строковое представление, было получено такое же строковое значение элемента, как и до преобразования.

В рамках этой стратегии для изменения реквизитов объектов метаданных нужно выполнить следующий алгоритм.

Разобрать объект метаданных и сформировать структуру, скопировать один из элементов структуры и изменить его, после чего исходное значение элемента структуры и измененное преобразовывается в строковые представления. Полученные строковые представления заменятся одно на другое в представлении объекта метаданных.

Структура свойства

Что делать с набором свойств более, менее понятно. На этом можно было бы, остановится, если бы нам требовалось только удалять элементы наборов свойств объектов метаданных. Однако это, скорее всего, делать в групповой обработке и не придется…. Большую необходимость имеют такие групповые действия с объектами метаданных как добавление или изменение, и для того, что бы осуществлять эти операции необходимо разобрать внутреннюю структуру элемента набора свойств объекта метаданных.

На рисунке представлен реквизит документа. Почти все свойства метаданных (реквизиты) разных типов прикладных объектов различны и следовательно внутренне представление этих свойств за исключением некоторых полей (UNID,Имя, Синоним, Комментарий[,Тип]) различны. Постоянной структурой любого реквизита объекта метаданных являются не затененные элементы, структура затененных элементов может меняться в зависимости от:

• типа прикладного объекта;

• значения свойства;

• в рамках одного элемента от значения дополнительных свойство объекта метаданных в целом, например для справочника (иерархический, не иерархический), для регистра сведений (подчинен или не подчинен регистратору) и т.п.
  

Таким образом, мы выяснили, что относительно начала списка значений (начала строки) все элементы одинаковы. Однако как хорошо, что все в этом мире относительно и к своей радости мы замечаем, что относительно Unid все элементы свойств метаданных (реквизитов) до какой то границы (как вверх, так и вниз) одинаковы. Для того, что предоставить пользователю, более-менее приемлемые методы изменения значений элемента свойства метаданных. Создана структура, в которую помешены элементы списков значений.

Имя	Значение(для первых 2 рисунков)
Unid	СписокЗначений[0],Значение[0].Значение[1].Значение[1].Значение[2]
Имя	СписокЗначений[0],Значение[0].Значение[1].Значение[2]
Синоним	СписокЗначений[0],Значение[0].Значение[1].Значение[3] .Значение[2]
Комментарий	СписокЗначений[0],Значение[0].Значение[1].Значение[4]
Тип	СписокЗначений[0],Значение[0].Значение[2]

Причем расчет адресов элементов структуры происходить относительно уникального идентификатора, то есть вначале рассчитывается адрес Unid (0,0,1,1,2) после чего для остальных элементов рассчитывается отклонение от адреса Unid, (как я уже упоминал) «теория относительности» нам немного помогла.

Выше приведенный код изменяет для всех элементов свойства (в данном случае «реквизиты») объекта метаданных, уникальный идентификатор и добавляет к комментариям определенную строку. В данном коде следует обратить внимание на то, что обращение к свойствам объекта метаданных для чтения или записи, происходит следующим образом:

ОбъектМетаданных(<Элемент коллекции (Реквизит)>).[Ключ].Значение=;

МД.UNID.Значение=

потому что в структуре хранится элемент списка значений.

Копирование элементов

Ну теперь мы вплотную подошли к самому сложному.

Попробуем перефразировать крылатую фразу.

«Для того что бы что-то куда-то вставить нужно что то и где-то скопировать?»

Вот для того, что бы определить это «что- то» и «где-то» нужно определится с источником. Источником может быть любой объект конфигурации с необходимым набором параметров, то есть источником для вставки элемента в реквизиты документа, справочника,… и т.д. может являться любое измерение или ресурс, возможно и обратное, однако измерение содержит больше свойств чем например реквизит (Ведущее, Запрет незаполненных значений), поэтому при добавлении эти свойства примут такое же значение, как и первый элемент коллекции, в которую добавляется новый элемент. Отличатся эти элементы (первый элемент коллекции и добавляемый элемент) будут только элементами постоянной структуры объектов метаданных (см. выше не затененные элементы).

На рисунке изображен результат копирования реквизита табличной части документа в измерения регистра сведений.

Однако для большей надежности рекомендуется копировать реквизиты одного типа. Это увеличит скорость копирования реквизитов и компенсирует возможные коллизии.

Для того что бы определить те реквизиты которые будем копировать необходимо в форме «Объекты конфигурации» выбрать в дереве объектов источник (прикладной объект содержащий нужные реквизиты). Для каждого прикладного объекта существуют в таблице Config запись без окончания (см. Формат уникального идентификатора) в этих записях, как уже было сказано выше, и хранится описание свойств метаданных прикладного объекта. После открытия этой записи в форме «Встроенного языка», в правой части этой формы будет сформирован обозреватель объекта – дерево значений, сформированное на основе внутреннего представления свойств метаданных, строится на основании флаговых идентификаторов перечисленных в настройках Параметры – Объекты конфигурации – Обозреватель объектов, колонки этого дерева содержат все доступные свойства элемента коллекции (пока это Unid,Имя, Синоним, Комментарий и Тип). Именно в обозревателе объектов нужно выбрать необходимые элементы свойств и передать их в форму "Конструктор запросов" для групповой обработки, выбрав пункт контекстного меню в обозревателе объекта.

В результаты запроса конструктора также передастся дерево конфигурации именно по нему мы можем определить, в какие прикладные объекты нам нужно добавить выбранные свойства.

Как уже упоминалось в самом начале, нас интересует только метаданные прикладных объектов, поэтому отметим только эти строчки в результатах запроса, для нужных (редактируемых) объектов. Это достаточно просто сделать еще количество редактируемы реквизитов не велико… Но мы затеяли всю эту «кашу» не для того чтобы «тупо» сидеть и выбирать 200 элементов например справочников в дереве значений. Поскольку редактировать тексты модулей или формы в нашу задачу сейчас не входит то по большей части нам необходимы только внутренние идентификаторы определенных прикладных объектов. Получить соответствие ПолноеИмя -Unid можно используя шаблон «Метаданные» Действия – Шаблоны –Метаданные (перебор) в форме «Конструктор запроса» . Данный шаблон представляет из себя следующее выражение на встроенном языке:

Результат=Новый ТаблицаЗначений;
Результат.Колонки.Добавить("Имя");
Результат.Колонки.Добавить("FileName");
Для каждого Объект из Справочники.ТипВсеСсылки().Типы()Цикл

//Для каждого Объект из Параметры.ТипыМД.Типы() Цикл //выбранные типы