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