Переход с Flute 1.0 на Flute 2.0
Материал из Course Orchestra
Обновление системы
- Система Flute версии 1 запускала Python-скрипты из папки scripts в установочной директории (что, кстати говоря, создавало проблемы: каждое изменение текста скрипта требовало разрешений системного администратора, т. к. скрипты находились в Program Files). Основным отличием версии 2 от версии 1 является полный переход на механизм Celesta для запуска Python-скриптов. Новая версия использует инфраструктуру Celesta и требует, чтобы запускаемые скрипты являлись при этом Celesta-процедурами. Установщик Флейты теперь на одном из этапов запрашивает путь к Celesta Score. Таким образом, при переходе к версии 2.0 обратная совместимость потеряна, однако апгрейд всех имеющихся процедур на новую версию нетрудно выполнить при помощи формальных преобразований скриптов и помещения их в какую-либо гранулу.
- Смело ставьте Flute 2 на машину с Flute 1. Инсталлятор Flute 2 не перезаписывает Flute 1, а размещает программные файлы в отдельной директории (Program Files\KURS\Flute2 вместо Program Files\KURS\Flute) и создаёт сервис с другим именем (Flute2 вместо Flute1).
- Возможность работы на «чужой» базе данных без вмешательства в её структуру сохраняется. Flute 2, хотя и широко использует Celesta, для чтения и модификации данных в таблице задач использует не механизм Celesta, а свой собственный механизм. Это значит, что разворачивание системных таблиц Celesta в базе данных, к которой подключена Flute, для самой Flute не требуется, и по-прежнему возможно использование Флейты с базами данных сторонних приложений (например, ERP-системы Navision). Чтобы запретить Celesta создавать собственную структуру таблиц в базе данных, можно использовать параметр skip.dbupdate в файле flute.properties. Естественно, отказываясь от разворачивания системных таблиц Celesta в базе данных, вы лишаетесь возможности использования Celesta API для доступа к данным, но в очень многих случаях прямой доступ к данным из скрипта Flute и не нужен.
- Хотя формат параметров в flute.properties поменялся и вместо database.classname/database.connection теперь, для совместимости с ShowCase, используется rdbms.connection.url/rdbms.connection.username/rdbms.connection.password, старая настройка будет работать.
- Для выполнения апгрейда существующих скриптов в папке scripts следует выполнить следующие действия:
- Перенести скрипт из папки Program Files\KURS\Flute\scripts в какую-либо гранулу (например, в создаваемую по умолчанию при установке Flute 2 гранулу flute в папке C:\score\flute).
- Оформить исполняемую часть скрипта в виде процедуры (допустим, с именем run), принимающей два параметра: context и params.
- Обновить код, вставлявший записи в таблицу задач таким образом, чтобы в поле script вставлялась правильная ссылка на процедуру. К примеру, если скрипт ранее называлася makereport.py, его содержимое было обёрнуто в процедуру run, а сам он помещён в гранулу flute, то вместо makereport.py в поле script необходимо записывать: flute.makereport.run.
- Заменить системные переменные, использовавшиеся в скриптах Flute 1, по следующей таблице соответствий:
Параметр во Flute1 | Параметр во Flute2 | Примечание |
---|---|---|
taskid | params.taskid | |
params | params.params | |
conn | context.conn | Если скрипт использовался для модификации данных, желательно переписать его с использованием Celesta API для доступа к данным. Однако на первых порах можно использовать атрибут conn объекта context для прямого доступа к JDBC-соединению. |
resultstream | params.resultstream | |
message | params.message | |
процедура repair(conn) | — | Во Flute 2 не реализовано, так как все соединения с базой данных работают в транзакции. Если допустить, что по ходу исполнения скрипта связь "отваливается", то это будет означать откат транзакции и сброс результатов работы скрипта до момента "отваливания" связи. |