gifts2017

Работа с предопределенными элементами в 8.3

Опубликовал Алексей Бочков (Aleksey.Bochkov) в раздел Программирование - Практика программирования

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

Для управления созданием предопределенных элементов существуют следующие механизмы:
1) В Конфигураторе для объекта метаданных можно определить способ обновления предопределенных данных - Авто, Обновлять автоматически, Не обновлять автоматически.
2) Для информационной в целом можно установить режим создания предопределенных через метод:
УстановитьОбновлениеПредопределенныхДанныхИнформационнойБазы(ОбновлениеПредопределенныхДанных), где
ОбновлениеПредопределенныхДанных - системное перечисление с вариантами Авто, Обновлять автоматически, Не обновлять автоматически
3) Для конкретной таблицы информационной базы можно установить режим создания предопределенных через менеджера через метод:
УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных), например
Справочники.Номенклатура.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
4) На создание предопределенных элементов также влияет тип информационной базы - главный узел РИБ (не подчинен ни одному плану обмена, являющемуся РИБ) или периферийный узел РИБ.

Цитата из справки:
Фактический режим обновления определяется в следующем порядке:
  • Если для объекта метаданных в данных установлен режим обновления, отличный от Авто, то используется это значение. (пункт 3 из списка выше)
  • Иначе, если для объекта метаданных в конфигурации установлен режим обновления, отличный от Авто, то используется это значение. (пункт 1 из списка выше)
  • Иначе, если для информационной базы установлен режим обновления, отличный от Авто, то используется это значение. (пункт 2 из списка выше)
  • Иначе, если это периферийный узел РИБ, то предопределенные данные не будут обновлены. Если проверка выполняется для центрального узла РИБ, или для базы, не являющейся РИБ, обновление предопределенных данных будет выполнено.

Посмотрим несколько стандартных случаев:
1) Имеем некую информационную базу без использования РИБ.
В этом случае, все должно быть хорошо - если для метаданных конфигурации выставлен способ обновления предопределенных = "Авто" и программно режим не был переопределен для информационной базы в целом или отдельной таблицы, то предопределенные элементы будут созданы\обновлены при реструктуризации информационной базы (это может быть при создании ИБ из cf, установке нового релиза конфигурации или проведения реструктуризации через тестирование и исправление).

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

Что можно сделать:
- выставлять способ обновления для объекта метаданных в конфигурации = "Обновлять автоматически" не совсем правильно, если в конфигурации есть несколько разных планов обмена РИБ с разным составом, а этот объект входит только в часть из них. Если это сделать, то в данной конкретной ситуации ошибка будет исправлена - в периферийном узле предопределенные элементы будут созданы. Но при создании РИБ по другим планам обмена (куда данный объект входит) элементы задублируются - в периферийный узел придут предопределенные из главного узла.


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

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

Если ТипЗнч(ПланыОбмена.ГлавныйУзел()) = Тип("ПланОбменаСсылка.Разработка") Тогда //если это не РИБ, или узел иного плана обмена, то код выполнятся не должен.
    Если РольДоступна("ПолныеПрава") Тогда //методы ниже требуют прав на удаление объектов, поэтому правильнее выполнять их под полными правами
        Справочники.ГруппыПользователей.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);  
        Справочники.ГруппыВнешнихПользователей.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);   
    КонецЕсли;
КонецЕсли;

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

Предопределенные элементы можно создать руками, но будьте осторожны, если используете клиент-серверный режим и платформу 8.3.4 - после добавления элементов вручную велика вероятность того, что войти в базу больше не получится - при запуске получите "На сервере 1С произошла неисправимая ошибка", и только в логах технологического журнала можно будет увидеть, что система пыталась вставить дублирующееся по GUID значение в таблицу.


