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

33 18

В этом материале я опишу подходы, обычно применяемые разработчиками 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, может быть сразу включена в пакет конвертации, некоторые разработчики предпочитают делать так. Но практически в этом нет какого-то серьезного преимущества, т.к. простой импорт разработки не может вызвать каких-то затруднений, главное помнить, что его нужно сделать и иметь эту разработку под рукой. А для этого надо отражать все действия по конвертации в инструкции.

Заключение

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

Отредактировал Елена Питомцева, 15.07.2013 в 09:59
Иван Середкин

Денис, спасибо как минимум за схему структуры DIRECTUM.

Денис Баранов

Отмечу, что это схема именно "с точки зрения прикладного разработчика", поэтому в ней сознательно сделаны некоторые допущения. Например, формально интеграция с Office не относится к платформе, это блок "Сервисное ПО", но практически разницы нет - прикладной разработчик все равно не имеет туда доступа.

Иван Жижик

Очень познавательно) Спасибо Денис )

Вячеслав Лазарев

Денис, так можно четко разделить платформу и прикладную разработку. Например созданный справочник "Работники" это платформе или прикладная разработка и я могу его изменить\удалить, или например отказаться от "связанного" справочника "Персоны", и каким образом мой новый справочник "Работники" будет например стыковаться с системной функцией всплывающей информации от сотруднике (такая сплывающая форма при наведении на реквизит).

Если все таки есть четкое разделение платформы и разработки, могу я получить от Директум только базу с ядром системы, где не будет ничего лишнего, что можно изменять\удалять, где не будет разработанных справочников, сценариев, функций, и все что я разработаю я могу экспортировать и потом импортировать на новую версию платформы без "танцев с бубнами"?!

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

Вячеслав Лазарев

Другими словами, Денис, в папке Utils\SystemDev есть, как мы думаем то, что нам надо. А именно на системную базу накатывается "системная" разработка. Далее, как мы предполагаем, накатывает "прикладная" разработка из Utils\StandardDev. Таким образом рождается "directum_with_dev.dat", которая идет в комплекте с Директум.

Если наши домыслы верны, вот нам требуется база до накатки "прикладной" разработки. А в идеале, вообще системная база, на которую системную разработку накатим мы сами :)

Это реально?

Вячеслав Лазарев

каким образом мой новый справочник "Работники" будет например стыковаться с системной функцией всплывающей информации от сотруднике (такая сплывающая форма при наведении на реквизит).

Этот вопрос снят...справочник OBJECT_HINT_SETTINGS - системный, что позволяет выполнить необходимые настройки.

По остальному ждем Вашего комментария, а лучше помощи :)

Степан Мурашов

Вячеслав, а Вы не могли бы пояснить задачу, для которой нужна база без стандартной прикладной разработки? Вы действительно готовы ее повторить лишь ради того, чтобы потом проще было обновляться?

Вообще, конечно, можно попробовать составить рецепт получения такой БД из обычной. Но одним лишь удалением разработки, перечисленной в Utils\StandardDev, обойтись не удастся - останется много привязок в настройке, например типовые маршруты, блоки от которых будут удалены, вызовы в коде настройки функций ISBL, которые тоже будут удалены, и т.п.

Вячеслав Лазарев

Степан, мне не нравится реализация прикладной разработки и я не хочу быть "привязанным" к ней.

Рецепт наверное есть, но зачем этим заниматься и рисковать, если все это может\должен предоставить вендор.

Степан Мурашов

Disclaimer: Все ниже сказанное - это мое личное мнение и личные размышления.

Вячеслав, давайте попробуем зайти с другой стороны. А какую систему вы собираетесь продавать и поставлять? Это коварный вопрос со скрытым смыслом, и я подозреваю, что именно ответ на него может стать ключевым :) Подсказка: система без стандартной разработки DIRECTUM - это, по крайней мере на мой взгляд, уже не DIRECTUM :)

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

Возможно еще стоит подумать о сложности поддержке такой системы для вендора. Ведь с инцидентами/за консультациями вы все равно будете обращаться к вендору? Для стандартного DIRECTUM есть хорошая документация, есть наработанная база знаний, есть инфраструктура для поддержки (развернутые базы DIRECTUM всех версий со всеми модулями), и т.п. А для базы без стандартной разработки - многое из этого не подходит, придется нарабатывать заново. Окупится ли оно с продаж только базовых лицензий, и, как минимум первое время, всего одним партнером?

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

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

Дмитрий Тарасов
Сборка своего пакета конвертации - отдельная тема, возможно, именно сведения по этой теме и стоит запросить у службы поддержки.
Хочу подробную инструкцию! smiley
Вячеслав Лазарев

Вот сегодня с утра и начали общение с Группой поддержки партнеров.

Как-то вы лихо технические и политические, стратегические вопросы смешали. Если у конкретной компании есть конкретные замечания к прикладной разработке (любому техническому решению) тут только два варианта: или разработчик устраняет замечания или предоставляет возможность устранить их пользователю. У меня есть принцип: если я что-то не могу объяснить себе, я не могу/не буду объяснять это своим клиентам.

Прикладная разработка денег не стоит, я не про типовые решения говорю типа Канцелярия, эти решения с ходу в кастомизацию.

