Инструкция bizagi process modeler

03.07.2014 Любомира 5 комментариев

У нас вы можете скачать книгу инструкция bizagi process modeler в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

А вот тип будет ссылка на справочник. И New Entity потому что такого справочника пока что нет. Имя этой сущности TipMash. Так же нужно указать атрибуты этой сущности 1 атрибут, Тип машины тип String. На рисунке видно, что начинает выстраиваться Er — диаграмма. Видно, что заявка имеет ссылочный атрибут Тип машины , который ссылается на сущность и там есть один атрибут Тип машины.

Кликнув правой кнопкой мыши выбирать Values , нажать на кнопку Тип машины в низу окна, появляется 1 значение. Есть кнопка добавить , и нет кнопки удалить. Единственное, что можно сделать, пометить как не используемые Disabled. Это сделано что бы гарантировать ссылочную целостность, чтобы удаление какого-то значения не исказило данные уже имеющиеся. На вводе заявки появится возможность выбора тип автомобиля. Атрибут был добавлен в общий блок, соответственно необходимость в редактировании остальных форм отпадает.

Выбор из справочника очень распространенный сценарий. Второй не менее распространенный сценарий это заявка, в которой есть многострочная часть. Примером будет список затрат. Необходимо чтобы у него была возможность составить авансовый отчет. Где он может указать, сколько он потратил на бензин, замену колеса и т. Перейти к моделированию данных. Edit Attribute List , и создать атрибут под названием затраты.

Но тип у этого атрибута будет необычный, Collection. Здесь связь будет не N к одному, а N к , т. Master , потому что это не справочник а фактические данные, New Entity. Создать сущность под названием Zatrati. Типы затрат имя TipiZatrat , значения в поле Name должны отличатся.

Это будет справочник, Так же как и в предыдущей сущности. Имя атрибута справочника Типа затрат TpZatrat. Заявка ссылается на множество записей затрат, те в свою очередь на справочник типов затрат. Открыть форму, и вставить атрибут затраты на форму. Там появится таблица затрат, где можно добавлять и удалять строки.

Далее необходимо разрешить удаление. Выделить табличку и в свойстве Allow Delete ставим True. Для улучшения внешнего вида сделать следующее:. Заполнить все формы, переходя от шага к шагу. Но как видно справочник Тип затрат пустой. Можно вернутся к разработке и там его наполнить, так же портал даёт возможность администрирования, позволяя наполнять справочники нужными данными, не выходя из портала.

Нажfnm на кнопку Добавить Тип затрат. Ввести необходимые данные и нажать на кнопку сохранить были созданы следующие типы затрат ГСМ, Сервис, Прочее. Далее перейти в исполняющиеся процессы, найти там запущенный процесс нажать на Выполнить рейс.

Так же создать список затрат. Для дальнейшего усовершенствования процесса нужно добавить 3 атрибута: Заказчик, Номер заказа и Дата заказа. Таким образом Будут указаны данные зарегистрированного пользователя.

Найти сущность Заказчик , раскрыть и перенести атрибут fullName форму. Поменять имя атрибута на Заказчик Display Name. Так же нужно перенести атрибуты Номер заказа и Дата заказа. Лучше запретить редактирование этих атрибутов. Если не сделать атрибут Заказчик не редактируемым то будет ошибка, и не удастся сохранить форму. Перейти в раздел Business Rules , нажать на Activity Action. Прямо на входе в первой задаче вычислить эти действия.

Кликнуть на задачу Ввести заявку , появится окно Bizagi Dialog , выбираем On Enter , нажать на в нижнем левом углу окна, там выбрать Expression. Появится новое окно, ввести имя в поле Name Compute.

Далее правой кнопкой на стрелке и выбрать Add Expression. Два раза кликнуть по появившейся иконке появится окно редактирования Edit Expression. Для кодирования в Bizagi используется Visual J Sharp к которому добавлены некие способы адресации к полям. Потребуются атрибуты Заказчик, Номер заказ и Дата заказа. Также потребуются функция Me. Есть описание на сайте Bizagi ссылка на описание этой функции http: При синтаксических ошибках появляются сообщения.

Видно, что появились созданные атрибуты Заказчик, Номер заказа и Дата заказа. Но отличие в том что эти атрибуты заполняются сами.