3) Создание нового периферийного узла без выгрузки начального образа.
Не уверен насколько этот метод распространен, но я уже в 7.7 использовал окольный путь для создания нового узла, лишь бы не блокировать монопольно главный узел на длительное время. В 8-ке все стало намного проще и полностью реализуется типовыми средствами.
Обычно для создания нового узла выгружается начальный образ при этом он будет наполнен корректно всей информацией, в том числе, мигрирующими предопределенными значениями. Но это требует монопольной блокировки базы, что при больших объемах просто неприемлемо.
Другой вариант - на базе конфигурации главного узла создать пустую базу, затем создать в обеих базах узлы, привязать периферийный узел к главному, зарегистрировать объекты к обмену и дождаться окончания обмена. И все это в спокойном режиме без монопольной блокировки базы. Но с новым подходом к созданию предопределенных в этом случае получим проблему - при создании новой базы они еще не будет привязана к главному узлу, соответственно, система создаст все предопределенные элементы, а потом их дубли придут из главного узла.
Для устранения этой проблемы разработчики платформы рекомендуют следующее:
  • После загрузки и обновления конфигурации периферийного узла запустить Конфигуратор в пакетном режиме с командой "/SetPredefinedDataUpdate -DoNotUpdateAutomatically"
  • выполнить действия по настройке узлов
  • запустить Конфигуратор в пакетном режиме с командой "/SetPredefinedDataUpdate -Auto"
  • Периферийный узел готов к работе. Предопределенные данные будут приходить из центрального узла. Дублей не будет.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. bulpi bulpi (bulpi) 13.08.14 13:28
Вопрос разработчикам : ну и на хрена все это было делать ?
ccserg; Spacer; wolfsoft; sh_max; red80; +5 Ответить 3
2. Александр Полтава (Патриот) 13.08.14 14:43
(1) bulpi, они заботятся, чтобы у рядовых программеров было больше работы и мы не вымерли с голоду =)
3. Алексей Бочков (Aleksey.Bochkov) 14.08.14 19:17
Сделал простую обработку, которая поможет сгенерировать код для принудительного обновления предопределенных в узлах РИБ, когда объекты не входят в РИБ. Может кому будет полезно.

У меня получилось 197 (!!) таких случаев.
Прикрепленные файлы:
КодДляОбновленияПредопределенных.epf
4. Алексей Бочков (Aleksey.Bochkov) 14.08.14 19:24
(1), (2) - ИМХО, идеологи платформы сильно оторваны от реальности. У них нет практического опыта разработки, внедрения и эксплуатации более менее серьезных конфигураций. А выстраивать диалог с теми, у кого этот опыт есть, категорически не хотят, хотя и декларируют постоянно обратное. В итоге и получаются решения, которые в теории хорошие, а на практике сплошное разочарование.
mea27; RomanRomans; JohnyDeath; IvanAlekseev; Dvornik; wolfsoft; sh_max; davdykin; +8 Ответить 1
5. Allexey (alex_4x) 14.08.14 09:35
И зачем 1С все эти заморочки придумала с предопределенными элементами? Я считаю что это вообще ненужный механизм. Также как и константы. А за статью большое спасибо!
6. Иван Устьянцев (nSpirit2) 14.08.14 09:46
(4) Aleksey.Bochkov, Идеология платформы в наконец то двигается в правильном направление. У 1с нет опыта разработки сложных конфигураций? о_0 По моему изменения вполне логичны.
7. Алексей Бочков (Aleksey.Bochkov) 14.08.14 21:11
(6) nSpirit2,
Идеология платформы в наконец то двигается в правильном направление.

Я не утверждал, что направление неправильное. Речь про ряд неудачных решений в последних релизах 8.3.

У 1с нет опыта разработки сложных конфигураций?

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

По моему изменения вполне логичны.

Исходя из какой логики? Как много реальных баз будет использовать разделители на практике (наличие разделителя в типовой не является показателем его использования)? Скорее всего, мизерный процент. А "насладятся" нововведением все.
8. Иван Устьянцев (nSpirit2) 14.08.14 11:00
(7) Aleksey.Bochkov, Простите а зачем разработчикам платформы опыт разработки и внедрения решений. Думайте у Страуструпа был большой опыт написания и внедрения сложных приложений на С++. Вы подменяете понятия.. Задачей разработчиков платформы является методология использования языка конфигурации. А не вопросы как вам плохо что ваше решение не работает на новой платформе из за того что вы как то своенравно пользуйтесь самим языком. А что страшного в разделителях я что то совсем не вижу проблем?
vlad.frost; +1 2 Ответить 2
9. Allexey (alex_4x) 14.08.14 11:18
(8) nSpirit2,
Речь о том, что захламление специфическими методами не идет на пользу. Методы должны быть просты, универсальны и одни и те же применяться для различных целей.
Метод "табличная часть", регистр сведений, регистр накопления - оправданы.
а создание специальных методов для каждого чиха только плодит глюки и нестыковки.

