Технические принципы обновления системы DIRECTUM

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

Структура системы DIRECTUM с точки зрения разработчика

Для начала немного теории про структуру системы. Вся разработка системы делится на «платформу» и «прикладную разработку». У того, кто к такому делению уже привык, обычно не возникает вопросов что к чему относится и чем друг от друга отличается. Но начинающему разработчику или администратору это не столь очевидно. Объяснить это лучше всего на схеме.

При внедрении системы мы можем адаптировать под нужды заказчика прикладную разработку и настройку, как изменив существующую в системе («стандартную разработку»), так и создав новую. В целом, вся интерпретируемая часть доступна для модификаций. Как видно из схемы, часть интерпретируемой разработки относится к платформе («системная разработка»). К платформе относят ту разработку, которая написана на ISBL и доступна для модификаций, но является критичной для работы всей системы. Например, справочник «Пользователи». В принципе, вносить изменения в системную разработку можно, но самый минимум и с тщательным тестированием.

Итого, к моменту необходимости обновления системы мы имеем:

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

Что входит в конвертер и как он обновляет систему

Стандартный конвертер системы DIRECTUM предназначен для обновления системы на новую версию с помощью:

1. Обновления серверной части платформы (SQL скрипты создания и модификации таблиц, триггеров, хранимых процедур и т.п.);
2. Импорта стандартной прикладной разработки;
3. Преобразования данных под новую прикладную разработку.

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

Внутренняя структура пакета конвертации – отдельная тема и тут ее опустим. Скажу лишь, что convertpackage.dat – это обычный zip-архив, его можно изучать и даже изменять.

Что может и чего не может конвертер

Для описания особенностей функционала конвертера важно сначала уточнить один термин. Перед конвертацией системы утилита конвертации предлагает выбрать значение следующей настройки:

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

Важные моменты работы конвертера:

1. Он может и должен максимально адаптировать всю прикладную разработку (стандартную и не стандартную) для совместимости с платформой. Например, если в справочниках или документах в новой версии должен быть какой-то новый стандартный реквизит или какая-то настройка, то конвертер должен добавлять эти элементы во все справочники и типы карточек документов системы.
2. Когда конвертер выполняет преобразования данных, то считается, что вся стандартная разработка была принята. Например, если в стандартный справочник добавляется новый реквизит, который должен быть заполнен значением по умолчанию, то в конвертере после импорта разработки будет идти скрипт заполнения этого реквизита. Проверка на то, что этот реквизит действительно есть, обычно в скрипт не включается – считается, что он точно есть.
3. Если при импорте разработки возникает конфликт, то конвертер показывает элемент разработки, послуживший причиной, и предлагает выбрать – импортировать его новую версию или не импортировать. Детального сравнения – чем точно отличаются элементы конвертер не предоставляет, но показывает что поменялось «в общих чертах» (например, что добавился или удалился реквизит и т.п.). Если установлен режим «автоматически разрешать конфликты импорта разработки системы», то всегда будет импортироваться новая версия на место старой, без запроса.
4. Конвертер не может как-то автоматически (или хотя бы автоматизировано) соединить существующую и принимаемую версию элемента разработки, он может только переписать старую версию новой.
5. Конвертер не принимает настройку. Настройка принимается администратором вручную согласно инструкции по конвертации системы.
6. Настройка галочки «автоматически разрешать конфликты импорта разработки системы» не распространяется на системную разработку – системная разработка принимается всегда, учитывайте это.

Варианты действий при обновлении системы

Набор необходимых инструментов для обновления:

1. Документ с изменениями по версиям системы DIRECTUM;
2. Утилита конвертации и пакет конвертации;
3. Список измененной стандартной разработки своей системы (желательно с причиной изменений);
4. Дистрибутив последней версии системы.

Главная сложность всегда возникает с пунктом 3. Почти никто не обладает настолько подробной и актуальной документацией на свою систему, особенно когда с момента ее внедрения прошло несколько лет. Тем не менее, такой список весьма полезен при обновлении, т.к. позволяет до конвертации проанализировать изменения стандартной разработки и выбрать один из вариантов конвертации.

Не буду рассматривать случай, когда измененной стандартной разработки нет, потому что тогда нужно просто следовать инструкции по конвертации и все будет готово. В случае же, когда что-то в стандартной разработке изменялось, нужно решить – какой способ сведения вместе старого и нового оптимален в данном случае.

Первый способ – заменить всю измененную стандартную разработку новой версией и потом повторить сделанные изменения. Например, когда мне известно, что в справочник «Работники» был добавлен нестандартный реквизит, то мне проще принять новую версию справочника со всеми изменениями и потом, после конвертации, снова добавить туда этот реквизит.

