Сегодня немного расскажу о новой версии Terrasoft 3.4.0, некоторых ее особенностях по сравнению с предыдущей версией (3.3.2) и о методах перехода с 3.3.2 на 3.4.0.

Новое ядро Terrasoft 3.4.0

Было сделано очень много работы. Некоторые задачи давно уже планировали, некоторые появились по ходу работы. Обо всем рассказать не смогу, остановлюсь только на крупных, наиболее значимых вещах.

Ядро Terrasoft. Все началось с того, что в Delphi 2009 наконец-то появился полноценный, «нативный» юникод. Поэтому было решено перейти с Delphi 7 на последнюю версию, на тот момент это был Delphi 2010. А в процессе перехода появилась следующая версия: Delphi XE, переход на который уже занял несколько дней. И вот релиз Terrasoft 3.4.0 вышел при использовании самой новой версии Delphi. Таким образом значительно упростится переход на следующую версию (Delphi XE2), которая уже поддерживает компиляцию приложений под х64. А с этим уже не за горами и Terrasoft x64.

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

Так как теперь все «родные» компоненты Delphi полностью поддерживают юникод, то стало возможным не использовать промежуточные компоненты, которые приходилось писать поверх стандартных (чтобы обеспечить ввод и отображение юникода). Вследствие этого уменьшилось почти в два раза использование GDI Objects: значение после запуска у 3.3.2 – 1564, 3.4.0 – 881. Также на 30% уменьшилось потребление памяти.

При переходе на новую Delphi решили полностью переписать компонент Layout. В конфигурации он представлен в виде Frame и FrameGroup, а также всех других компонентов, которые его поддерживают: DataGrid, WindowContainer, PageControl и т.д. Именно он управляет автоматическим размещением и выравниванием компонентов на формах. И вместе с этим заново реализована отрисовка ScrollBar в компонентах Terrasoft. Таким образом, исправили большое количество старых ошибок и, благодаря этому, значительно улучшилась отрисовка интерфейса. Лучше всего это можно увидеть при изменении размеров окон, сворачивании/разворачивании главного окна.

В новой версии была произведена оптимизация и переработка библиотек. В библиотеку TSWindowLibrary.dll включена часть TSDskObjectLibrary.dll, полностью вся TSDskWindowLibrary.dll и TSReportLibrary.dll. Пакеты компонентов теперь представлены с помощью: TSCoreComponents.bpl, TSComponentsExtra.bpl, TSComponents.bpl и Terrasoft.bpl. Благодаря этому при работе с не визуальными COM-объектами Terrasoft, подгружается только необходимый минимум: TSObjectLibrary.dll и TSCoreComponents.bpl. Как следствие уменьшилось потребление памяти при работе Service Desk Web-формы.

Переход с Terrasoft 3.3.2

Главным требованием при разработке 3.4.0 было обеспечить полную обратную совместимость с 3.3.2. Поэтому если у вас есть 3.3.2 и вы хотите использовать новое ядро 3.4.0, то это можно сделать максимально быстро. Например, у вас продукт Terrasoft XRM и вы хотите перейти на бинарные файлы 3.4.0.53.

План действия таков:

1. В таблице tbl_DatabaseInfo меняете используемую версию:
   
   UPDATE [tbl_DatabaseInfo] SET
         [DatabaseMajorVersion] = 3
         [DatabaseMinorVersion] = 4
         [DatabaseReleaseVersion] = 0
         [DatabaseBuildVersion] = 53
2. Регистрируете новые бинарные файлы
3. Запускаете Менеджер лицензий: TSClient.exe /wnd=wnd_LicenseManager
4. На закладке «Продукт» к своему продукту (в данном случае Terrasoft XRM) добавляете два новых модуля: Dictionary и JobManager (скриншот)
5. Перезаказываете лицензии в тех. поддержке

Все, больше ничего делать не нужно.

Пакеты перехода на 3.4.0

Помимо нового ядра, много удобных вещей было реализовано в конфигурации:

