У нас уже есть несколько публикаций, посвященных платформе Serena Business Manager (SBM).
» Версия 11.1
» Версия 11.01
Поскольку поступил запрос рассказать подробнее о платформе, среде разработки, примерах решений, я начну с рассказа о поставляемом в составе платформы инструменте для разработки приложений – SBM Composer.
Сразу предупреждаю, что как такового программирования в первых частях не будет – среда разработки визуальная и позволяет разработать полностью функциональное приложение, что называется, «без единой строчки кода».
SBM Composer устанавливается и работает на ОС Windows. C сервером версий приложений общение происходит по протоколу HTTP(S), развертывание приложения в среду выполнения (deploy) происходит в один клик. Также доступен удобный импорт/экспорт приложения через файлы, сравнение версий, валидация приложения на предмет ошибок и т.д.
Центральным модулем среды является, конечно, дизайнер моделей процессов, который позволяет моделировать процесс (или несколько) жизненного цикла информационного объекта (workflow). Интерфейс напоминает таковой у MS Visio – на холст набрасываются возможные состояния объекта и переходы между ними, swimlane и т.д.
Разница «только» в том, что за картинкой диаграммы процесса скрывается рабочая модель web приложения, которую умеет исполнять сервер приложений SBM, предоставляя пользователям возможность создавать новые информационные объекты, изменять их и «двигать» по заданному процессу.
Дизайнер процессов удобно связан с остальными модулями среды. Разработчик может прямо с модели переопределить настройки поля в модели данных, выбрать форму, которую необходимо показать пользователю на том или ином переходе/состоянии, добавить различные действия бизнес-логики в контекст перехода или состояния (запуск скриптов, orchestration workflow) и т.д.
В свойствах состояний и переходов модели workflow можно определять Действия (Actions), которые сервер приложений должен исполнить до/после перехода или до входа/на выходе из состояния. В списке возможных действий — вызов скрипта, вызов web-службы, вызов сценария orchestration, вызов определенного перехода у связанных с текущим объектом записей. Действия можно запускать условно или безусловно.
Используется для моделирования структур хранения данных, по сути, структур таблиц в базе данных (в качестве СУБД, кстати, используется либо MS SQL, либо Oracle). Как только вы добавляете новый workflow — автоматически создается primary таблица с набором обязательных атрибутов для хранения информации о новых объектах – «Название», «Номер», «Дата создания» и т.д.
Есть возможность добавлять свои собственные поля из палитры. Поля строго типизированы – доступны как привычные типы (binary, date/time, numeric, text и т.д.), так и специфические для платформы (например, user, single relational, sub-relational и т.д.).
Для каждого поля доступны разного рода настройки – значение по умолчанию, обязательность заполнения, подсказка на пользовательском интерфейсе и т.д.
Разработчик может создать неограниченное количество дополнительных структур данных, справочников (auxiliary table). По сути, это дополнительные таблицы в базе данных, служащие, как правило, для хранения различных списков (например, продуктов или услуг, договоров с клиентами и т.д.) Самое главное отличие auxiliary — здесь хранятся записи, для которых не предусмотрен свой процесс workflow.
И наконец, в этом модуле появляются структуры данных из внешних источников данных, объявленные в XML формате — по сути view на данные, которые нужно использовать в процессе без репликации.
Раздел для создания форм пользовательского интерфейса. Для начала надо отметить, что приложение будет работать и без создания custom-форм. При этом будут использоваться так называемые quick-формы, автоматически построенные системой на основе модели данных, модели процесса и привилегий пользователя. Но современный избалованный пользователь, как правило, требует отнестись к формам пользовательского интерфейса со всей возможной серьезностью.
Composer позволяет создавать формы нескольких типов – это форма просмотра (state form), редактирования (transition form) и печатная форма (print form).
Редактор позволяет расположить атрибуты информационного объекта на холсте формы, использовать дополнительные секции (вкладки), форматировать названия и содержимое полей и т.д. Важно, что допускается создавать свои отдельные формы хоть для каждого состояния, хоть для каждого перехода. Это бывает удобно, когда для конкретного перехода требуется, например, только указать примечание, или назначить исполнителя — форма резко упрощается, остаются только необходимые поля, что ценят конечные пользователи.
Среда разработки имеет режим preview с рендерингом формы.
Более интересные возможности включают в себя:
1. Добавление интерактивности через Actions. Специальный мастер позволяет по определенных событиям (загрузка формы, изменение значения поля и т.д.) выполнять разнообразные действия (скрывать/показывать поля, изменять обязательность заполнения полей, подсвечивать отдельные секции и т.д.).
Всё то же самое, по сути, можно сделать и через JavaScript (см. пункт 2), но Actions сильно упрощают жизнь и решают 80% типовых задач.
2. Подключение и написание JavaScript-кода. jQuery доступен по умолчанию, любые нужные вам плагины вы можете подключить и использовать на форме.
Доступна библиотека функций для взаимодействия с формой (те самые скрытия полей/секций, обязательность и т.д. – для всех этих действий есть готовые javascript-функции).
3. Встроенные отчеты. Любые отчеты SBM от простейших списков до панелей информационных показателей. Самый широко применяемый нами тип виджета на формах. Например, так можно легко добавить на форму список записей связанных с текущим объектом. (например, отобразить список включенных в релиз фич, что-там у клиента прописано в договоре, какие еще инциденты происходили с данным оборудованием и т.д.).
4. Также доступны еще несколько интересных виджетов (REST Grid widget, PDF widget), секция для фиксации затраченного времени (Time Capture) и т.д.
Самый скучный раздел. Здесь осуществляется настройка прав и привилегий ролей пользователей нашего приложения.
Роль — это контейнер привилегий, причем привилегии настраиваются достаточно гибко. Например, можно создать роль «Разработчик», разрешив ей работать только со своими объектами, но видеть при этом все остальные, разрешить запуск отчетов, но запретить создавать свои и т.д., видеть одни поля, редактировать другие.
Наиболее интересный, с точки зрения разработки, раздел. В основном сюда заходят, чтобы сделать две вещи:
1. Написать какой-нибудь скрипт, исполняющийся на сервере. Скрипты пишутся на языке VBScript с расширением в виде встроенной библиотеки для взаимодействия с платформой (всяческие создание, изменения, удаления объектов, чтение данных и т.д.). Скрипт может быть исполнен в контексте перехода, запущен сервером уведомлений по какому-то событию или вызван через URL.
Типовые сценарии для использования скриптов это, например, валидация введенных данных, генерация имени объекта, расчет стоимости и т.д.
2. Написать orchestration. На хабре уже есть статья на эту тему. Если кратко, то через специальный дизайнер процесса можно вызывать SOAP или REST веб-службы, обрабатывать полученные данные, выполнять различные действия с объектами платформы и т.д.
Типовые сценарии – интеграция с внешними системами (в т.ч. с другими системами Serena, например, Serena Deployment Automation), получение и обработка данных из внешних источников и т.д.
Самый маленький раздел, но очень важный. Здесь разработчик может объявить внешние приложения, структуры данных и процессы которых он собирается использовать. Например, если уже есть решение по управлению поручениями, то здесь его можно объявить, а потом определить в новой модели процесса переход создания поручений в качестве зависимых подзадач или просто параллельных потоков исполнения. Или брать данные из объявленных здесь справочников.
Теперь, когда назначение каждого из разделов среды разработки должно быть понятно, я постараюсь на примерах конкретных прикладных задач подробнее раскрыть возможности платформы автоматизации бизнес-процессов SBM.
» Версия 11.1
» Версия 11.01
Поскольку поступил запрос рассказать подробнее о платформе, среде разработки, примерах решений, я начну с рассказа о поставляемом в составе платформы инструменте для разработки приложений – SBM Composer.
Сразу предупреждаю, что как такового программирования в первых частях не будет – среда разработки визуальная и позволяет разработать полностью функциональное приложение, что называется, «без единой строчки кода».
Общий обзор возможностей
SBM Composer устанавливается и работает на ОС Windows. C сервером версий приложений общение происходит по протоколу HTTP(S), развертывание приложения в среду выполнения (deploy) происходит в один клик. Также доступен удобный импорт/экспорт приложения через файлы, сравнение версий, валидация приложения на предмет ошибок и т.д.
Основные разделы
Workflow design
Центральным модулем среды является, конечно, дизайнер моделей процессов, который позволяет моделировать процесс (или несколько) жизненного цикла информационного объекта (workflow). Интерфейс напоминает таковой у MS Visio – на холст набрасываются возможные состояния объекта и переходы между ними, swimlane и т.д.
Разница «только» в том, что за картинкой диаграммы процесса скрывается рабочая модель web приложения, которую умеет исполнять сервер приложений SBM, предоставляя пользователям возможность создавать новые информационные объекты, изменять их и «двигать» по заданному процессу.
Дизайнер процессов удобно связан с остальными модулями среды. Разработчик может прямо с модели переопределить настройки поля в модели данных, выбрать форму, которую необходимо показать пользователю на том или ином переходе/состоянии, добавить различные действия бизнес-логики в контекст перехода или состояния (запуск скриптов, orchestration workflow) и т.д.
В свойствах состояний и переходов модели workflow можно определять Действия (Actions), которые сервер приложений должен исполнить до/после перехода или до входа/на выходе из состояния. В списке возможных действий — вызов скрипта, вызов web-службы, вызов сценария orchestration, вызов определенного перехода у связанных с текущим объектом записей. Действия можно запускать условно или безусловно.
Data design
Используется для моделирования структур хранения данных, по сути, структур таблиц в базе данных (в качестве СУБД, кстати, используется либо MS SQL, либо Oracle). Как только вы добавляете новый workflow — автоматически создается primary таблица с набором обязательных атрибутов для хранения информации о новых объектах – «Название», «Номер», «Дата создания» и т.д.
Есть возможность добавлять свои собственные поля из палитры. Поля строго типизированы – доступны как привычные типы (binary, date/time, numeric, text и т.д.), так и специфические для платформы (например, user, single relational, sub-relational и т.д.).
Для каждого поля доступны разного рода настройки – значение по умолчанию, обязательность заполнения, подсказка на пользовательском интерфейсе и т.д.
Разработчик может создать неограниченное количество дополнительных структур данных, справочников (auxiliary table). По сути, это дополнительные таблицы в базе данных, служащие, как правило, для хранения различных списков (например, продуктов или услуг, договоров с клиентами и т.д.) Самое главное отличие auxiliary — здесь хранятся записи, для которых не предусмотрен свой процесс workflow.
И наконец, в этом модуле появляются структуры данных из внешних источников данных, объявленные в XML формате — по сути view на данные, которые нужно использовать в процессе без репликации.
Visual design
Раздел для создания форм пользовательского интерфейса. Для начала надо отметить, что приложение будет работать и без создания custom-форм. При этом будут использоваться так называемые quick-формы, автоматически построенные системой на основе модели данных, модели процесса и привилегий пользователя. Но современный избалованный пользователь, как правило, требует отнестись к формам пользовательского интерфейса со всей возможной серьезностью.
Composer позволяет создавать формы нескольких типов – это форма просмотра (state form), редактирования (transition form) и печатная форма (print form).
Редактор позволяет расположить атрибуты информационного объекта на холсте формы, использовать дополнительные секции (вкладки), форматировать названия и содержимое полей и т.д. Важно, что допускается создавать свои отдельные формы хоть для каждого состояния, хоть для каждого перехода. Это бывает удобно, когда для конкретного перехода требуется, например, только указать примечание, или назначить исполнителя — форма резко упрощается, остаются только необходимые поля, что ценят конечные пользователи.
Среда разработки имеет режим preview с рендерингом формы.
Более интересные возможности включают в себя:
1. Добавление интерактивности через Actions. Специальный мастер позволяет по определенных событиям (загрузка формы, изменение значения поля и т.д.) выполнять разнообразные действия (скрывать/показывать поля, изменять обязательность заполнения полей, подсвечивать отдельные секции и т.д.).
Всё то же самое, по сути, можно сделать и через JavaScript (см. пункт 2), но Actions сильно упрощают жизнь и решают 80% типовых задач.
2. Подключение и написание JavaScript-кода. jQuery доступен по умолчанию, любые нужные вам плагины вы можете подключить и использовать на форме.
Доступна библиотека функций для взаимодействия с формой (те самые скрытия полей/секций, обязательность и т.д. – для всех этих действий есть готовые javascript-функции).
3. Встроенные отчеты. Любые отчеты SBM от простейших списков до панелей информационных показателей. Самый широко применяемый нами тип виджета на формах. Например, так можно легко добавить на форму список записей связанных с текущим объектом. (например, отобразить список включенных в релиз фич, что-там у клиента прописано в договоре, какие еще инциденты происходили с данным оборудованием и т.д.).
4. Также доступны еще несколько интересных виджетов (REST Grid widget, PDF widget), секция для фиксации затраченного времени (Time Capture) и т.д.
Security
Самый скучный раздел. Здесь осуществляется настройка прав и привилегий ролей пользователей нашего приложения.
Роль — это контейнер привилегий, причем привилегии настраиваются достаточно гибко. Например, можно создать роль «Разработчик», разрешив ей работать только со своими объектами, но видеть при этом все остальные, разрешить запуск отчетов, но запретить создавать свои и т.д., видеть одни поля, редактировать другие.
Extensions
Наиболее интересный, с точки зрения разработки, раздел. В основном сюда заходят, чтобы сделать две вещи:
1. Написать какой-нибудь скрипт, исполняющийся на сервере. Скрипты пишутся на языке VBScript с расширением в виде встроенной библиотеки для взаимодействия с платформой (всяческие создание, изменения, удаления объектов, чтение данных и т.д.). Скрипт может быть исполнен в контексте перехода, запущен сервером уведомлений по какому-то событию или вызван через URL.
Типовые сценарии для использования скриптов это, например, валидация введенных данных, генерация имени объекта, расчет стоимости и т.д.
2. Написать orchestration. На хабре уже есть статья на эту тему. Если кратко, то через специальный дизайнер процесса можно вызывать SOAP или REST веб-службы, обрабатывать полученные данные, выполнять различные действия с объектами платформы и т.д.
Типовые сценарии – интеграция с внешними системами (в т.ч. с другими системами Serena, например, Serena Deployment Automation), получение и обработка данных из внешних источников и т.д.
References
Самый маленький раздел, но очень важный. Здесь разработчик может объявить внешние приложения, структуры данных и процессы которых он собирается использовать. Например, если уже есть решение по управлению поручениями, то здесь его можно объявить, а потом определить в новой модели процесса переход создания поручений в качестве зависимых подзадач или просто параллельных потоков исполнения. Или брать данные из объявленных здесь справочников.
Теперь, когда назначение каждого из разделов среды разработки должно быть понятно, я постараюсь на примерах конкретных прикладных задач подробнее раскрыть возможности платформы автоматизации бизнес-процессов SBM.