В пятницу, 29 августа, прошла IT-конференция «Центра разработки и внедрения Terrasoft Поволжье» в формате «коллеги для коллег». Событие подобного формата проходило впервые, но собрало много положительных отзывов среди участников, и стало отличной площадкой для обмена опытом и детального разбора профессиональных процессов.

УТРО.
8:30, просека, «Олимп». Чудесная погода, на небе ни облачка. Немного сонное, но хорошее настроение. Ребята потихоньку приезжают в назначенное место, регистрируются и берут фирменные майки и бейджи. Кстати, о бейджах: идейным вдохновителем конференции стал Александр Свистунов, и в дополнение к свободному и лёгкому формату мероприятия, он предложил сделать самые нетипичные надписи, олицетворяющие участников. То было удивительно и странно, но в дальнейшем на каждом из ребят красовались тексты вроде «Адепт javaScript», «Выполняю бесконечные циклы за 5 секунд», «Троечник», «Хорошо делаю кофе» и т.д.
Вдохновитель конференции явился и ее первооткрывателем, начав программу докладов. Александр представил всем план текущего мероприятия, рассказал об истории и перспективах роста «Программных Технологий». Невозможно было не обратить внимание на частые Сашины заметки о том, что главной гордостью и богатством компании являются ее кадры.
Сразу после вводной части, началась основная часть конференции с доклада «Методология. Путь к удобству». «Методология – есть основа процесса ведения проекта. Именно с переходом на новую методологию связано разделение труда по ролям и соблюдения регламентов взаимодействия как внутри команд, так и с заказчиком» - Александр вводил слушателей в курс дела.

Перед тем, как разойтись на 3 параллельные сессии, был устроен кофе-брейк на свежем воздухе. И тут из толпы послышался звонкий возглас: «Белочка!!!» Действительно, маленькая красавица бегала по дереву, метрах в 5 от людей, не боялась и позировала как настоящая модель.
Кофе был весьма кстати, поскольку после него начался настоящий интеллектуальный штурм, участники разделились на 3 группы и разошлись по нескольким тематическим площадкам: Маргарита Шаркова на собственных примерах доходчиво рассказала о сборе требований и документации, а Александр Свистунов и Марина Шальнева – об «архитектуре» Terrasoft 3.X.
В докладах Тимофея Яблокова «JS/ExtJS или как сломать мозг программисту», «Отчеты. От простого к ужасу», Дмитрия Толмачева «Принципы совместной работы», Александра Семенова и Антона Мочальникова «Интеграции с внешними системами», непосвященному слушателю были понятны лишь предлоги. Ребята раскрывали темы, используя профессиональный технический слэнг, и легко отвечали на заданные вопросы, демонстрируя высокий уровень владения предметом.
Марина Шальнева представила доклад «Типичные задачи в Террасофт 3.Х», коснувшись разделов «инструменты разработчика», «запросы и отчеты» и «создание полей реестров и деталей».

ОБЕД.
Что может быть прекраснее этого слова? Конечно же, «bpm’online», но сейчас мы не об этом.
Построившись парами в одну большую шеренгу, голося кричалки: «Кто шагает дружно в ряд…?», отряд направился в столовую. Салат, первое блюдо, второе, 2 вида выпечки напомнили о детстве. Но даже во время обеда за столами не угасало общение в продолжение дискуссий по докладам. Всё непонятое – пояснялось, всё несказанное – озвучивалось. Проголодавшиеся сотрудники продемонстрировали равный интерес как к пище духовной, так и ко вкусной солянке, котлеткам и булочкам.

После сытного обеда, с целью борьбы со сном, Дмитрий Толмачев поведал об основах построения процессов в bpm’online и работе с базой данных, подробно рассмотрев высокоуровневый класс ESQ – EntitySchemaQuery, приложение SQL Server Profiler, позволяющее перехватывать события SQL Server и язык интегрированных запросов - Linq. В этот момент Александр Свистунов на соседней площадке развлекал слушателей освещением тем интеграции bpm’online с сайтами, 1С и импорта данных в систему.

ВЕЧЕР.
Во время того, как ребята представляли последние доклады, стремились к вершинам IT-мастерства, и штурмовали баррикады неизвестности, в беседке, около мангала, разворачивалась кампания по подготовке вечернего досуга и трапезы. Мангал зазывал всех отведать сочных сосисок, ножи плясали в умелых руках наших «гуру высокой кухни», ароматы глинтвейна разносились далеко за пределы беседки.
К тому моменту, когда ребята, слегка уставшие, но довольные вышли из «аудиторий», всё уже было готово, и началась последняя часть конференции.
Обмен впечатлениями, поздравления и тосты были наполнены позитивом, а зажигательные конкурсы, чудо-фокусы, песни и разговоры у огня и танцы помогли расслабиться и окунуться в атмосферу беззаботного веселья.
Так прошла наша первая образовательная конференция в формате «коллеги для коллег».

Александр Свистунов, руководитель отдела исследований и разработки: «Идея проведения конференции родилась из потребности обучения персонала. Пробежавшись по темам, мы поняли, что парой докладов тут не обойтись. В итоге все это вылилось в полноценную «One Day Конференцию». Самое интересное в подготовке - было распределение тем по докладчикам (ребята проявляли инициативность, и мы с трудом уместили все темы в 3 сессии).
При чтении докладов возникало очень много интересных смежных тем, поэтому пришлось даже продлить время конференции в счет части обеда.
Ну и, конечно же, на уровне была вся организация мероприятия – начиная от качества докладов и заканчивая вечерней культурной программой на свежем воздухе! Каждый остался доволен!»

Ссылка на фото: http://samarasoft.ru/info/photo-gallery/407/

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

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

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

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

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

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

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