1. Мастер настроек (Implementation Wizard)
2. Поиск и слияние дублей
3. Планировщик задач
4. Раздел Справочники
5. Wizard пользовательских запросов
6. Wizard графиков
7. Настройка рабочих мест

Подробнее можете почитать тут: Новая функциональность версии 3.4

Чтобы перенести все новые конфигурационные функции нужно делать полноценный переход. А это уже нужно делать с помощью пакетов перехода. Новые пакеты перехода всегда делаем по требованию, для этого вам нужно обратиться в техническую поддержку и указать вашу текущую версию, используемый продукт и СУБД. Уже с октября мы начинаем отгружать первые пакеты перехода.

Первая часть здесь - http://community.terrasoft.ua/blogs/4354

Продолжу описывать общую методологию перехода на новую версию. Сервисы уже перенесены, нам осталось перенести данные.

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

Кроме того, генерируется два скрипта, на отключение триггеров и внешних ключей, и на их включение (миграция производится на СУБД Microsoft SQL Server).

Перед выполнением шага 3 отключаем триггеры и внешние ключи.

Шаг 3. Перенос данных о пользователях и группах.

Эти данные важно перенести в первую очередь, так как вся прочая информация ссылается на пользователей или контакты (например, записи о правах, поля CreatedByID, ModifiedByID и т.п.)

Фактически переносим данные всего четырех таблиц:

• tbl_Account, tbl_Contact - только те записи, которые касаются пользователей системы, и только поля ID и Name (остальные поля будем переносить уже у клиента);
• tbl_AdminUnit и tbl_UserInGroup - полностью.

Шаг 4. Перенос справочных данных.

Перенос справочных данных в сгенерированном скрипте выделен отдельно (на основании данных таблицы tbl_DictionarySettings).
Как правило, для справочных таблиц сначала генерируется запрос на удаление всех записей, а потом на вставку из рабочей базы, так как нам важны ИД справочных записей.

После выполнения шага 4 включаем триггеры и внешние ключи.

На данном этапе можно провести тестирование базы на работоспособность. У нас должна работать вся логика.

Шаг 5. Перенос основных данных.

Ставим дамп клиенту, и начинаем переносить основные данные, используя вторую часть сгенерированного скрипта.

Предварительно отключаем триггеры/внешние ключи, после выполнения скрипта включаем их.

Шаг 6. Корректировка данных пользователей.

Так как между 3.0.4 и 3.3.1 большая разница в плане реализации прав доступа к данным, после переноса данных с помощью отдельных скриптов на Transact-SQL необходимо:

• создать роли для групп пользователей (используя данные из tbl_AdminUnit);
• создать логины и пользователей в базе (используя данные из tbl_AdminUnit);
• включить пользователей в роли (используя данные из tbl_UserInGroup);
• перенести права на группы таблиц (записи из tbl_TableGroupRight);
• перенести права по умолчанию (записи из tbl_TableDefaultRight);
• перенести права на поля (используя данные из tbl_TableFieldRight). 

Осталось протестировать работоспособность новой версии, и клиент может приступать к работе.
 

Буду рад, если эта информация пригодится кому-либо в работе. Если будут вопросы - с удовольствием отвечу.
 

Совсем недавно мы завершили доработку модуля PVC в плане поддержки разных версий Террасофт и СУБД (теперь он работает с версиями 3.2-3.3.1 под все СУБД, и интерфейс модуля доступен на русском и английском языке), и решили продолжить его наполнение функциональными возможностями. Очень кстати один наших клиентов решил перейти на новую версию Террасофта, поэтому в разработку был взят мастер миграции с одной версии на другую.

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

Предистория мастера миграции - у нас как минимум раз в год возникают проекты по переводу наших клиентов с одной версии Террасофт на другую. Тот, кто делал такие проекты, знает, что эта работа требует определенных усилий :) Мы выработали для себя стратегию перевода конфигурации, и написали некоторый инструментарий. Об этом я и буду рассказывать в последующих нескольких записях блога.

