30.10.2014 Розширення

Реалізовано в версії 8.3.6.1977.

Ми реалізували принципово новий механізм адаптації прикладних рішень під конкретного споживача - механізм розширень.

Чим хороші розширення?

Розширення пропонують іншу, відмінну від існуючої, стратегію зміни типових конфігурацій. Використання цієї нової стратегії істотно полегшить супровід типових рішень, які хочеться адаптувати до потреб конкретного впровадження, конкретного замовника.

Як виглядає цей процес зараз? Є типова конфігурація. Вона знаходиться на повній підтримці постачальника. Це означає, що змінювати її не можна. Періодично постачальник випускає нові (поліпшені) версії цієї конфігурації. У такій ситуації оновлення старої версії конфігурації на нову версію виконується повністю автоматично. Це зручно і не вимагає від замовника якихось особливих навичок або знань.

Але часто замовник хоче щось додати чи щось змінити у типовій конфігурації «під себе». Для цього режим підтримки змінюється, конфігурація знімається з повної підтримки. Партнер, який виконує впровадження, або власні IT фахівці замовника, вносять в неї необхідні зміни. З цього моменту повністю автоматичне оновлення типової конфігурації на нову версію, випущену поставки товару, стане неможливим.

Тепер для оновлення конфігурації потрібна участь фахівця. Причому, якщо зміни, внесені з волі замовника, були значними, то і від фахівця, що виконує оновлення конфігурації, можуть знадобитися значні витрати часу. І часто може знадобитися дуже добре знання як самої типової конфігурації, так і внесених доробок.

Стратегія, запропонована розширеннями, полягає в наступному. Якщо ви хочете змінити типову конфігурацію, ви не чіпаєте саму конфігурацію. Всі зміни ви виконуєте в розширенні, яке, по суті, теж є конфігурацією.

У режимі 1С: Підприємство ви просто підключаєте своє розширення до типової конфігурації. Платформа автоматично, в режимі 1С: Підприємство, об'єднує ваше розширення з типовою конфігурацією. В результаті замовник працює зі зміненим, за його бажанням, типовим рішенням.

Коли постачальник випускає нову версію типової конфігурації, автоматично оновлюється, оскільки режим підтримки типової конфігурації не змінювався. Вона залишилася на повній підтримці постачальника. А при запуску оновленого прикладного рішення платформа знову автоматично об'єднає змінену типову конфігурацію з вашим розширенням. І замовник продовжить працювати зі зміненим, за його бажанням, типовим рішенням.

Коли потрібно використовувати розширення?

Механізм розширень привабливий своєю універсальністю. Тому важливо мати правильне уявлення про те, для вирішення яких завдань він призначений.

По-перше, розширення незамінні тоді, коли прикладне рішення працює в режимі поділу даних. Наприклад, в моделі сервісу. Один з абонентів хоче мати пару додаткових звітів. У той час як інші абоненти хочуть працювати з нормальною типовою конфігурацією.

Тоді саме для цього абонента ви можете розробити розширення, в якому і реалізувати всі його побажання. Абонент підключить собі це розширення і буде працювати зі зміненою конфігурацією. У той час як для інших абонентів ніяких змін не відбудеться. Тому що все розширення підключаються і запускаються в розрізі поточних значень роздільників.

Інша ситуація - це доопрацювання типової конфігурації під конкретного замовника у нього на впровадженні. Або ж доопрацювання типової конфігурації, які виконують для себе IT фахівці замовника власними силами. Якщо всі ці доробки виконати в розширенні, то типова конфігурація залишиться на повну підтримку, що значно спростить її подальший супровід.

Є спокуса використовувати розширення для створення тиражних прикладних рішень, однак робити цього не варто. По-перше, тому, що розширення не проектувалися під такі завдання. А по-друге, тому, що інші механізми платформи, наприклад механізми поставки і підтримки, нічого не знають про розширення.

