Общие правила обмена объектами метаданных между конфигурациями
В процессе разработки часто возникает необходимость переноса объектов метаданных между конфигурациями. Платформа 1С:Предприятие 8 предоставляет несколько механизмов, которые в той или иной степени позволяют решать данную задачу. К ним относятся:
- Копирование объектов метаданных через буфер обмена
- Объединение конфигурации с файлом
- Загрузка конфигурации из файла
- Хранилище конфигурации
- Обновление конфигурации, находящейся на поддержке
- Обновление конфигурации базы данных
В данной статье рассматриваются некоторые особенности работы этих механизмов, которые позволяют прогнозировать результат перемещений объектов по «цепочкам» конфигураций и правильно выбирать соответствующий механизм. Следует заметить, что статья не является подробным руководством по использованию данных механизмов.
Сопоставление объектов. Имя и идентификатор объекта метаданных
При перемещении объектов между конфигурациями важную роль играет вопрос их сопоставления. Необходимо иметь возможность определить, являются ли два данных объекта разными объектами или копиями одного и того же объекта. Предположим, что мы тем или иным способом скопировали объект из одной конфигурации в другую, а затем выполнили объединение этих конфигураций. Естественно ожидать, что платформа определит соответствие двух объектов, а не будет считать их разными объектами с одинаковыми именами. Для сопоставления объектов используются имя и внутренний идентификатор объекта. И если имя в процессе перемещения объекта, как правило, не изменяется (в любом случае мы можем его контролировать и, при необходимости, модифицировать), то внутренний идентификатор объекта ведет себя по-разному в зависимости от используемого механизма. В приведенной ниже таблице описываются способы сопоставления объектов и поведение внутренних идентификаторов при использовании разных механизмов.
При отключенной возможности изменений – сопоставление по идентификаторам. При включенной возможности изменений – сопоставление по идентификаторам, которые в некоторых случаях могут отличаться. В некоторых ситуациях возможна ручная установка соответствия.
Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:
- Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
- Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при включенной возможности изменений.
- Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.
Можно определить следующее правило:
Для обеспечения корректного сопоставления объектов уровень механизмов нельзя понижать.
Например, имеются две конфигурации: одна, в которой ведется разработка и вторая — в «рабочей» базе. Новые версии разрабатываемой конфигурации переносятся при помощи механизма загрузки конфигурации с последующим обновлением конфигурации базы данных. Используемый механизм переноса объектов относится к первому уровню, и идентификаторы при переносе не изменяются. Предположим, что для очередного обновления был использован механизм объединения конфигураций. Проблемы при этом не возникнет, поскольку для «старых» объектов, присутствовавших в предыдущих версиях, идентификаторы не изменились. Однако новые объекты попали в «рабочую» базу с измененными идентификаторами. Для дальнейших переносов новых версий нужно будет использовать только механизм объединения конфигураций, поскольку при выполнении загрузки (то есть при понижении уровня механизма со второго на первый), идентификаторы некоторых объектов «восстановятся» с точки зрения конфигурации разработки, но изменятся с точки зрения «рабочей» конфигурации. В этом случае при обновлении конфигурации базы данных произойдет потеря данных.
Примеры
Параллельное создание объектов
Используется одна конфигурация в двух разных базах: в базе разработки и в базе заказчика. При обновлении конфигурации заказчика, была на месте произведена доработка, в результате которой в базу был добавлен новый объект. Затем в конфигурации разработки этот объект был добавлен вручную. Фактически мы воспользовались механизмом третьего уровня (поскольку идентификаторы у объектов получились разные). Для дальнейшей синхронизации конфигураций без потери данных можно применять только объединение (механизм третьего уровня). Для того, что бы избежать подобных проблем, следует после доработки у заказчика сохранить конфигурацию в файл, а затем загрузить ее в базу разработки.
Восстановление автоматической поддержки конфигурации поставщика
Конфигурация находится на поддержке в полностью автоматическом режиме (с отключенной возможностью изменений). Предположим, что в какой-то момент возможность изменений была включена. Например, это понадобилось для срочного исправления ошибки. После исправления ошибки поставщиком, возникла необходимость отключить возможность изменений для облегчения последующих обновлений. Но это приведет к понижению уровня механизма, а следовательно гарантированного сохранения данных информационной базы при этом добиться будет невозможно. Следует создать новую базу из дистрибутива конфигурации поставщика (с выключенной возможностью изменений) и программно перенести в нее данные.
Примеры анализа цепочки изменений конфигурации
Приведем несколько примеров анализа цепочки изменений конфигурации с точки зрения возможности потери данных.
Например, конфигурация хранилища была сохранена в файл. Это механизм первого уровня. В другой базе было выполнено объединение конфигурации с этим файлом. Уровень повысился до третьего. Затем возникла необходимость подключить эту базу к хранилищу. Механизм хранилища работает на первом уровне, поэтому при этом будет возможна потеря данных.
Другой пример. Мы ведем разработку конфигурации в некоторой базе и готовим в ней файлы поставки. Кроме того, у нас есть подготовленная демонстрационная база, которую мы поставляем пользователям. После создания файла поставки очередной версии мы загружаем его в демонстрационной базе. Все использованные механизмы работают на первом уровне, поэтому расхождения идентификаторов и потери данных не произойдет.
Для получения более подробной информации по поведению идентификаторов и сопоставлению объектов, мы рекомендуем ознакомиться с циклом статей «Поставка и поддержка конфигураций».
Особенности предопределенных элементов объектов метаданных
Для некоторых объектов метаданных в платформе 1С:Предприятие 8 есть возможность задавать в конфигурации предопределенные элементы, для которых в информационной базе будут автоматически создаваться объекты с заданными значениями. В данной статье рассматриваются некоторые особенности их реализации и работы с ними.
Общие принципы реализации
Внутренний идентификатор
Каждый предопределенный элемент имеет внутренний идентификатор, который соответствует идентификатору объекта информационной базы, соответствующего данному предопределенному элементу.
Обновление конфигурации базы данных
При обновлении конфигурации базы данных для вновь созданных предопределенных элементов создаются новые объекты информационной базы. Для удаленных, по сравнению с версией конфигурации, хранящейся в базе данных, элементов, соответствующие объекты информационной базы помечаются на удаление. У этих объектов также снимается признак «Предопределенный». Важно еще раз отметить, что связь между элементом и объектом устанавливается только по внутреннему идентификатору. Следовательно, если в конфигурации присутствовал элемент с именем «А», в процессе редактирования конфигурации мы его удалили и вновь создали элемент с таким же именем, то этим элементам будут соответствовать разные объекты информационной базы. Старый объект будет помечен на удаление и лишится признака «Предопределенный», а новый будет создан. Поскольку в базе данных окажутся два практически одинаковых объекта, будет выдано предупреждение о дублировании кодов.
Поведение идентификаторов предопределенных элементов при копировании и объединении конфигураций
В отличие от идентификаторов объектов метаданных, идентификаторы предопределенных элементов при копировании не изменяются. Таким образом, два различных объекта метаданных могут иметь предопределенные элементы с одинаковыми идентификаторами.
Теперь рассмотрим, как описанные принципы влияют на поведение предопределенных элементов в различных механизмах платформы 1С:Предприятие 8.
Объединение конфигураций
При объединении конфигураций сопоставление между предопределенными элементами выполняется только по идентификатору, а не по имени или коду. Это следует учитывать при выборе правила объединения свойства «Предопределенные данные».
Рассмотрим следующую ситуацию. Вы разрабатываете конфигурацию и устанавливаете ее у заказчика. В процессе настройки возникает необходимость срочной доработки, в частности, добавления предопределенного элемента. Затем в своей основной разрабатываемой конфигурации вы «синхронизируете» изменения, добавляя такой же элемент, осуществляете еще какие-то доработки и приносите новую версию к заказчику.
Если при выполнении объединения конфигураций оставить правило по умолчанию — «Взять из конфигурации поставщика», то в результате останется только «ваша» версия элемента. При выполнении обновления конфигурации информационной базы, как было описано выше, будет создан новый объект, а старый помечен на удаление.
Однако на старый объект могут быть заведены ссылки в других объектах. Для исправления этой ситуации следует найти все ссылки в базе данных на «старый» объект. Это можно сделать с помощью команды «Поиск ссылок на объекты» или в процессе контроля, при выполнении команды «Удаление помеченных объектов». Найденные ссылки следует исправить на ссылки на «новый» объект, после чего «старый» удалить.
Если ссылок много, а дальнейшие объединения с другой конфигурацией не предполагаются (в описываемом сценарии это не так, но, может, вы просто хотите однократно добавить в конфигурацию некоторые объекты из другой), можно поступить иначе. При объединении для предопределенных данных установить правило «Объединять с приоритетом. » (приоритет будет влиять на порядок и место в иерархии предопределенных элементов с одинаковым идентификатором). После выполнения объединения в конфигурации будут присутствовать оба элемента, и старый и новый. Новый можно удалить (до выполнения обновления конфигурации базы данных). Главное, только их не перепутать. Для этого перед сравнением / объединением можно в основной конфигурации временно переименовать элемент, а потом вернуть обратно. При таком алгоритме, предопределенные элементы конфигурации из файла, которые не имеют аналогов, будут добавлены, а «конфликтные» нет.
Наконец, следует напомнить, что если из файловой конфигурации новых предопределенных данных добавлять не надо, то для свойства «Предопределенные данные» можно отключить пометку (флажок) объединения. При этом объединение конфигураций в целом будет выполнено, а предопределенные данные останутся старыми.
Однако различия в предопределенных данных не всегда приводят к подобным проблемам. Рассмотрим другой возможный сценарий. Вы выгружаете конфигурацию в файл, затем редактируете ее где-то в стороне, например, дома. В процессе редактирования добавляются новые предопределенные элементы и, возможно, удаляются или редактируются существующие. Затем выполняется объединение новой версии с оригинальной конфигурацией. В этом случае можно оставить правило объединения «Взять из файла». Как уже отмечалось, в процессе перемещения между различными конфигурациями идентификаторы элементов не изменяются, и все старые элементы вернуться со своими оригинальными идентификаторами.
Обмен данными
Описанный алгоритм поведения идентификаторов предопределенных элементов был использован для обеспечения корректности работы механизма обмена данными.
Рассмотрим следующий сценарий. В обмене участвуют две информационные базы, имеющие независимые конфигурации. В этих конфигурациях есть справочники, между которыми установлена связь. В одной из конфигураций мы добавляем предопределенный элемент. После обновления конфигурации базы данных создается соответствующий объект, который передается во вторую базу. В ней этот объект, естественно, не имеет признака «Предопределенный».
Затем мы объединяем вторую конфигурацию с первой, и копируем предопределенные данные. Поскольку идентификатор элемента не изменяется, то при последующем обновлении конфигурации базы данных, элемент «найдет» свой объект, и не будет создан новый. В случае, если бы идентификаторы элементов изменялись по тем же правилам что и идентификаторы объектов метаданных, подобный сценарий привел бы к проблемам.
1с идентификаторы объектов метаданных зачем он
Что такое объект Метаданные и зачем он может пригодиться?
Объект Метаданные предназначен для доступа к объектам конфигурации, объявленным при ее создании (т.е. в Конфигураторе). Одна из задач, где широко используется метаданные — универсальные обработки, где заранее не известно, с какими видами объектов придется работать. Другая, не менее часто возникающая задача, — универсальная обработка атрибутов похожих но, тем не менее, различных видов объектов (например — одинаковая обработка табличных частей документов, в одном из которых есть «лишнее» поле).
К каким объектам мы можем доступиться, используя Метаданные?
Практически ко всем, объявленным в Конфигураторе: Константа, Справочник, Документ, Журнал, ПланСчетов и т.д.
Синтаксис использования объекта следующий:
Кво = Метаданные.Объект(); // получение количества элементов
МетаОб = Метаданные.Объект(Номер | Идентификатор); // объект метаданных
КвоРекв = МетаОб.Реквизит(); // количество реквизитов
// хотя в некоторых случаях может быть и такой синтаксис:
КвоРекв = МетаОб.Реквизит.Количество; // количество реквизитов
МетаРекв = МетаОб.Реквизит(Номер | Идентификатор); // реквизит объекта
// или для второго случая:
МетаРекв = МетаОб.Реквизит.Получить(Номер); // реквизит объекта
Какой конкретно случай использовать для доступа к объектам — смотрите в документации.
Как видите — доступ к количеству несколько отличается от общепринятого (если такое слово применимо к 1С) получения количества других объектов.
Для проверки существования реквизита с заранее определенным идентификатором используется метод Выбран():
Если Метаданные.Объект(Идентификатор).Выбран()=1 Тогда . // Объект существует
Если МетаОб.Реквизит(Идентификатор).Выбран()=1 Тогда . // Реквизит существует
Объекты метаданных имеют атрибуты, позволяющие определить подробные их характеристики. К таким атрибутам относятся стандартные (Идентификатор, Тип, Вид, Длина, Точность, . ) или специфические для конкретных объектов (ДлинаКода, ДлинаНаименования, ТипНомера, . ).
Приведем простой пример получения списка всех справочников:
Функция СписокДокументов()
Сп=СоздатьОбъект(«СписокЗначений»);
Для И1=1 По Метаданные.Справочник() Цикл
МетаСпр=Метаданные.Справочник(И1);
Сп.Установить(МетаСпр.Синоним, МетаСпр);
КонецЦикла;
Возврат Сп;
КонецФункции
Если я еще не убедил вас в полезности этого объекта — посмотрите, насколько широко он используется в стандартных конфигурациях (только «для Украины»? Или во всех? не знаю. ). Это и «Обработка документов», и функции глЕстьРеквизитШапки, глЕстьРеквизитТабличнойЧасти и другие фичи.
Напоследок рассмотрим более интересный (с практической точки зрения) пример: создание из существующего документа нового, возможно — другого вида.
Процедура КопироватьДокумент(ИсхДок, ВидДок, Сп)
// ИсхДок — исходный документ
// ВидДок — вид нового документа
// Сп — список соответствий реквизитов:
// Значение — реквизит в исходном документе
// Строка — реквизит нового документа
Д=СоздатьОбъект(«Документ.»+ВидДок);
Д.Новый();
МетаДок=Метаданные.Документ(ВидДок);
// Копируем общие реквизиты — для них соответствий не нужно
Для И1=1 По Метаданные.ОбщийРеквизитДокумента() Цикл
ИдРекв=Метаданные.ОбщийРеквизитДокумента(И1).Идентификатор;
// Идентификатор guid уникальный — не копируем!
Если НРег(ИдРекв)=»guid» Тогда Продолжить; КонецЕсли;
Д.УстановитьАтрибут(ИдРекв, ИсхДок.ПолучитьАтрибут(ИдРекв));
КонецЦикла;
// Копируем реквизиты шапки. Несопоставленные — пропускаем
Для И1=1 По МетаДок.РеквизитШапки() Цикл
ИдРекв=МетаДок.РеквизитШапки(И1).Идентификатор;
ИдИсх=Сп.Получить(ИдРекв);
Если ПустоеЗначение(ИдИсх)=1 Тогда Продолжить; КонецЕсли;
Д.УстановитьАтрибут(ИдРекв, ИсхДок.ПолучитьАтрибут(ИдИсх));
КонецЦикла;
// Построчно копируем реквизиты табличной части.
// Как и для реквизитов шапки несопоставленные — пропускаем
ИсхДок.ВыбратьСтроки();
Пока ИсхДок.ПолучитьСтроку()=1 Цикл
Д.НоваяСтрока();
Для И1=1 По МетаДок.РеквизитТабличнойЧасти() Цикл
ИдРекв=МетаДок.РеквизитТабличнойЧасти(И1).Идентификатор;
ИдИсх=Сп.Получить(ИдРекв);
Если ПустоеЗначение(ИдИсх)=1 Тогда Продолжить; КонецЕсли;
Д.УстановитьАтрибут(ИдРекв, ИсхДок.ПолучитьАтрибут(ИдИсх));
КонецЦикла;
КонецЦикла;
// Документ скопирован. Запишем и покажем
Д.Записать();
Конт=»»;
ОткрытьФорму(Д.ТекущийДокумент(), Конт, );
КонецПроцедуры
P.S.: Документацию в формате ALS (формат справки 1С) по метаданным можно найти на сайтах, посвященным 1С программированию, например в Клубе профессионалов 1С. Или воспользоваться поиском на yandex.ru.
P.P.S.: Обработку, выполняющую копирование документов можно взять здесь.
БСП справочник Идентификаторы Объектов Метаданных