Второй способ – обновить платформу, но не принимать часть (или даже все) изменений стандартной прикладной разработки. После обновления нужно проверить весь функционал системы, посмотреть что перестало работать в прикладной разработке, исправить все несовместимости. Возможно, вручную перенести какие-то понравившиеся «фишки» новой стандартной разработки в свою. Например, если я кардинально переделал справочник РКК, то мне проще вообще не принимать разработку стандартного справочника, чем перетереть свой справочник стандартным и потом вручную доводить его снова до требуемого мне функционала.

Очевидно, что первый способ дает лучшие результаты в плане качества, но очень трудоемок в случае сильного изменения стандартной разработки. Если стандартный функционал системы сильно переработан, то часто имеет смысл обновлять платформу, а по всему остальному уже решать – что из изменений стандартной разработки интересно для вашей системы.

Еще один важный момент – связь разработки и настройки. Например, внедрена стандартная канцелярия версии DIRECTUM 4.4, но при этом типовые маршруты сильно изменены под нужды организации. В этом случае, если принять разработку канцелярии DIRECTUM 4.9, то эти маршруты работать не будут, несмотря на то, что разработка и там, и тут стандартная. Для раннего выявления подобных моментов следует внимательно изучать изменения по версиям системы DIRECTUM, особенно в случае выбора первого способа обновления, когда измененная разработка заменяется на новую стандартную.

Как быть, если список изменений стандартной разработки не известен

В этом случае можно воспользоваться одной хитростью – взять полный пакет стандартной разработки вашей текущей версии DIRECTUM (на диске с системой находится в каталоге UTILS\StandardDev) и попытаться импортировать в свою систему. Утилита импорта разработки выдаст примерно следующий результат:

Все что попало в тип модификации «изменение» – это и есть отличия вашей стандартной разработки от эталона. Для более точного понимания сути изменений, можно развернуть эталонную пустую базу DIRECTUM и, сравнивая свою разработку и эталон, вникать в смысл найденных несоответствий. Возможно, многие из них отличаются комментарием в коде, лишним переносом строки, а то и вообще только датой изменения (впрочем, последнее будет видно сразу после завершения сравнения разработки утилитой импорта).

Важно помнить, что системная разработка хранится отдельно (каталог Utils\StandardDev), ее тоже стоит проанализировать.

Подготовка к конвертации – последовательность действий

Обновление системы обычно производится в нерабочее время и почти всегда стоит задача минимизировать трудоемкость «боевой» конвертации и повысить ее качество и надежность. Для этого к ней нужно готовиться заранее. Не буду тут упоминать про установку служб, подготовку дистрибутивов клиентских частей к распространению – это все описано в соответствующих инструкциях и хитростей там нет. Остановлюсь на подготовке самого пакета конвертации (в расширенном смысле этого термина). Итак, я бы конвертировал систему так:

1. Развернуть тестовую копию своей системы и стандартную систему DIRECTUM той же версии, проанализировать отличия своей системы от стандартной. Если подходить совсем основательно, будет не лишним установить еще и систему DIRECTUM той версии, до которой планируется обновление - так можно получить представление о соотношении "что у меня сейчас"-"что у меня нестандартного"-"что я в итоге должен получить";
2. Определить список той разработки, которую стоит принять во время конвертации, а от приема какой лучше отказаться, отразить это в инструкции по конвертации (пригодится для того, чтобы не думать при конвертации рабочей базы);
3. Посмотреть на скрипты конвертера, нет ли там лишних с вашей точки зрения скриптов (например, вышеупомянутый скрипт заполнения нового реквизита справочника, разработку которого вы решили не принимать), убрать из пакета конвертации эти скрипты.
4. Сконвертировать тестовую систему;
5. Применить на сконвертированной системе все известные модификации разработки. Например, если я принял новый справочник «Работники» без нестандартного реквизита, то на этом этапе этот реквизит нужно добавить заново;
6. Организовать тестирование системы, найти и устранить все несовместимости;
7. Выгрузить всю разработку и настройку, которую изменили в пунктах 5 и 6;
8. В нужный день и нужный час сконвертировать рабочую базу,
9. Импортировать туда разработку и настройку из пункта 7.

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

Заключение

Обновление системы для среднестатистического разработчика не такое уж страшное дело. Самое трудоемкое – анализ того, что же изменилось и как эти изменения применить. И нельзя забывать о качественном тестировании, только оно позволит выявить все несовместимости.