Исходные данные:
1) дамп клиента, в котором присутствуют справочные данные и информация о пользователях, но нет основных данных (контрагентов и их деталей, контактов и их деталей и т.д);
2) "чистый" дамп той же версии, что и дамп клиента;
3) новый дамп из нужной нам версии Террасофт.

Вначале работы указываем некоторые настройки для мастера миграции:
- строка ADO-соединения к новой базе
- названия баз данных (рабочей, "чистой" и новой)
- утилиту Merge

Далее выполняем обновление.

Шаг 1. Перенос новых сервисов.
Самая легкая часть обновления...
Нажимаем в мастере кнопку "Шаг 1" и получаем перечень новых сервисов в иерархическом виде.
Затем нажимаем кнопку "Перенести все", и все сервисы переносятся в новую базу.

При этом автоматически:
- корректируются USI сервисов;
- при необходимости "укорачиваются" коды индексов и FK таблиц;
- корректируются сервисы, наследованные от wnd_BaseGridArea и wnd_BaseWorkspace
- создаются таблицы в базе данных

В итоге мы за считанные минуты получаем работоспособные сервисы уже в новой версии.

Шаг 2. Перенос измененных сервисов

Это самая трудоемкая и ответственная часть обновления, требует терпения и внимательности :)

Здесь приходится активно пользоваться Merge-утилитой, чтобы, с одной стороны, сохранить функциональность новой версии Террасофт, и с другой стороны - перенести настройки из старой.

Мастер миграции в данном случае выступает помощником:
- отображает список измененных сервисов (в виде иерархии);
- позволяет запустить утилиту Merge для сравнения двух версий (рабочей и новой) или трех версий (из "чистой" базы, рабочей и новой) сервиса, при этом результат "слияния" предлагает сохранить в новую базу (экраны утилиты Merge вставлять не буду, их и так все знают :) );
- позволяет ставить сервису отметку "Обработано" и выводить в списке измененных сервисов только необработанные.

Кроме того, использование мастера позволяет не тратить время на такие вещи, как заголовок и размер окна, заголовок датасета и характеристики полей в датасете (обязательность, заголовок и т.д.).
Для этого в мастере есть сервисная кнопки для автоматического "приведения" этих характеристик к используемым в рабочей базе:

Также мастер позволяет открыть в Администраторе все сервисы SelectQuery, в которых есть колонки типа "Текст SQL". Это связано с тем, что в последних версиях Террасофта для доступа к данным используются представления (vw_), и после переноса, возможно, в таких колонках надо заменить таблицы на представления.

Итак, резюмируем общий алгоритм:

• переносим новые сервисы;
• переносим измененные сервисы, пользуясь утилитой Merge (не забываем, что при переносе сервисов-скриптов надо "сливать" не только текст скрипта, но и сам сервис, для переноса данных о подключенных скриптах и перечислениях);
• обновляем характеристики окон и датасетов;
• проверяем поля с текстом SQL в запросах;
• опционально вручную выполняем две следующие операции:
  • если в нашей конфигурации есть новые разделы, то открываем в Администраторе таблицы групп новых разделов, ставим галку "Администрируется по записям", и сохраняем (чтобы создалось соответствующее vw_ - представление).
    Так как новых разделов обычно мало, эту операцию мы не автоматизировали.
  • если используется чтение системных параметров, то либо надо заменить вызов GetSystemParameterValue в скриптах на GetSystemParameterValueEx, либо сделать функцию-прокси (GetSystemParameterValue, вызывающую GetSystemParameterValueEx)
• проводим альфа-тестирование - все разделы в клиенте должны открываться без ошибок, должны открываться карточки редактирования разделов (работу с данными будем проверять после переноса справочной информации).

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

От себя хочется добавить две вещи:

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

И вообще, чем меньше изменений в базовых сервисах, тем проще перевод, но надо удержаться от фанатизма...

Первую часть на этом закончу, во второй части речь пойдет о переносе данных.

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