Руководство Бизнес-аналитика

Page tree

Руководство Бизнес-аналитика. Платформа Web-BPM 2.0

Skip to end of metadata
Go to start of metadata

Общая концепция программной платформы WEB-BPM

Платформа WEBBPM основана на взаимодействии и одновременной работе в связке трёх разных крупных программных комплексов:

  1. Программный комплекс Студия как инструмент разработки бизнес-процессов и экранных форм пользовательского интерфейса. Результат работы - сборка всех исходных файлов проекта в единый файл - дистрибутив приложения.
  2. Программный комплекс Web сервер WildFly, используемый в качестве "проигрывателя" дистрибутива приложения, собранного с помощью Студии. Он специальным образом преобразует файл дистрибутива в исполняемые модули и обеспечивает доступ пользователей к приложению по протоколу http через любой браузер.
  3. Программный комплекс Проект, который на старте содержит в себе минимальный набор файлов и библиотек, необходимый для запуска пустого приложения и начала работ по созданию  пользовательского приложения. Именно на его основе аналитик с использованием Студии, создает приложение в соответствии с требованиями Заказчика.

Студия предоставляется аналитику как ссылка на скачивание архива, подлежащего распаковыванию. Запуск осуществляется файлом app.bat в корне распакованной папки Студии.

Web-сервер WildFly также  предоставляется аналитику как ссылка на скачивание архива, подлежащего распаковыванию. Но он  запускается в нужный момент Студией автоматически после сборки дистрибутива приложения из файлов Проекта.

Проект на рабочем месте аналитика появляется как заранее специальным образом подготовленная техническим специалистом, иерархически  организованная совокупность папок и файлов. Может предоставляться архивом, подлежащим распаковке, а может быть результатом клонирования (скачивания) репозитория с использованием системы управления версиями Git. Открывается из меню Студии указанием на корневую папку Проекта, а не на конкретный файл.

Важно учитывать, что имена любых папок, которые задействованы в создании приложения (папка с Проектом, папка со Студией, папка с Сервером WildFly и их поддиректории) предпочтительно должны содержать только латинские буквы, без специальных, служебных и просто необычных символов (то есть знаков восклицания, пробелов, подчеркиваний, тире и т.п.).

Программная платформа WEB-BPM

Студия представляет собой прозрачное для пользователя соединение в рамках единой информационной среды нескольких программных инструментов, которые позволяют аналитику:

  1.  Спроектировать (нарисовать) бизнес-процесс (схему прохождения маркера процесса) от инициализации процесса до его завершения. Это происходит в окне Редактора бизнес-процессов.
  2.  Разработать экранные интерфейсы и связать их с соответствующими пользовательскими задачами  (UserTasks) из бизнес-процесса. Это происходит в окне Редактора Экранных Интерфейсов.
  3.  Использовать визуальный  конструктор связей и соединений артефактов базы данных (таблиц, представлений) вместо ручного составления запросов. Это происходит при настройке источника данных для экранных форм в окне Редактора Экранных Интерфейсов.
  4.  Осуществлять сборку и локальный запуск на рабочем месте аналитика полноценного web-приложения в один клик, с возможностью горячего обновления при внесении изменений в Проект

Визуально проектируя процесс в Редакторе бизнес-процессов, аналитик создает только структурированное описание (шаблон) в виде простого XML-файла, на основании которого в работающем приложении по инициативе пользователя будут создаваться физические  экземпляры процессов в виде записей в специальной базе данных jbpmn  с колонками - параметрами запуска и прохождения конкретного экземпляра от начала процесса до его завершения. Если из одного и того же шаблона процесса будет запущено несколько экземпляров работающих процессов, то каждый их них будет отдельно существовать  до тех пор, пока не будет завершен либо штатно (достигнув узла "Завершение процесса"), либо принудительно извне.

Таким образом, при разработке приложения на платформе WEB-BPM следует учитывать, что собранное и запущенное приложение  одновременно работает с набором из 4 разных информационных ресурсов, физически представляющих из себя разные базы данных (или разные схемы в базах данных):

  1. Пользовательская база данных, которая обрабатывает пользовательские данные в предметной области приложения.
  2. База данных экземпляров процессов, запущенных пользователями в работающем приложении.
  3. База данных безопасности, в которой обрабатываются учетные данные пользователей (логины, пароли, роли, группы и т.д.), может быть представлена отдельной схемой с ограниченными правами доступа в составе пользовательской базы данных.
  4. База данных адресных классификаторов ФИАС и других прикладных БД по требованию Заказчика.

Создание и обслуживание экземпляров упомянутых баз данных осуществляется техническими специалистами и не входит в компетенцию аналитика - разработчика приложения. Настройка и логическое связывание этих баз данных происходит при инициализации стартового Проекта техническим специалистом (не аналитиком) в специальном конфигурационном файле настроек, который для каждого Проекта уникален. Он называется standalone.xml. Обычно распространяется вместе с папкой Проекта (<имя папки с проектом>\config\dev\) и подлежит копированию в предусмотренную для него поддиректорию <папка web сервера WildFly>\standalone\configuration\.