что такое предопределенные значения - это значения коллекции, которые на момент разработки, закладываются в решение, как присутствующие. Что мешает хранить такие значения в регистре сведений, как связь константы и элемента справочника? Это было бы проще, понятней и предсказуемей. Обработка незаполненных значений и вопросы репликации - решались бы в рамках общей парадигмы.
10. Алексей Бочков (Aleksey.Bochkov) 14.08.14 22:22
(8) nSpirit2,
Ваше утверждение не соответствует действительности. Ознакомьтесь с позицией Сергея Нуралиева на партнерском форуме.
Как раз-таки разработчики платформы ставят перед собой цель создать максимально готовый инструмент для написания бизнес-приложений, а не предоставлять низкоуровневые механизмы для кастомизации решения. Проводить параллель между C++ и 1С ошибочно.

Думайте у Страуструпа был большой опыт написания и внедрения сложных приложений на С++.

Это конечно, порадовало :). Нет, блин, он его в пьяном бреду придумал.
lustin; nSpirit2; +2 Ответить 2
11. Иван Устьянцев (nSpirit2) 14.08.14 11:27
(9) alex_4x, к сожалению это судьба любого языка программирования с невозможностью стороннего расширения.

Не правильно вы к этому относитесь как внедренец собственно. Предопределенный элемент это именованная ссылка. Это необходимо для тех кто сам пишет конфигурации потому что наверняка вам не приходилось добавлять предопределенные элементы в типовые справочники. Если честно то сам считаю механизм предопределенных очень глупым и стараюсь не использовать его в коде. Но 1С вполне логично дает возможность изменения всего из режима предприятия для для еще более гибкой настройки.
12. Иван Устьянцев (nSpirit2) 14.08.14 11:46
(10) Aleksey.Bochkov, Мы не сравниваем специфику самого языка а принцип развития. Вы опять подменяете понятия. Любые разработчики языка ставят задачу сделать наиболее удобный инструмент для разработки того на что он нацелен по мнению разработчиков это слишком общая фраза чтобы делать те выводы которые вы делаете. Я рад что мой пример со Страуструпом вас порадовал разработчик языка так и остался разработчиком и методистом а не внедренцем программ на своем языке.
13. Allexey (alex_4x) 14.08.14 11:46
"Для еще более гибкой настройки" это выливается в косяки ради не пойми какой выгоды.
Если решение настраиваемо в рамках рантайма - никто не мешает сделать форму для заполнения того же самого регистра сведений, причем там можно запрограммировать нужные проверки и всё что душе угодно. То есть на качество возможностей кастомизации применение "предопределенных значений" положительно не влияет. А вот "видимость возможности настройки с кучей подводных камней, делающей эту возможность глючной и геморройной" - да, появляется. Фактически разработанный механизм - искусственный источник проблем и ошибок, которых можно было бы избежать, просто правильно применяя универсальные механизмы, уже заложенные в платформу.
14. Иван Устьянцев (nSpirit2) 14.08.14 11:57
(13) alex_4x, Сам механизм именования ссылок конечно кажется выраженным на первый взгляд но полезность его весьма интересна. Представим обстрактную ситуацию у вас есть Предопределенный элемент который используеться в движениях. Настал момент и вам нужно вместо него использовать другой и что делать лезть в конфигуратор и там менять код? А если механизм из типовой конфигурации вон в зарплате таких хватает что с поддержки снимать из за этого? Собственно замена в предприятии одного элемента на другой и решит проблему.