Якщо трохи зазирнути в історію появи розширень, то, безумовно, ми бачили раніше, бачимо і зараз, що конфігурації стають складніше. Ми бачимо, що потрібна додаткова підтримка на різних рівнях розробки: бібліотечна, модульна і галузева і т.д. Ми аналізували всі ці завдання і прийшли до висновку, що найбільш пріоритетною на даний момент є адаптація конфігурацій до побажань користувачів під час впроваджень.

Саме для цього завдання ми і створили механізм розширень. Звичайно, в ньому можна помітити різні риси і інших перерахованих напрямків розробки. Але вони не є його основним призначенням і не повинні збивати вас з пантелику.

Що можна змінювати вже зараз за допомогою розширень?

Поки зроблено не дуже багато з того, що планується зробити. Механізм, звичайно, буде розвиватися. Але те, що вже зроблено, може бути корисно в багатьох випадках на впроваджень. зараз:

• Можна змінювати керовані форми, існуючі в типовій конфігурації;
• Можна додавати нові підсистеми. Можна змінювати склад підсистем, наявних у типовій конфігурації;
• Можна змінювати ролі типової конфігурації, додаючи в них об'єкти, створені в розширенні;
• Можна змінювати командний інтерфейс типової конфігурації (основного розділу, підсистем);
• Можна додавати нові звіти і обробки.

Надалі ми плануємо поступово нарощувати функціональність розширень і будемо раді отримати вашу думку про те, яка функціональність найбільш затребувана на впроваджень з невеликими доробками.

Як влаштовано розширення?

Розширення дуже схоже на звичайну конфігурацію. Воно також представляється у вигляді дерева об'єктів. Для роботи з розширенням використовуються ті ж прийоми роботи, що і зі звичайною конфігурацією.

Важливою особливістю розширення є наявність запозичених об'єктів. Запозичити можна будь-який об'єкт типової конфігурації за допомогою команди контекстного меню:

Запозичені об'єкти потрібні не завжди. Найкраще це пояснити на «побутовому» прикладі, якщо провести аналогію з обідом в ресторані.

Ситуація перша, коли запозичені об'єкти потрібні.

Ви звикли обідати в одному і тому ж ресторані. Ви завжди замовляєте біфштекс і чай. Наприклад, тому що вони дуже гарні в цьому ресторані. Або з іншої причини. Це не важливо. Важливо лише те, що їсти ви збираєтеся саме їх, і ніщо інше.

Тоді ресторан - це типова інформаційна база. Ви - розширення. Меню ресторану - це розширювана типова конфігурація. Біфштекс і чай - це запозичені об'єкти. Ви їх запозичили (запам'ятали, що вони є в меню).

Як розширення підключається до конфігурації і працює? Ви приходите в ресторан і просите меню. У меню ви бачите, що є біфштекс і чай. Тобто встановлюєте відповідність між запозиченими об'єктами і об'єктами типової конфігурації. Природно, відповідність ви встановлюєте за іменами :). Вам приносять біфштекс і чай, ви їх з'їдаєте. Тобто розширення підключається і працює.

Через тиждень ви приходите, але меню ресторану змінилося (типову конфігурацію оновили). Однак в меню як і раніше є біфштекс і чай. Саме вони вам і потрібні. Вам їх приносять, ви їх з'їдаєте. Тобто розширення продовжує працювати з оновленою типовою конфігурацією.

