Переход с версии 3.0.4 на 3.3.1. Часть 1 (обновлено).

Совсем недавно мы завершили доработку модуля 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)
• проводим альфа-тестирование - все разделы в клиенте должны открываться без ошибок, должны открываться карточки редактирования разделов (работу с данными будем проверять после переноса справочной информации).

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

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

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

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

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

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