Так же как и процессы в Редакторе бизнес-процессов, экранные формы, создаваемые в Редакторе  Экранных Интерфейсов на этапе разработки, тоже представляют собой структурированные XML файлы, располагающиеся в файловой системе компьютера аналитика в поддиректориях папки Проекта. Из этого следует, что зачастую поиск по ключевым словам по процессам и экранным формам можно производить в любой внешней программе -  файловом менеджере (типа Sublime, TotalCommander) -  как по простым текстовым файлам. 

Процесс разработки  экранной формы в Редакторе  Экранных Интерфейсов по своему внутреннему содержанию очень похож на процесс блочного строительства домов, когда из готовых блоков создается уникальная конструкция по желанию заказчика. Готовые блоки в этом случае - это заранее разработанные и объединенные в библиотеку Студии так называемые  Визуальные Компоненты (кнопки, поля ввода, таблицы, фильтры  и т.п.), которыми остается вдумчиво и осознанно наполнить универсальный фундамент web-страницы.

Для того, чтобы на любой экранной форме собранного и запущенного приложения отобразились необходимые данные, поля, кнопки и т.п., приложение должно обратиться к пользовательской базе данных, получая или отдавая структурированную информацию (тестовую, цифровую, логическую и т.п.). Чтобы такое обращение было правильно исполнено, а информация от базы данных получена, необходимо на этапе разработки экранной формы предусмотреть и сконфигурировать источник данных в виде корректного SQL- запроса. Для этого почти в каждом Визуальном Компоненте предусмотрены свойство или параметр, отвечающий за создание и настройку такого запроса в виде визуального конструктора, в котором из вкладки со всеми имеющимися в базе данных таблицами на рабочее поле переносятся только нужные, и с использованием мыши рисуются стрелками связи между этими таблицами. В дальнейшем Студия сама генерирует корректный SQL-код на основе такой картинки. Подробнее о существующих компонентах, порядке их настройки и использовании рассказывается в разделе Базовая библиотека компонент данного руководства. Там же приведены часто встречающиеся в практике примеры их использования. 

Существует разница между сборкой и запуском проекта на рабочем месте аналитика-разработчика информационной системы и сборкой и запуском проекта на продуктовом стенде. Однако эта разница важна и учитывается только руководителями проекта, и никак не влияет на работу рядового аналитика при текущей разработке. Сборка и запуск приложения из исходных файлов Проекта на рабочем месте аналитика осуществляется непосредственно из главного меню Студии. После сборки дистрибутива Студия автоматически перенаправляет собранный дистрибутив "Web серверу WildFly", побуждая  его к запуску переданного дистрибутива. Чтобы такая совместная согласованная работа Студии и сервера  была возможна,  Студия  и Web сервер WildFly должны знать о расположении друг друга на рабочем компьютере аналитика. Источником такой информации является файл appserver.xml, который должен располагаться в пути <профиль пользователя в windows>\.webbpm-studio\appserver.xml. Первоначально этот файл также предоставляется техническим специалистом.

Рекомендуемым браузером для взаимодействия с запущенным приложением является  FireFox, но допустимыми считаются актуальные версии всех известных браузеров.

Подсистема журналирования (записи логов)

После того, как приложение собрано из файлов проекта и локально запущено на рабочем компьютере аналитика, оно начинает логировать (пошагово записывать в журнал) все действия и события, которые в этом приложении происходят (включая запросы к базе данных).  Степень детализации ведения журналов задается в ранее упомянутом файле настроек standalone.xml, но по умолчанию для режима разработки сразу включен максимальный уровень детализации. Это означает, что по логам можно отследить момент появления ошибки, место ее возникновения и причину для того, чтобы исправить ситуацию. После исправления не обязательно полностью останавливать приложение и заново запускать - Студия умеет догружать исправления в ранее полностью запущенную систему, обновляя ее до последнего актуального состояния. Лог пишется в файл server.log, который располагается в поддиректории <папка web-сервера>\standalone\log.

Существует еще одна система логирования тех событий и действий Студии, которые происходят до запуска приложения и до начала формирования журнала server.log.  Содержание этого "предварительного" журнала играет важную роль для технического специалиста для диагностирования точек отказа непосредственно Студии. Поэтому об этом логе аналитику нужно знать только то, что он существует и находится в пути <профиль пользователя в windows>\.webbpm-studio.log. В случае запроса технического специалиста на предоставление этого лога его следует просто скопировать и отправить по указанному адресатом каналу связи.

Подсистема управления версиями и поддержки совместной работы

Как уже было отмечено, Проект в целом представляет из себя совокупность большого количества файлов текстового формата. Когда над проектом работают несколько аналитиков одновременно, то обязательно возникнут ситуации, когда в один и тот же файл одновременно будут внесены разные изменения разными аналитиками. Для правильного управления такими ситуациями при разработке приложения примером "лучших практик" является использование системы управления версиями  и поддержки совместной работы, основанной на автоматическом определении и  разрешении конфликтов совместных правок. Для быстрой и беспроблемной совместной разработки большого приложения в коллективе аналитиков необходимо самостоятельно овладеть основными навыками работы с этой системой управления версиями. Основные элементы этой  функциональности доступны аналитику из главного меню Студии

  • No labels