Кастомізації в 1С

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

image

Зміна вихідного коду
Є різні стратегії кастомізації. Якщо програма постачається у вихідних кодах, то самий очевидний підхід – переписати вихідний код під свої потреби. І найбільш очевидна в цьому випадку проблема – перехід на нову версію програми, т. к. він тягне злиття (merge) вихідних кодів зміненої на стороні клієнта версії і новій версії від постачальника. А це може бути нетривіальним завданням, особливо якщо код на стороні клієнта сильно кастомізований.

Плагіни
Більш безпечна в цьому плані стратегія – плагіни. Вихідне додаток надає плагіну фіксований набір інтерфейсів, а також можливість зареєструвати себе у додатку. При виході нової версії додатка плагіни, написані для попередньої версії, продовжать працювати і в новій версії (за умови незмінності інтерфейсів). Поведінка плагінів в новій версії може відрізнятися від поведінки в попередній, якщо постачальник ЗА змінив поведінку програми. Концепція плагінів використовується в найрізноманітніших класах ПО – офісному і бізнес-софт, середовищах розробки (Visual Studio, Eclipse, ...), графічних і звукових редакторах і т. п.

Підписки
Ще одна технологія кастомізації – можливість оформлення передплати (subscription) на події в додатку і виконання користувальницького коду на загальновідомому або проприетарном мовою під час цих подій. Події можуть бути самого різного виду – відкриття вікна, завантаження зображення (для графічного редактора), обробка замовлення (для бізнес-системи).

Одна з різновидів такого підходу – вбудовування в основну програму можливості виконувати користувальницькі скрипти на мовах типу Visual Basic for Application (VBA). Кастомный код може, зокрема, виконуватися у відповідь на події програми. Той же VBA показав себе дуже потужним і гнучким засобом кастомізації; він вбудований в Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS та інші продукти.

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

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

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

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

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

image

Налаштування поставки на стороні постачальника

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

image

Налаштування підтримки на стороні клієнта

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

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

  1. Стара конфігурація від постачальника.
  2. Поточна конфігурація клієнта (стара конфігурація від постачальника плюс зміни, зроблені в ній клієнтом).
  3. Нова конфігурація від постачальника.
Зрозуміло, що в ряді випадків об'єкти, змінені постачальником, можна оновлювати автоматично:

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

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

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

Кастомізації в хмарах
З появою хмарної технології 1cFresh завдання кастомізації вийшла на новий рівень. Справа в тому, що в «хмарі» користувачі прикладного рішення з різних організацій можуть фізично працювати з однією інформаційною базою (тобто з одним примірником програми), але, в той же час, завдяки механізму розділення даних, бачать тільки дані своєї організації. Кастомізація через зміну вихідного коду тут стають неприйнятною – якій організації потрібні свої кастомізації, і зовсім не потрібні кастомізації «сусідів» по инфобазе.

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

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

  1. Дозволяв би легко оновлювати кастомізованих рішення на нову версію, уникаючи ручної роботи з об'єднання конфігурацій.
  2. Дозволяв включати кастомізацію при певних умовах (наприклад, якщо ми працюємо в контексті певної організації).
  3. Знижував імовірність втрати працездатності кастомізації при переході на нову версію вихідної конфігурації.
  4. Мав можливість відключення кастомізації в разі проблем для збереження працездатності програми.
Такий механізм, крім застосування в хмарних рішеннях, полегшив би життя при переході на нову версію на впровадження типових конфігурацій, де необхідні кастомізації.
Ми придумали такий механізм і назвали його розширення. Цей механізм в якомусь сенсі поєднує в собі два підходи до кастомізації – ідеологію плагінів і механізм підписок.

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

image

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

image

Основна конфігурація і розширення з запозиченим документом СчетФактураВыданный

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

image

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

&Після("ПередЗаписью")
Процедура РасшАндромеда_ПередЗаписью(Відмова, РежимЗаписи, РежимПроведения)
Якщо (ЭтотОбъект.Відповідальний = Довідники.Користувачі.ПустаяСсылка()) Тоді 
ЭтотОбъект.Відповідальний = МодульПользователи.ПолучитьТекущегоПользователя();

КонецЕсли;
КонецПроцедуры

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

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

image

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

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

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

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

На форму можна додати нову кнопку (або навіть декілька). У разі якщо кілька розширень додають на одну і ту ж форму свої кнопки – всі вони будуть присутні на підсумковій формі під час виконання.

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

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

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

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

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

image

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

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

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

image

Раннє оповіщення про помилки
Припустимо, ми запозичили в розширення довідник Контракти з основної конфігурації для використання його в звіті. Тим часом вийшла нова версія типової конфігурації, в якій довідник Контракти був перейменований в Договори. Природно, після переходу на нову версію наш звіт в розширенні працювати не буде. Якщо б ми використовували стару технологію кастомізації — зовнішній звіт, то помилка виникла б лише в момент виконання звіту. У разі ж розширень у нас є можливість перевірити коректність розширень в design-time після оновлення версії типової конфігурації, і виправити всі проблеми до того, як користувачі почнуть роботу.

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

Що далі?
Ми вважаємо розвиток розширень одним з головних напрямків розвитку засобів кастомізації в платформі «1С: Підприємство». Розширення, створені спочатку для полегшення кастомізації в хмарному сервісі, були спроектовані так, щоб полегшити і ситуації з кастомизациями і на не-хмарних впроваджень.

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.