DIRECTUM позиционируется как платформа, вот я хочу строить свои решения на платформе, а не править "всю жизнь" более четырех сотен не понятно зачем созданных реквизитов справочников, с корявыми названиями, и до "конца жизни" к реквизиту "Телефон" справочника "Работники" обращаться по имени "Дополнение4. Больше ничего не хочу "доказывать", кто копался глубоко тот знает, а кто строил отчеты во внешних редакторах типа CrystalReports, MS Reporting и другие проблемы знают.

В моем решении не будет ни слова на русском языке, ни в названиях реквизитах, ни в годах справочников, ни в функциях\сценариях. И вся разработка будет документироваться. А если будет по другому, после рефакторинга буду "руки отрывать" (это я так любя, мои сотрудники знают) :)

 

Нисколько не обвиняю разработчиков решения, прекрасно догадываюсь как решение создавалось много лет и сколько сотрудников через него прошло :) В любом случае мое решение "связать жизнь" с данным продуктом считаю верным и доказываю это другим (в интернете можно найти :))

Ждем ответа вендора!

Денис Баранов

Вячеслав, удалить прикладную разработку из DIRECTUM в принципе можно. Только именно "удалить", а не "не накатывать". Насколько я знаю, баз с исключительно системной разработкой, только с самой платформой, вообще нет. По крайней мере, мне такие не попадались. Потому что компания не поставляет IS-Builder как отдельный от DIRECTUM продукт. Соответственно, каждый новый билд платформы сразу применяется ко всей системе, на ней и тестируется. Технология выпуска такая.

В принципе, опыт "вырезания" прикладной разработки есть - на IS-Builder 7 создана система, по прикладной разработке имеющая с DIRECTUM мало общего - Orienge Conterra. Но проект по ее созданию был еще тот по трудоемкости. Но опять же - делалась новая система, не было цели создать поставку IS-Builder без ничего. 

Вячеслав Лазарев

Денис,  Orienge Conterra посмотрели, по видео особой разницы с DIRECTUM не увидели, все локализовано, карточка электронного документа Договорного документа в принципе та же.

А причем тут IS-Builder без ничего и как отдельный продукт? Я так понимаю это предметно-ориентированный язык с объектной моделью работы с данными (читай с БД). На нем сверху построен продукт DIRECTUM, со своим интерфейсом и объектами, а вот сверху уже выполнена прикладная разработка (для решения общих задач, аля оргструктуру компании завести, номеклатуру дел создать и т.п.) + бизнес-решения (для решения конкретных задач, аля договор согласовать).

Нам нравится DIRECTUM как продукт и платформа, не без своих заморочек конечно, но в целом очень достойно. А вот прикладная разработка "подкачала", но тут дело вкуса может быть. У нас он вот такой :)

Вячеслав Лазарев

Итак как удалить прикладную разработку? Только вручную удалять каждый реквизит в карточках, а потом в справочнике не хотим, упаримся - а групповых операций нет (вот такой сюрприз)

Дмитрий Тарасов

Вячеслав, а зачем вам вообще нужна голая платформа? Собираетесь разработать на данной платформе свой какой-то продукт аля престима или контерра? Это весьма сомнительное занятие, даже если не брать в расчет огромные трудозатраты. Попытка же переписать "свой" директум "с нуля", так вообще голимая утопия, которая не стоит тех трудозатрат, которые придется на это потратить, а результат не факт, что будет лучше того, что уже есть. Возможно, конечно, все это и имеет какой-то смысл, но не на этой версии платформы, которая, на мой взгляд, уже морально устарела и слишком во многом ограничивает прикладного разработчика. Я бы подождал новой версии платформы (уж точно не 4.х.х), а действительно новой и уже оценив её возможности и перспективы начал бы думать, нужна она мне в голом виде или нет.

Иван Чурбаков
Я так понимаю это предметно-ориентированный язык с объектной моделью работы с данными (читай с БД). На нем сверху построен продукт DIRECTUM, со своим интерфейсом и объектами, а вот сверху уже выполнена прикладная разработка (для решения общих задач, аля оргструктуру компании завести, номеклатуру дел создать и т.п.) + бизнес-решения (для решения конкретных задач, аля договор согласовать).
Я бы сказал, что DIRECTUM - это и есть прикладная разработка для решения общих задач, канцелярии и т.п. Т.е. один слой у вас лишний в данной схеме, его реально не выделить из системы.
Если хотите получить только IS-Builder, удаляйте лишние справочники (которые не относятся к системной разработке) и их реквизиты. В итоге должно остаться только то, без чего IS-Builder работать не будет.
Если хотите, чтобы вообще не было русскоязычных реквизитов в системе, лучше для этого взять базу от Orienge Conterra: основная трудоемкость в ее создании как раз и была из-за необходимости все русские данные заменить англоязычными (в том числе системные реквизиты).
Вячеслав Лазарев

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

Дмитрий, да не то что бы переписать, привести все в полный порядок, кое от чего отказаться, что-то сделать проще. Сколько в неширокой таблице SQL может быть колонок? А сколько в таблице MBAnalit уже? :) На наш век хватит и можно плодить еще 7-8 сотен новых реквизитов? Или использовать имеющиеся, тогда почему этого нет в текущей разработке? :)

Иван, Вам конечно виднее :) 

Вообще выполняя такую задачу, много всего "накопали" уже, особенной части как системная разработка вдруг начинает напрямую ссылаться на прикладную, о которой она по идеи ничего не должна знать :)

 

 

 

Виктор Золотов

Вячеслав, судя по всему в стандартной конфигурации вы обнаружили "фатальный недостаток"...  )))

http://lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA

 

 

Авторизуйтесь, чтобы написать комментарий