Ще через тиждень ви приходите в ресторан, і бачите, що біфштекс і чай зникли з меню. Ви встаєте і йдете (повідомлення про помилку підключення розширення). Тому що ви хотіли саме їх. А про інших стравах (об'єктах) ви поняття не маєте. Розробник не навчив вас, як правильно їсти равликів чи омарів.

Інша ситуація, коли можна обійтися без запозичених об'єктів.

Ви йдете в ресторан, але наявність конкретних страв вас не цікавить. Тому що ви все одно не збираєтеся їх є. Ви хочете їх тільки сфотографувати. А фотографувати ви вмієте яке завгодно блюдо. Тоді ви просто підключаєтеся до конфігурації і говорите: несіть все закуски, які є у вас в меню (отримуєте колекцію документів з метаданих). Я їх перепроводити буду (фотографувати).

Якщо описати це сухою мовою розробників то вийде, що запозичувати об'єкти потрібно:

• Коли вони необхідні для візуального конструювання. Наприклад, ви розширюєте форму і додаєте реквізит форми типу СправочнікВалюти.Ссилка. Тоді звичайно ви повинні запозичувати довідник Валюти, щоб при підключенні до типової конфігурації бути впевненими в тому, що в ній такий довідник все ще є.
• Коли вони необхідні для роботи коду. Наприклад, в коді розширення ви звертаєтеся до реквізиту довідника Номенклатура - Імпортер. Тоді цей реквізит також треба запозичувати, щоб при підключенні бути впевненим, що у типовій конфігурації все ще існує такий реквізит у довідника Номенклатура.

підключення розширення

Ви створюєте розширення в конфігураторі. Після того, як воно налагоджено і перевірено, ви можете його відкинути, зберігши розширення в файл * .cfe.

Цей файл ви можете передати замовнику. Замовник самостійно завантажить його в свою інформаційну базу в режимі 1С: Підприємство за допомогою стандартної функції Управління розширеннями конфігурації.

Робота з розширеннями доступна з вбудованої мови, тому в прикладному рішенні ви можете створити власну обробку, яка буде завантажувати розширення. Щоб розширеннями «не балуватися» все підряд, ми додали нове право - Адміністрування розширень конфігурації.

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

Щоб розширення «заробило», сеанс потрібно перезапустити. При старті сеансу, безпосередньо перед викликом події УстановкаПараметровСеанса, будуть підключені всі розширення, що зберігаються в інформаційній базі і відповідні поточним значенням роздільників даного сеансу.

В результаті, при роботі в режимі поділу даних розширення буде застосовано тільки для користувачів цього конкретного абонента. А якщо поділ даних не використовується, то розширення буде працювати для всіх користувачів інформаційної бази.

При підключенні розширення, як ми вже говорили, контролюється, що в типовій конфігурації існують запозичені об'єкти. Зіставлення об'єктів відбувається за іменами.

Крім цього можливий і більш тонкий контроль. Ви можете контролювати не тільки сам факт наявності об'єктів, а й стан їх окремих властивостей. Тобто, якщо згадати про ресторан і біфштекс, для вас може бути важливо не просто наявність якось приготовленого біфштекса, а саме те, що тут його готують непрожареної, «з кров'ю».

Повертаючись до розширення, стандартно він не контролює властивості запозичених об'єктів. Але якщо в цьому є необхідність, ви можете деякі властивості зробити контрольованими. Наприклад, для вашого алгоритму важливо, щоб не тільки існував довідник Номенклатура, але і те, що його код має тип Рядок.

Тоді якщо в типовій конфігурації постачальник змінить тип коду цього довідника на Число, ваше розширення визначить це в момент підключення і повідомить про помилку.

Цікавий момент пов'язаний з перейменуванням об'єктів типової конфігурації. Наприклад, ви прийшли в ресторан, а в меню замість Біфштекс написано Стейк. Тобто підключаючись до конфігурації розширення не знаходить в ній довідник Номенклатура, тому, що постачальник перейменував його в Товари.

Тепер для вас така ситуація не є проблемою. І вам не потрібно «перелопачувати» весь код розширення, щоб замість Номенклатура написати Товари. працює механізм зміни коду модулів при перейменуванні об'єктів конфігурації і механізм рефакторінга . Тому вам достатньо всього лише змінити ім'я запозиченого об'єкта на Товари, а решта зміни в розширенні платформа зробить сама. Або з вашої мінімальною допомогою.

Робота розширення

Можна досить довго розповідати про особливості розширення різних об'єктів, про особливості роботи самих розширень. Але ми обмежені рамками оглядової статті, тому торкнемося тільки ключові і найбільш показові моменти.

Основна «принадність» розширень полягає, звичайно, не в тому, що можна додати до типової конфігурації щось, чого в ній немає. А в тому, що в розширенні можна змінити те, що в типовій конфігурації вже є. Тобто властивості запозичених об'єктів ви можете змінювати.

Основну концепцію, яка використовується під час спільної роботи конфігурації і розширення, можна описати наступним чином. У тих місцях, де вони «не перетинаються», розширення доповнює конфігурацію. У тих місцях, де вони «перетинаються» - буде застосований ефект розширення.

Детальніше це можна побачити на прикладі керованих форм. Ви можете запозичувати форму з основною конфігурації і редагувати її в розширенні без обмежень. Для візуальної частини форми і для її модуля використовуються дві різні стратегії об'єднання.

Візуальна частина форми фіксується в розширенні на момент її запозичення. А в режимі 1С: Підприємство для кожного елемента форми аналізуються зміни щодо цього стану в типовій конфігурації, і в розширенні.

Якщо змін не було, або вони були тільки в типовій конфігурації - застосовується значення з типової конфігурації. В інших випадках застосовується значення з розширення.

Таким чином, якщо в розширенні ви додали в форму нову команду - ви її побачите разом з іншими командами форми. А якщо змінили заголовок існуючої групи, то ви будете бачити свій заголовок навіть в тому випадку, якщо заголовок цієї групи у типовій конфігурації поміняє постачальник.

Для модулів форм використовується інший підхід. Для запозиченої форми в розширенні створюється власний модуль з власними обработчиками всіх подій. У режимі 1С: Підприємство обидва модуля форми (з типової конфігурації і з розширення) об'єднуються в одному контексті. З цієї причини кожне розширення має свій префікс, який додається до обробникам всіх подій в модулі форми. Щоб не було збігів з обработчиками з типової конфігурації. Після цього обробники подій і команд викликаються послідовно і синхронно. Спочатку обробник з розширення. Потім з типової конфігурації. Цю послідовність ви можете поміняти, або зовсім заборонити виконання обробника з типової конфігурації.

Взагалі, що стосується спільної роботи конфігурації і розширення в режимі 1С: Підприємство, вони існують в загальному просторі назв. Це стосується не тільки окремих модулів, але і самих дерев метаданих. Тому немає ніякої можливості в режимі 1С: Підприємство визначити, чи є цей об'єкт «рідним» для типової конфігурації, або він з'явився з розширення.

Що стосується інших об'єктів, які ви можете використовувати в розширенні, то для них все виглядає набагато простіше.

У розширенні ви можете створювати свої власні підсистеми. Використовуючи запозичені об'єкти, ви можете розширювати існуючі підсистеми: додавати в них об'єкти і підсистеми, які вже є в типовій конфігурації, або ті, які ви створили в розширенні. Видалити щось з існуючої підсистеми ви не можете.

Розширювати ролі ви можете тільки додаючи в них об'єкти, створені в розширенні. Видалити що-небудь з існуючої ролі ви теж не можете. Це саме можна сказати і до командного інтерфейсу.

Розширення - це майже конфігурація

Ми говорили на початку, що розширення схоже на звичайну конфігурацію. Тому в ув'язненні кілька слів хочеться сказати про те, наскільки розширення інтегровані з іншими механізмами платформи.

У розширення (як і у звичайній конфігурації) є основна конфігурація і конфігурація бази даних. Механізм порівняння і об'єднання конфігурацій працює з розширеннями так само, як і зі звичайними конфігураціями.

Ви можете вивантажити розширення в файл (правда, з іншим розширенням * .cfe), і завантажити з файлу. Розширення можна вивантажувати / завантажувати в XML.

Механізми глобального пошуку, заміни, редагування текстів інтерфейсів також працюють і з розширеннями.

З'явилися нові параметри командного рядка для роботи з розширеннями, а також нові події в журналі реєстрації.

У вбудованій мові основний об'єкт для роботи з розширеннями це МенеджерРасшіренійКонфігураціі.