Быстрое развитие технологий и инструментов разработки ПО приводит к тому, что технологии, лежащие в основе информационной системы, теряют свою актуальность и становятся тяжелой ношей. Взять, к примеру, какую-нибудь разработку компании для автоматизации процессов, написанную на Visual Basic 6.0 или Delphi 7, которая, мягко говоря, не сочетается с новыми трендами “все в web, все в облака”, да и не соответствует амбициям разработчиков.
Проблема перевода старой ИС на новые технологии, доходя до руководства, традиционно упирается в деньги: “поживем и так...”. Для разработчиков, в свою очередь, уже перенос модели данных и шаблонное программирование стандартных экранов вызывает негатив. При этом зачастую все усложняется требованием сохранения работоспособности старой ИС на этапе разработки и внедрения новой. Так или иначе, по моему опыту, продукт либо умирает совсем, вызывая мучения как программистов, так и пользователей, либо все же приходит понимание, что обновление ИС — неотложная необходимость.
Исходя из описанных проблем, а также учащающихся запросов как к вендору платформы о помощи в миграции устаревших систем на CUBA, мы решили добавить механизм, который сделает этот процесс максимально легким для программистов и дешевым для руководства.
Под катом пошаговая инструкция, как модернизировать устаревшую систему с минимальными усилиями на перенос модели данных и стандартных CRUD экранов.
Для демонстрации мигратора, который начиная с версии 2.1 представлен в CUBA Studio, мы подготовили пошаговую инструкцию о том, как модернизировать устаревшую систему, минимизируя усилия на перенос модели данных и стандартных CRUD экранов. Так как Microsoft официально прекратил поддержку LightSwitch — популярного инструмента для быстрой разработки корпоративных информационных систем — мы выбрали для примера и перенесли на платформу CUBA демонстрационное приложение LightSwitch Vision Clinic и выложили его на GitHub с подробным описанием предпринятых действий. Если у вас есть необходимость или опыт в модернизации ПО, приглашаем вас пройти по предложенному примеру.
Мы будем использовать встроенный в CUBA Studio мигратор для реверс-инжиниринга. Он извлекает метаданные из старой базы и использует их, чтобы автоматически:
1. Сгенерировать модель данных на основе существующей БД,
2. Обновить БД, чтобы создать необходимые системные таблицы CUBA Platform,
3. Сгенерировать стандартный CRUD UI.
Таким образом, основную рутину берёт на себя CUBA Studio. Тем не менее, бизнес-логику и дизайн экранов, отличный от стандартного, в новое приложение нужно переносить вручную.
Если вам просто интересно посмотреть, что у нас получилось в итоге, пролистайте до раздела Можно ли запустить приложение без MSSQL?
Пара слов об исходном приложении
Теперь о том, что представляет собой легаси-приложение, которые мы выбрали жертвой для миграции. Мы скачали демо-приложение для абстрактной глазной клиники с официального сайта Microsoft. Оно написано в среде разработки Microsoft Lightswitch, поддержку которого Microsoft официально прекратил несколько месяцев назад.
По сути, это стандартное 3-слойное приложение, демонстрирующее основные фишки LightSwitch: создание модели данных, скаффолдинг экранов и вычисляемые атрибуты сущностей. Пример VisionClinic хранит данные одновременно в 2 разных БД, связанных между собой. Для упрощения, мы объединили эти две базы в одну.
Системные таблицы CUBA будут созданы в той же базе данных. Эти изменения никак не скажутся на таблицах, используемых старым приложением LightSwitch, так что его можно будет запустить на том же экземпляре базы данных.
Примечание: БД легаси-приложения можно подключить к CUBA-приложению и как дополнительный датастор. В этом случае старая БД останется совсем без изменений, а кубинские таблицы будут храниться отдельно.
Вот как выглядит пользовательский интерфейс приложения Lightswitch. Нам больше всего понравился экран Products list — он чуть посложнее остальных:
В целом, это классическая разметка экрана энтерпрайз-приложения: сверху расположено основное меню, экраны открываются в виде новых вкладок в том же окне. Если хотите, можете создать его самостоятельно по инструкции, или просто скачать. Нам от всего приложения понадобится только база данных. Как её установить, подробно описано в соответствующем разделе.
Приложение на базе CUBA
Забегая вперёд, скажу, что мы хотим в итоге получить. Мы создадим полностью функциональное приложение на Java, традиционно состоящее из 3 слоёв, с полноценным веб-клиентом, повторяющим UI и бизнес-логику исходного приложения Lightswitch. Как уже говорилось, приложение не изменит структуру существующих таблиц, так что оба приложения смогут работать параллельно на одном экземпляре БД.
На скриншоте ниже показан тот же экран продуктов, но уже в CUBA-приложении, можете сравнить:
Шаг 1. Установка окружения и Базы Данных
1. Скачаем и установим платформу CUBA согласно Инструкции по установке из документации на платформу.
2. Скачаем и установим MS SQL Server 2012+ с официального сайта. Пропустите этот шаг, если сервер у вас уже установлен.
3. Выполним скрипт create-db.sql на экземпляре MS SQL DB, чтобы создать базу данных VisionClinic.
4. Выполним скрипт insert-data.sql на свежесозданной БД VisionClinic, чтобы заполнить её тестовыми данными.
5. Разрешим SQL Server and Windows Authentication mode и вход от имени пользователя sa, как показано здесь. Запомним пароль для sa, он будет нужен для подключения к базе из приложения CUBA.
Шаг 2. Создание проекта на CUBA
1. Запустим сервер CUBA Studio (1) и откроем Studio в браузере (2).
2. Создадим новый проект (1), введём vision-clinic в поле имени проекта (2) и нажмём OK.
3. В секции Project properties установим подключение к базе данных VisionClinic и заполним следующие поля:
- Database type — Microsoft SQL Server 2012, здесь укажите вашу установленную версию (1)
- Database URL — localhost, или доменное имя/IP компьютера с установленным SQL Server (2)
- Database name — visionclinic, это имя было создано при выполнении скрипта create-db.sql в шаге 1, пункт 3 (3)
- Database user и Database password — используйте свои параметры входа для sa в SQL server, или другого пользователя с правами администратора (4)
4. Нажмём Test connection (1) и проверим, подключилась ли Studio к нужной нам базе. Получив сообщение Connection successful (2), нажмём OK (3) для сохранения введённых параметров.
Шаг 3. Мигратор — Модель данных и генерация CRUD UI
На этом шаге мы сгенерируем модель данных (т.е. сущности), основанную на структуре существующей БД, и простой пользовательский интерфейс для манипуляций с данными.
1. Перейдём на вкладку DATA MODEL и нажмём на ссылку Generate model.
2. CUBA Studio запросит обновление базы данных, чтобы создать свои таблицы, необходимые для работы платформы, как то: настройки безопасности, аудит состояния, динамические атрибуты, и т.д. Подтвердим обновление.
3. Появляется окно GENERATE MODEL FROM DATABASE. Здесь мы настроим маппинг таблиц базы данных и их столбцов к сущностям и их полям.
4. Нажмём на кнопку Settings в верхней панели, чтобы настроить общие параметры маппинга. В нашем демо-приложении оба фреймворка позволяют отслеживать, кто и когда создал или изменил запись в базе, поэтому мы связываем предопределённые кубинские поля createTs, createdBy, updateTs, updatedBy с соответствующими системными столбцами в существующей базе, которые есть почти во всех её таблицах: Created (1), CreatedBy (2), Modified (3), ModifiedBy (4).
RowVersion (5) — ещё один системный столбец, который в Lightswitch используется для оптимистической блокировки. К сожалению, его нельзя привязать к столбцу version, используемому в платформе для той же цели, так как типы этих полей не совпадают. Для поддержки оптимистической блокировки в приложении CUBA можно создать другое поле, но раз мы решили ничего не менять в структуре таблиц, то просто удалим этот столбец из маппинга и нажмём ОК.
5, Нажмём на кнопку Show tables в верхней панели и выберем таблицы, по которым будут созданы сущности в новом приложении. Выберем все кнопкой Select all и снимем выделение с sysdiagrams (1), — это служебная таблица MS SQL, в которой хранится схема базы данных, для миграции нам она не нужна. Нажмём Next (2).
6. На этом этапе можно настроить маппинг более тонко, на уровне отдельных сущностей и их полей. К примеру, CUBA предусматривает, что имена всех сущностей должны быть в единственном числе, так как Studio на их основе генерирует основные строки UI, такие как имена экранов и заголовки пунктов меню. Поэтому переименуем сущности, убрав отовсюду наследие множественного числа. Выберем таблицу Appointments, нажмём на Edit mapping button, отредактируем имя класса и сохраним изменения нажатием OK.
7. Повторим этот шаг для других сущностей, имеющих множественное число в имени: InvoiceDetails, Invoices и Patients.
8. Также на этом этапе можно указать для сущности её Instance Name — строковое представление сущности (записи), которым она будет представлена в UI, например, в ячейках таблиц или выпадающих списках. Выберем таблицу Product, нажмём Edit mapping, выберем атрибут ProductName в поле Instance name и нажмём OK.
9. Все эти параметры можно будет исправить и позднее, поэтому не страшно, если мы что-то пропустили или где-то ошиблись. Нажимаем Next.
10. Теперь можно автоматически создать CRUD-экраны для сущностей, обеспечивающие доступ к данным. Платформа CUBA предлагает несколько стандартных экранных шаблонов:
- Browser — экран просмотра списка записей из базы, в него по умолчанию входит фильтр данных и поддерживается пагинация;
- Editor — экран просмотра и редактирования отдельной записи;
- Browser and Editor — всего лишь означает, что будут созданы оба экрана;
- Single screen — встраивает редактор в экран браузера, таким образом, слева отображается список всех записей, а справа — детали выбранной записи.
Примечание: Начиная с версии 6.4, платформа поддерживает создание пользовательских шаблонов экранов. Также любой экран можно впоследствии отредактировать в Studio и IDE.
11. Выберем следующие шаблоны и нажмём Next:
На экране скриптов обновления БД никаких скриптов мы не видим. Всё как мы и планировали, исходный таблицы остаются без изменений. Нажмите Save и подождите, пока платформа сгенерирует модель данных и экраны CRUD.
Шаг 4. Первый запуск
Начиная с этого этапа, мы уже можем запустить приложение и посмотреть на свежесозданный стандартный UI.
1. Запустим приложение CUBA командой Run — Start application в основном меню.
2. По ссылке Web client в левом нижнем углу Studio перейдём в приложение, которое откроется в новой вкладке браузера.
3. Логин и пароль по умолчанию — admin/admin, подтверждаем и входим в приложение.
4. Созданные нами экраны доступны из меню Application в верхней части приложения.
5. Откроем экран Products и посмотрим, как он выглядит со стандартной разметкой шаблона single screen.
Конечно, понадобится ещё какое-то время на перенос бизнес-логики и оформление интерфейса, но на этом этапе у нас уже есть первая версия кросс-платформенного приложения, полностью основанная на опен-сорс технологиях.
Дальнейшая разработка
Что делать с приложением дальше, тут у вас есть полная свобода выбора. Платформа CUBA Platform не запрещает изменять генерированный код приложения, равно как и исходный код самой платформы. Вы также можете интегрировать в приложение любые сторонние технологии из мира Java.
К примеру, вы могли заметить, что на стандартном экране просмотра Product не хватает информации о скидках, таблицы похожих продуктов и изображений. С помощью платформы и CUBA Studio можно легко привести экран к тому виду, который он имел в исходном приложении LightSwitch.
Исходники дополненной сущности Product и дескриптора экрана Product можно посмотреть в проекте на GitHub. Хочу отметить, что все изменения в декларации сущности и дескрипторе экрана были созданы в визуальном редакторе CUBA Studio.
Все ручные изменения в коде прописаны в контроллере экрана. Также вы можете посмотреть пример создания вычисляемых атрибутов в исходном коде сущности Product (см. метод Product#getCurrentPrice).
Можно ли запустить приложение без MSSQL?
По умолчанию, наше приложение на GitHub настроено для использования с легковесной HyperSQL Database. Поэтому, просто склонировав его из репозитория, вы можете его запустить, и при старте Studio сама создаст требуемую базу данных. Правда, эта база будет пустой, и вам придётся наполнить её самостоятельно через пользовательский интерфейс приложения.
Если же вы хотите изменить тип используемой БД, в CUBA Studio это реализовано весьма прямолинейно: для миграции на другую DBMS откройте настройки проекта в секции Project Properties и выберите тип базы данных из выпадающего списка. Studio создаст новые скрипты создания и обновления базы данных, и вы сможете запустить приложение с любой выбранной БД.
Резюмируя, если у вас есть необходимость или опыт в модернизации ПО, приглашаем вас оценить инструмент и, возможно, предложить варианты по улучшению механизма миграции. Будем рады получить обратную связи на нашем форуме поддержки.
