Совсем недавно мы завершили доработку модуля 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)
- проводим альфа-тестирование - все разделы в клиенте должны открываться без ошибок, должны открываться карточки редактирования разделов (работу с данными будем проверять после переноса справочной информации).
В процессе переноса не покидала мысль, что надо определить на будущие проекты какие-то рекомендации по разработке, чтобы упростить перевод на другие версии. Ведь приходится переводить не только клиентов, но и собственные отраслевые решения... Посмотрел на комьюнити раздел "Разработчику" - вроде бы все уже описано :)
От себя хочется добавить две вещи:
- бизнес-логика, оформленная отдельными функциями в скриптах к окнам и датасетам базовой конфигурации (или даже вынесенная в отдельные скрипты), облегчает процесс переноса;
- комментарии разработчиков в тексте скриптов также большой плюс.
И вообще, чем меньше изменений в базовых сервисах, тем проще перевод, но надо удержаться от фанатизма...
Первую часть на этом закончу, во второй части речь пойдет о переносе данных.
Прошу, уважаемые коллеги, если есть замечания, рекомендации, высказывайте. Я думаю, что многие партнеры занимались переводом клиентов с версии на версию, и возможно вы увидите ошибки или упущения в моем повествовании.