Ваша идея с регистром очень хороша но идея предопределенного в том что ссылка точно есть. А вот в регистре записи может и не оказаться.
15. Allexey (alex_4x) 14.08.14 12:35
(14) nSpirit2,
О том и спор, что кажется, будто бы "предопределенное значение" снимает ответственность с программиста на этапе разработки решения проверки корректности заполнения этого значения. В Вашем случае, во время проведения проверки на правильность и наличие "предопределенного значения" делать вроде как и не надо. Это уже потенциальный источник проблемы. Если это предопределенное значение берется допустим из процедуры глобального модуля СслылкаСправочникаВидыНалоговНДС18 = глПолучитьПредопределенноеЗначение("НДС18",СсылкаДляКого,ТекущаяДата()); то потом в модуле проведения (на этапе проектирования) должно быть предусмотрено, что возможно такое значение и не заполнено. Что уж там дальше делать - опять же должно быть на этапе проектирования предусмотрено. В результате получим, что в режиме использования можно производить Предусмотренные настройки, а при не правильной настройке система будет на это адекватно реагировать. Минусов в таком решении не вижу, только одни плюсы.
А если при не заполненном значении нельзя продолжать работать вообще - замечательно - проводи проверки всех критичных значений при запуске приложения и если что-то не заполнено, оповещай пользователя и не давай работать, пока не будет что надо заполнено. Опять же - всё решается на уровне проектирования системы и лежит не в плоскости "система сама за нас всё сделает, а правильно или нет - мы не ведаем", а определяется разработчиком прикладного решения.
16. Иван Устьянцев (nSpirit2) 14.08.14 13:19
(15) alex_4x, Вы не подумайте я с вами согласен. Я про само развитие так сказать. Использование предопределенных сродни найти по коду. Ну собственно вот и идею и довели до полного соответствие теперь вроде как возвращается то что выберет пользователь.

А теперь представите что в вашем регистре храниться что-то важное для проведения что нужно всем документам. Вот и узкое место в вашей системе при большой нагрузке все проводимые документы будут читать одну и туже таблицу. В "теории" предопределенные значения должны работать быстрей. Ну и главная проблема а как обеспечит целостность таких настроек как быть если пока документ проводился настройку удалили? Блокировать их? Предопределнные хороши тем что всегда дадут вам ссылку пусть даже на не существующие данные это потом проще исправить чем перепроводить документы с потерявшейся настройкой.
17. Max Avramenko Avramenko (A_Max) 15.08.14 12:35
А потом ещё вернут галочку у реквизитов "переодический"...
18. Андрей Овсянкин (Evil Beaver) 18.08.14 10:20
(10) Aleksey.Bochkov,
Нет, блин, он его в пьяном бреду придумал.

Иногда мне кажется, что это, все-таки, правда)
nSpirit2; +1 Ответить
19. Татьяна (svetanik) 20.08.14 11:52
Большая благодарность за статью! Испытала большую радость и похвалила себя, что периодически просматриваю сайт. Теперь знаю об этих подводных камнях. Само знание, что они есть, уже многого стоят!
20. Алексей Бочков (Aleksey.Bochkov) 21.08.14 14:11
UPD - оказывается, ошибка с падением платформы в 8.3.5 не исправлена.
У нас проявляется если отвязать периферийный узел от РИБ и зайти под полными правами.
Azatikn; hakerxp; Bukaska; +3 Ответить 1
21. Дмитрий Топчий (hakerxp) 28.08.14 09:40
(20) Aleksey.Bochkov, такая же беда. Ждемссс обновления.
22. Антон Рощин (wolfsoft) 03.09.14 14:29
(1) bulpi, на хрена, на хрена... когда коту нечего делать... ну, вы знаете.
23. Евгения Карук (ekaruk) 14.10.14 15:26
Почитала, подумала, и добавила в свою обработку по предопределенным данным возможность поиска задвоенных значений по всей конфигурации.
http://infostart.ru/public/305892/
Даже у себя нашла дубли.

А вообще по-моему все-таки правильное решение дать пользователям возможность самостоятельно устанавливать предопределенные элементы.
Не нужно изобретать лишние сущности.

24. Осипов Сергей (fixin) 26.09.15 17:20
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа