DIRECTUM, DIRECTUM Общност

В тази статия ще опиша подходите, които обикновено се използват от разработчиците на DIRECTUM при актуализиране на системата до нова версия.

Структура на системата DIRECTUM от гледна точка на разработчика

Първо, малко теория за структурата на системата. Цялата разработка на системата е разделена на "платформа" и "разработка на приложения". Тези, които вече са свикнали с подобно разделение, обикновено нямат въпроси за това какво се отнася до какво и как се различават помежду си. Но за начинаещ разработчик или администратор това не е толкова очевидно. Това е най-добре обяснено на диаграмата.

При внедряването на системата можем да адаптираме разработването и конфигурирането на приложенията към нуждите на клиента, както чрез промяна на съществуващата в системата („стандартна разработка“), така и чрез създаване на нова. Като цяло цялата интерпретирана част е достъпна за модификации. Както можете да видите от диаграмата, някои от интерпретираните разработки са специфични за платформата ("разработване на системи"). Платформата включва разработката, която е написана на ISBL и е достъпна за модификации, но е критична за работата на цялата система. Например директорията "Потребители". По принцип е възможно да се правят промени в разработката на системата, но най-малко и при задълбочено тестване.

И така, докато системата трябва да бъде актуализирана, имаме:

компилираната част на платформата (не може да бъде променена);
стандартна непроменена приложна разработка (при адаптиране на системата тя не е била пипана);
стандартно модифицирано разработване на приложения (това, което първоначално беше в оригиналната доставка, но беше променено по време на внедряването);
нова приложна разработка (нови елементи, създадени за клиента, това включва и технически решения).

Какво е включено в конвертора и как той актуализира системата

Стандартният преобразувател на системата DIRECTUM е предназначен за актуализиране на системата до нова версия, като се използват:

Актуализации на сървърната страна на платформата (SQL скриптове за създаване и модифициране на таблици, тригери, съхранени процедури и др.);
Внос на разработка на стандартни приложения;
Преобразуване на данни за ново приложно развитие.

Съответно конверторът включва SQL скриптове, изпълнявани в последователността, посочена в пакета за преобразуване, както и всички приложени разработки. Важно е да се отбележи, че пакетът включва цялото разработване на приложения, а не само това, което се е променило от версия на версия. Основната причина за това е гъвкавостта на конвертора, един и същ пакет за преобразуване може да се приложи за надграждане на системата от различни стари версии до текущата (например от 4.2 и по-висока до 4.9). В този случай разработката не се приема кумулативно (т.е. не 4.3, след това 4.4 и т.н. до 4.9), а само последната. Следователно разработването на последната версия в конвертора съдържа всичко, от което тази версия се нуждае, за да работи.

Вътрешната структура на пакета за преобразуване е отделна тема и тук ще го пропуснем. Просто ще кажа, че convertpackage.dat е обикновен zip архив, можете да го изучавате и дори да го променяте.

Какво конвертор може и не може

За да опишете характеристиките на функционалността на конвертора, е важно първо да изясните един термин. Преди да преобразувате системата, помощната програма за преобразуване предлага да изберете стойността на следната настройка:

„Конфликт при внос на разработка на система“ се отнася до ситуация, когато съществуващата приложна разработка на система се различава от внесената. Тези. Конфликтът не е причинен само от добавянето на новата стандартна разработка, но дори промяната на един (от старата версия) на стандартния елемент на разработка към друг стандартен е „конфликт при импортиране“. По този начин такъв конфликт възниква при всяка актуализация на системата, тъй като винаги поне нещо се променя и не се добавят само нови.

Важни точки на преобразувателя:

Той може и трябва да адаптира възможно най-много всички приложни разработки (стандартни и нестандартни) за съвместимост с платформата. Например, ако справочниците или документите в новата версия трябва да съдържат някакъв нов стандартен атрибут или някакъв вид настройка, тогава конверторът трябва да добави тези елементи към всички справочници и типове картони на документи в системата.
Когато преобразувателят извършва преобразуване на данни, се счита, че всички стандартни проекти са приети. Например, ако към стандартната препратка се добави нов атрибут, който трябва да се попълни със стойност по подразбиране, след импортиране на разработката скрипт за попълване на този атрибут ще бъде изпратен на конвертора. Проверката, че този атрибут наистина съществува, обикновено не е включена в скрипта - счита се, че той определено е там.
Ако възникне конфликт при импортиране на дизайн, конверторът показва елемента на дизайна, който го е причинил, и предлага да избере дали да импортира нова версия на него или не. Подробно сравнение - как точно се различават елементите, конверторът не предоставя, но показва какво се е променило „в общи линии“ (например, че е добавен или премахнат реквизит и т.н.). Ако е зададен режимът „автоматично разрешаване на конфликти при импортиране при разработка на системата“, тогава новата версия винаги ще се импортира вместо старата, без да се подканва.
Конверторът не може по някакъв начин автоматично (или поне автоматизирано) да свърже съществуващата и приета версия на елемента за разработка, той може само да пренапише старата версия с новата.
Преобразувателят не приема настройката. Настройката се приема от администратора ръчно в съответствие с инструкциите за преобразуване на системата.
Настройката на квадратчето за отметка „автоматично разрешаване на конфликти при импортиране при разработване на система“ не се отнася за разработването на системата - разработката на системата винаги се приема, имайте предвид това.