Нужно перейти в Define Forms и перекинуть туда этот атрибут. Далее кликнуть на задаче Выполнить рейс. Отчет будет строится после действия Сохранить. С тем же самым названием.

Далее Dispay Name - Авансовый отчет. Далее указать созданный специальный атрибут Авансовый отчет. А вместо номера укать из атрибута, нажатием на Xpath Field , там показаны атрибуты, выбирать Номер заказа.

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

Это достаточно примитивный документ. Но легок в реализации. Самый примитивный анализ во вкладке Исполняющиеся. Здесь представлены все исполняющиеся процессы. Так же имеется возможность посмотреть на динамику процесса, увидеть все переходы. Для этого нужно нажать на кнопке просмотр. Здесь можно запустить имитацию, которая покажет как происходил переход задач в данном процессе.

Это можно сделать нажав на кнопку. Так же в этом окне присутствует кнопка , нажатие которой показываются задачи на которых остановился процесс. Если необходимо посмотреть на картину целом, то не обойтись без раздела Анализ , который включает 5 пунктов. Мониторинг это экземпляры процессов которые ещё исполняются а Аналитика — экземпляры процессов, которые уже завершены. График показывает число активных процессов, имеющих запас по времени зеленый столбец , находящихся в зоне риска срок которых истекает сегодня, желтый столбец и просроченных красный столбец.

При клике на один из столбцов будут показаны подробности данные всех процессов отнесенных в эту группу. График показывает процент процессов с запасом по времени, в зоне риска срок которых истекает сегодня и просроченных. Подробности по клику на диаграмме. Процессы с истекающим сроком: График показывает когда открытые процессы окажутся просрочены. График показывает процент заданий с запасом по времени, в зоне риска срок которых истекает сегодня и просроченных. Задачи с истекающим сроком: График показывает когда открытые задания окажутся просрочены.

Процессы, закрытые в срок и с превышением. График показывает сколько дней заняло выполнение завершившихся процессов. Вертикальный пунктир отделяет завершенные вовремя процессы от просроченных. График можно построить только если процесс выполнялся более 1 дня. Показывает сколько за какой-то промежуток времени процессов появилось и сколько завершилось. Процессы запущенные, завершенные и прерванные в выбранном интервале времени.

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

Без модуля Engine вы не сможете полноценно работать в системе и исполнять прописанные бизнес-процессы. Как работает Bizagi Что мы делаем в Bizagi, если нам необходимо автоматизировать какой-либо бизнес-процесс? Рассмотрим алгоритм действий на примере согласования заявки на расход денежных средств. В статье про BPM-системы мы видели, как этот бизнес-процесс был реализован на реальном проекте посредством учетной системы, сейчас мы посмотрим, как это правильно организовать в системе BPM.

Моделирование Моделирование бизнес-процесса происходит путем перетаскивания графических элементов, предложенных в Bizagi, в рабочую зону. Выше я писал, что интерфейс Studio, представлен на английском языке, но в самой карте бизнес-процесса мы можем использовать русский язык.

Мы моделируем схему бизнес-процесса Payment Request: Задача заключается в контроле оплаты счетов. Последовательность действий данного бизнес-процесса выглядит так: Сотрудник, которому поступает счет на оплату, должен создать запрос на оплату. Руководитель должен проверить запрос и выбрать один из вариантов действия: При первом варианте Сотрудник получает уведомление об отказе руководителя. На этом бизнес-процесс заканчивается. Во втором случае Руководитель должен Распечатать, подписать запрос и отправить его в бухгалтерию, на этом бизнес-процесс заканчивается.

Графическая карта бизнес-процесса выглядит так: Разработка структуры данных После того, как бизнес-процесс смоделирован, мы приступаем к разработке структуры данных. На данном этапе мы прописываем, в каких формах, каких полях хранятся те или иные данные и указываем их связи. В нашем примере мы должны разработать три сущности Entity: Запрос на оплату счета; Контрагент поставщик, которому необходимо оплатить счет ; Причина отказа.

Для каждой из этих сущностей необходимо прописать атрибуты поля , которые будут доступны для заполнения. Предустановленные их очень много — атрибуты, которые предлагает сама система; Пользовательские — те, которые пользователь создает вручную. На скриншоте видно, какие атрибуты прописаны для каждой сущности. Также необходимо указать связи между этими сущностями. Мы прописываем, что сущности Причины отказа и Контрагенты входят в сущность Запрос на оплату счета. Создание форм пользовательского интерфейса После того, как мы разработали структуру данных, нам необходимо решить, как пользователь заходит в систему, как взаимодействует с ней.