Очередной раз я за маньячил БСП, сижу смотрю на весь этот беспредел в скриптах и не могу понять накой фиг нужен этот Справочник?
Кто ни будь, киньте в меня ссылкой на подробное описание этого справочника! ЗАЧЕМ ОН НУЖЕН?
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

Программное создание объектов метаданных
Всем привет! Возможно ли средствами 1С или каким-либо сторонним ПО создать новый объект(документ.

Ошибка Метаданных «не найден идентификатор в справочнике Идентификатор объекта метаданных»
В общем ситуация следующая, только начал разбираться с 1С, скачал с оф сайта учебную версию для.
Подскажите, пожалуйста, для JS полный справочник объектов, свойств, методов
Здравствуйте. Подскажите, пожалуйста, есть ли для JS полный справочник объектов, свойств, методов.
Где можно найти документацию, справочник, описание COM-объектов Excel, Word?
Подскажите где можно найти документацию, справочник, описание COM-объектов Excel, Word? Мой шеф.
Шизофреник
360 / 362 / 83
Регистрация: 25.06.2013
Сообщений: 1,141
Для хранения списка объектов метаданных
как я понял: юзается при сравнении конфигураций (а сравнение юзается при обновлении, обмене+обновлени, совместной разработке конф, итд)
Добавлено через 2 минуты
з.ы. конкретной инфы по справочнику не находил, везде косвенные отсылки к самому явлению «идентификаторы объектов метаданных»
![]()
3777 / 2958 / 588
Регистрация: 10.03.2011
Сообщений: 11,645
Записей в блоге: 1
Сообщение от wladimir_ui 
Для хранения списка объектов метаданных
Т.е. конфигуратора для этого НАМ мало.
Добавлено через 33 секунды
Давайте в Регистре Сведений хранить тексты функций?!
Добавлено через 25 минут
Нашел на ИТСе
Использование идентификаторов объектов метаданных
При необходимости хранить в базе данных ссылку на объект метаданных (например, ссылка на объект метаданных Справочник.Организации) рекомендуется вместо строкового реквизита с полным именем объекта метаданных использовать ссылку на соответствующий элемент справочника ИдентификаторыОбъектовМетаданных. Такая потребность возникает, например, в различных подсистемах БСП: для хранения настроек версионирования данных, списка выбранных ролей в профилях групп доступа и т.п.
Такой подход позволяет
● повысить производительность запросов, которые обращаются к реквизитам данного типа;
● снизить размер таблиц в базе данных, в которых используются реквизиты данного типа,
● выводить в пользовательском интерфейсе представление ссылки вместо строкового имени объекта метаданных,
● а также избавиться от разработки обработчиков обновления и первоначального заполнения ИБ для актуализации строковых реквизитов с полными именами объектов метаданных при изменениях метаданных конфигурации.
Программно, ссылку на объект метаданных можно получить с помощью функции ИдентификаторОбъектаМетаданных общего модуля ОбщегоНазначения.
Справочник ИдентификаторыОбъектовМетаданных заполняется автоматически при первом запуске (и каждом обновлении) конфигурации, согласно метаданным конфигурации, а также автоматически актуализируется при каждом обновлении версии конфигурации (учитываются переименованные, добавленные и удаленные объекты метаданных). Полный список объектов метаданных (справочники, документы, регистры, и т.п.), обновление идентификаторов которых выполняется автоматически, см. в комментарии к функции ИдентификаторОбъектаМетадан*ных общего модуля ОбщегоНазначения.
Исключение составляют подсистемы и роли, обновление идентификаторов которых требуется выполнять вручную. Необходимость обновления идентификаторов подсистем и ролей возникает при их переименовании (а для подсистем – также и в случае их перемещения из одной родительской подсистемы в другую). В противном случае, возможно рассогласование идентификаторов объектов метаданных с объектами метаданных конфигурации.
Для обновления идентификаторов необходимо воспользоваться процедурой ЗаполнитьТаблицуПереименованияОбъектовМетаданных общего модуля ОбщегоНазначенияПереопределяемый и увеличить номер версии конфигурации. Например, следующий фрагмент кода описывает, что в версии конфигурации 2.0.1.2 подсистема _ДемоПоставляемыеДанные была перенесена из подсистемы _ДемоРаботаВМоделиСервиса в _ДемоНастройкаИАдминистрирование:
1 2 3 4 5 6 7 8
Процедура ЗаполнитьТаблицуПереименованияОбъектовМетаданных(Итог) Экспорт // _Демо начало примера ОбщегоНазначения.ДобавитьПереименование(Итог, "2.0.1.2", "Подсистема._ДемоРаботаВМоделиСервиса.Подсистема._ДемоПоставляемыеДанные", "Подсистема._ДемоНастройкаИАдминистрирование.Подсистема._ДемоПоставляемыеДанные"); // _Демо конец примера КонецПроцедуры
Обновление идентификаторов выполняется последовательно по версиям конфигурации, а в пределах одной версии – в порядке следования строк со сведениями о переименованиях. Обновление идентификаторов для переименованных подсистем выполняется также и для всех их дочерних подсистем (если они есть).
Отдельным случаем, когда обновление идентификаторов происходит автоматически, является переименование объектов метаданных с целью изменения структуры данных с помощью создания новой копии объекта метаданных. Такая необходимость возникает, когда реструктуризация объекта метаданных невозможна. Например, при сокращении длины кода справочника Подразделения с 50 до 11, может потребоваться создать новый справочник, а старый переименовать в УдалитьПодразделения. В этом случае идентификатор справочника будет автоматически назначен новому справочнику с тем же именем.
Однако если при этом новый справочник будет назван иначе, например, СтруктурныеЕдиницы, то потребуется отразить переименование справочника Подразделения в справочник СтруктурныеЕдиницы, как это описано выше.
При активной разработке конфигурации данные справочника ИдентификаторыОбъектовМетаданных можно также обновлять вручную, без увеличения номера версии конфигурации, с помощью команды Обновить данные справочника в форме списка (открыв ее, например, из меню Все функции). Однако, это допустимо только в случае, когда не производилось переименование ролей и/или подсистем. В случае переименования ролей и/или подсистем, перед выполнением команды Обновить данные справочника нужно выполнить переименование полных имен соответствующих элементов справочника. Для этого нужно открыть форму элемента справочника ИдентификаторыОбъектовМетаданных, выполнить команду Включить возможность редактирования в меню Все действия и задать новое полное имя. В противном случае, этот элемент справочника будет помечен на удаление и создан новый, что приведет к рассогласованию идентификаторов объектов метаданных с объектами метаданных конфигурации.
Добавлено через 1 минуту
Сообщение от Dethmontt 