Основное изменение заключается в том, что созданием предопределенных элементов теперь можно управлять самостоятельно.
Кроме того, появилась возможность добавлять и удалять предопределенные элементы из режима Предприятия. Но - нельзя создать произвольный предопределенный элемент. Вы можете только назначить любому существующему элементу одно из предопределенных в Конфигураторе имен.
Для управления созданием предопределенных элементов существуют следующие механизмы:
1) В Конфигураторе для объекта метаданных можно определить способ обновления предопределенных данных - Авто, Обновлять автоматически, Не обновлять автоматически.
2) Для информационной в целом можно установить режим создания предопределенных через метод:
УстановитьОбновлениеПредопределенныхДанныхИнформационнойБазы(ОбновлениеПредопределенныхДанных), где
ОбновлениеПредопределенныхДанных - системное перечисление с вариантами Авто, Обновлять автоматически, Не обновлять автоматически
3) Для конкретной таблицы информационной базы можно установить режим создания предопределенных через менеджера через метод:
УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных), например
Справочники.Номенклатура.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
4) На создание предопределенных элементов также влияет тип информационной базы - главный узел РИБ (не подчинен ни одному плану обмена, являющемуся РИБ) или периферийный узел РИБ.
Цитата из справки:
Фактический режим обновления определяется в следующем порядке:
Посмотрим несколько стандартных случаев:
1) Имеем некую информационную базу без использования РИБ.
В этом случае, все должно быть хорошо - если для метаданных конфигурации выставлен способ обновления предопределенных = "Авто" и программно режим не был переопределен для информационной базы в целом или отдельной таблицы, то предопределенные элементы будут созданы\обновлены при реструктуризации информационной базы (это может быть при создании ИБ из cf, установке нового релиза конфигурации или проведения реструктуризации через тестирование и исправление).
2) Имеем некую информационную базу с использованием РИБ.
В этом случае, по умолчанию в периферийной базе предопределенные элементы не будут создаваться для всех объектов метаданных.
Если объект метаданных входит в РИБ, то предопределенные элементы будут созданы либо при создании начального образа, либо при выполнении обмена с главным узлом, но не в момент обновления конфигурации, а в момент чтения сообщения обмена.
Если объект метаданных не входит в РИБ, то предопределенные элементы созданы не будут, соответственно база не будет пригодной к работе.
Что можно сделать:
- выставлять способ обновления для объекта метаданных в конфигурации = "Обновлять автоматически" не совсем правильно, если в конфигурации есть несколько разных планов обмена РИБ с разным составом, а этот объект входит только в часть из них. Если это сделать, то в данной конкретной ситуации ошибка будет исправлена - в периферийном узле предопределенные элементы будут созданы. Но при создании РИБ по другим планам обмена (куда данный объект входит) элементы задублируются - в периферийный узел придут предопределенные из главного узла.
- использовать метод для установки способа обновления на всю ИБ также неправильно - будет создано даже то, что должно прийти с обменом из главного узла, и появится куча дублей.
- осталось только установить способ обновления для конкретных таблиц информационной базы. Прописываем все объекты где-нибудь при начале работы системы и до обращения к предопределенным элементам, которые еще не создались. В принципе, это код можно выполнить и разово для информационной базы через внешнюю обработку, но в нашем случае в базу периферийного узла даже зайти не удавалось из-за того, что к предопределенным элементам, не мигрирующим из главного узла, было обращение при начале работы системы:
Если ТипЗнч(ПланыОбмена.ГлавныйУзел()) = Тип("ПланОбменаСсылка.Разработка") Тогда //если это не РИБ, или узел иного плана обмена, то код выполнятся не должен.
Если РольДоступна("ПолныеПрава") Тогда //методы ниже требуют прав на удаление объектов, поэтому правильнее выполнять их под полными правами
Справочники.ГруппыПользователей.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
Справочники.ГруппыВнешнихПользователей.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
КонецЕсли;
КонецЕсли;
Еще один не самый приятный момент - если вы уже запускали периферийный узел и после обновления обращались первый раз к таблицам (даже просто открыли список справочника, например), а уже потом вставили код для установки способа обновления, то выполнение этого кода не приведет к созданию предопределенных элементов.
Чтобы это исправить придется выполнить реструктуризацию информационной базы через тестирование и исправление.
Отдельного метода, который позволил бы принудительно вызвать создание предопределенных, нет.
Предопределенные элементы можно создать руками, но будьте осторожны, если используете клиент-серверный режим и платформу 8.3.4 - после добавления элементов вручную велика вероятность того, что войти в базу больше не получится - при запуске получите "На сервере 1С произошла неисправимая ошибка", и только в логах технологического журнала можно будет увидеть, что система пыталась вставить дублирующееся по GUID значение в таблицу.
3) Создание нового периферийного узла без выгрузки начального образа.
Не уверен насколько этот метод распространен, но я уже в 7.7 использовал окольный путь для создания нового узла, лишь бы не блокировать монопольно главный узел на длительное время. В 8-ке все стало намного проще и полностью реализуется типовыми средствами.
Обычно для создания нового узла выгружается начальный образ при этом он будет наполнен корректно всей информацией, в том числе, мигрирующими предопределенными значениями. Но это требует монопольной блокировки базы, что при больших объемах просто неприемлемо.
Другой вариант - на базе конфигурации главного узла создать пустую базу, затем создать в обеих базах узлы, привязать периферийный узел к главному, зарегистрировать объекты к обмену и дождаться окончания обмена. И все это в спокойном режиме без монопольной блокировки базы. Но с новым подходом к созданию предопределенных в этом случае получим проблему - при создании новой базы они еще не будет привязана к главному узлу, соответственно, система создаст все предопределенные элементы, а потом их дубли придут из главного узла.
Для устранения этой проблемы разработчики платформы рекомендуют следующее:
Кроме того, появилась возможность добавлять и удалять предопределенные элементы из режима Предприятия. Но - нельзя создать произвольный предопределенный элемент. Вы можете только назначить любому существующему элементу одно из предопределенных в Конфигураторе имен.
Для управления созданием предопределенных элементов существуют следующие механизмы:
1) В Конфигураторе для объекта метаданных можно определить способ обновления предопределенных данных - Авто, Обновлять автоматически, Не обновлять автоматически.
2) Для информационной в целом можно установить режим создания предопределенных через метод:
УстановитьОбновлениеПредопределенныхДанныхИнформационнойБазы(ОбновлениеПредопределенныхДанных), где
ОбновлениеПредопределенныхДанных - системное перечисление с вариантами Авто, Обновлять автоматически, Не обновлять автоматически
3) Для конкретной таблицы информационной базы можно установить режим создания предопределенных через менеджера через метод:
УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных), например
Справочники.Номенклатура.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
4) На создание предопределенных элементов также влияет тип информационной базы - главный узел РИБ (не подчинен ни одному плану обмена, являющемуся РИБ) или периферийный узел РИБ.
Цитата из справки:
Фактический режим обновления определяется в следующем порядке:
- Если для объекта метаданных в данных установлен режим обновления, отличный
от Авто,
то используется это значение. (пункт 3 из списка выше)
- Иначе, если для объекта метаданных в конфигурации установлен режим обновления, отличный от Авто, то используется это значение. (пункт 1 из списка выше)
- Иначе, если для информационной базы установлен режим обновления, отличный от Авто, то используется это значение. (пункт 2 из списка выше)
- Иначе, если это периферийный узел РИБ, то предопределенные данные не будут обновлены. Если проверка выполняется для центрального узла РИБ, или для базы, не являющейся РИБ, обновление предопределенных данных будет выполнено.
Посмотрим несколько стандартных случаев:
1) Имеем некую информационную базу без использования РИБ.
В этом случае, все должно быть хорошо - если для метаданных конфигурации выставлен способ обновления предопределенных = "Авто" и программно режим не был переопределен для информационной базы в целом или отдельной таблицы, то предопределенные элементы будут созданы\обновлены при реструктуризации информационной базы (это может быть при создании ИБ из cf, установке нового релиза конфигурации или проведения реструктуризации через тестирование и исправление).
2) Имеем некую информационную базу с использованием РИБ.
В этом случае, по умолчанию в периферийной базе предопределенные элементы не будут создаваться для всех объектов метаданных.
Если объект метаданных входит в РИБ, то предопределенные элементы будут созданы либо при создании начального образа, либо при выполнении обмена с главным узлом, но не в момент обновления конфигурации, а в момент чтения сообщения обмена.
Если объект метаданных не входит в РИБ, то предопределенные элементы созданы не будут, соответственно база не будет пригодной к работе.
Что можно сделать:
- выставлять способ обновления для объекта метаданных в конфигурации = "Обновлять автоматически" не совсем правильно, если в конфигурации есть несколько разных планов обмена РИБ с разным составом, а этот объект входит только в часть из них. Если это сделать, то в данной конкретной ситуации ошибка будет исправлена - в периферийном узле предопределенные элементы будут созданы. Но при создании РИБ по другим планам обмена (куда данный объект входит) элементы задублируются - в периферийный узел придут предопределенные из главного узла.
- использовать метод для установки способа обновления на всю ИБ также неправильно - будет создано даже то, что должно прийти с обменом из главного узла, и появится куча дублей.
- осталось только установить способ обновления для конкретных таблиц информационной базы. Прописываем все объекты где-нибудь при начале работы системы и до обращения к предопределенным элементам, которые еще не создались. В принципе, это код можно выполнить и разово для информационной базы через внешнюю обработку, но в нашем случае в базу периферийного узла даже зайти не удавалось из-за того, что к предопределенным элементам, не мигрирующим из главного узла, было обращение при начале работы системы:
Если ТипЗнч(ПланыОбмена.ГлавныйУзел()) = Тип("ПланОбменаСсылка.Разработка") Тогда //если это не РИБ, или узел иного плана обмена, то код выполнятся не должен.
Если РольДоступна("ПолныеПрава") Тогда //методы ниже требуют прав на удаление объектов, поэтому правильнее выполнять их под полными правами
Справочники.ГруппыПользователей.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
Справочники.ГруппыВнешнихПользователей.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
КонецЕсли;
КонецЕсли;
Еще один не самый приятный момент - если вы уже запускали периферийный узел и после обновления обращались первый раз к таблицам (даже просто открыли список справочника, например), а уже потом вставили код для установки способа обновления, то выполнение этого кода не приведет к созданию предопределенных элементов.
Чтобы это исправить придется выполнить реструктуризацию информационной базы через тестирование и исправление.
Отдельного метода, который позволил бы принудительно вызвать создание предопределенных, нет.
Предопределенные элементы можно создать руками, но будьте осторожны, если используете клиент-серверный режим и платформу 8.3.4 - после добавления элементов вручную велика вероятность того, что войти в базу больше не получится - при запуске получите "На сервере 1С произошла неисправимая ошибка", и только в логах технологического журнала можно будет увидеть, что система пыталась вставить дублирующееся по GUID значение в таблицу.
3) Создание нового периферийного узла без выгрузки начального образа.
Не уверен насколько этот метод распространен, но я уже в 7.7 использовал окольный путь для создания нового узла, лишь бы не блокировать монопольно главный узел на длительное время. В 8-ке все стало намного проще и полностью реализуется типовыми средствами.
Обычно для создания нового узла выгружается начальный образ при этом он будет наполнен корректно всей информацией, в том числе, мигрирующими предопределенными значениями. Но это требует монопольной блокировки базы, что при больших объемах просто неприемлемо.
Другой вариант - на базе конфигурации главного узла создать пустую базу, затем создать в обеих базах узлы, привязать периферийный узел к главному, зарегистрировать объекты к обмену и дождаться окончания обмена. И все это в спокойном режиме без монопольной блокировки базы. Но с новым подходом к созданию предопределенных в этом случае получим проблему - при создании новой базы они еще не будет привязана к главному узлу, соответственно, система создаст все предопределенные элементы, а потом их дубли придут из главного узла.
Для устранения этой проблемы разработчики платформы рекомендуют следующее:
- После загрузки и обновления конфигурации периферийного узла запустить Конфигуратор в пакетном режиме с командой "/SetPredefinedDataUpdate -DoNotUpdateAutomatically"
- выполнить действия по настройке узлов
- запустить Конфигуратор в пакетном режиме с командой "/SetPredefinedDataUpdate -Auto"
- Периферийный узел готов к работе. Предопределенные данные будут приходить из центрального узла. Дублей не будет.