И вот здесь нам необходимо создать пользовательский интерфейс. Когда мы смоделировали бизнес-процесс, мы входим в него и видим, что каждый из этих квадратиков на схеме, обозначающих этапы, — это форма, которую необходимо разработать. Форма — это то, с чем впоследствии будет работать пользователь. Хочу обратить ваше внимание на то, что разрабатываются только те формы, над которыми работает пользователь.

Если какой-то из этапов предполагает автоматическое действие например, оповещение Сотрудника об отказе в оплате , для него форму разрабатывать не нужно.

В нашем примере необходимо разработать 3 формы: Создания запроса на оплату; Проверка запроса на оплату; Формирования печатной формы. Эти формы используют одни и те же данные. Основа в каждой из этих форм одна — запрос на оплату счета. Но каждая следующая форма имеет более расширенный функционал, чем предыдущая. А следующая форма имеет по сравнению с предыдущей еще и возможность печати запроса. При необходимости ненужные поля из предыдущих форм можно скрыть. Здесь важно понимать, что это все-таки не одна, а три разных формы.

И каждая из них создается заново либо копируется с предыдущей формы, после чего в нее вносятся необходимые изменения. Теперь рассмотрим сам процесс создания формы например, Создания запроса на оплату. Форма создается посредством выбора и перетаскивания в активное окно необходимых полей.

Для выбора предлагаются поля атрибуты , которые мы назначили конкретным формам на предыдущем этапе. Форма создания запроса в итоге будет выглядеть так: Здесь мы видим поля: Срок оплаты; Сумма счета; Номер счета; Контрагент; Присоединенный файл возможно прикрепить счет на оплату.

Также для более удобного использования форм можно воспользоваться Layot варианты расположения частей формы. Макет формы можно разделить: На этапе создания форм можно настроить видимость полей и функции редактирования для разных пользователей.

Например, у следующего этапа Проверки запроса есть своя форма, в которой руководителю видны поля, созданные сотрудником на предыдущем этапе, но руководитель эти поля редактировать не может. Зато ему доступны собственные поля, которые не видны сотруднику: Поле Причина отказа становится видным для руководителя, только если в поле Одобрено он выбрал вариант No. То есть видимость полей можно настроить не только в формате Видно-Не видно, но и в зависимости от каких либо условий.

Это условие выглядит так PaymentRequestApproved is equal to false Если Руководитель установил вариант Yes, становится доступной функция распечатать запрос на оплату.

Для него уже никакие функции недоступны, кроме Generate template. Определение бизнес-правил Далее необходимо разработать бизнес-правила, чтобы система автоматически делала некоторые вещи на основании каких-либо данных. В Bizagi предусмотрено три этапа установки бизнес-правил: Define Expressions — предполагает обработку условий Activity Actions Events — предполагает обработку событий Perfomance — предполагает обработку пользователей, работающих на том или ином этапе бизнес-процесса.

Define Expressions На этапе Define Expressions идет определение вариантов поведения системы при тех или иных условиях. В нашем случае это результат проверки запроса, два варианта две стрелки , которые ведут от Результата проверки. При нажатии на стрелку, ведущую к следующему этапу, открывается форма, в которых заполняются условия перехода на тот или иной этап.

Если по результатам проверки руководитель отказывает, то процесс переходит в стадию Оповестить о причине отказа. Если по результатам проверки Руководитель одобрил запрос, процесс переходит на этап Распечатать счет.

Activity Actions На этапе Activity Actions мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях на выбор: Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля: Id Perfomance Следующий шаг — это Perfomance.

Здесь мы прописываем, кто на каком этапе работает с бизнес-процессом, отвечает за его выполнение. На этапе Создания сделки работает сотрудник, создавший эту сделку.

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

Как он будет получать информацию об изменениях по бизнес-процессу, которые требуют его участия? Это настраивается с помощью Notification. Оповещения бывают двух видов: Использовать можно оба вида оповещений одновременно. В нашем бизнес-процессе при смене этапа Одобрен или Не одобрен запрос на оплату , Сотруднику отправляется сообщение о том, что счет одобрен или требует уточнения.