Skip to content

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

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

Тип определяет, какого рода данные будут храниться в атрибуте. Кроме стандартных String , Date Time , Boolean , здесь можно указать и более сложный тип или создать новый. Необходимо обратить внимание, что сейчас все шаги процесса выполняются людьми. Пользователь компьютера получает задачу и каждой этой задачи должна быть определена экранная форма.

На рисунке 6 Показана схема и желтым восклицательным знаком показаны задачи, для которых эта форма не определена. Далее нужно кликнуть на задачу и определить эту форму. Справа на форме, кликнуть по атрибуту Время подачи, найти в самом низу пункт Convert to далее Date - Time далее Date - Time. Для ускорения процесса можно нажать на кнопку Copy From и позаимствовать дизайн с уже имеющегося шага, выбрать образец и нажать Ок и дизайн скопируется.

Это не очень удобно т. Поэтому рекомендуемый способ немного другой:. Некое визуальное представление для этой сущности. Кликнуть правой кнопкой и далее New Form. Уже известным образом перекинуть из модели данных нужные атрибуты. Так же нужно задать имя Zakaz поле Display Name и время. После закрытия появляется форма, ассоциированная с этой сущностью. Теперь её необходимо вставить вместо атрибутов, которые были уже вставлены ранее. Таким образом, форма представляет единое целое.

Нужно вернувшись к предыдущей форме. Для этого кликнуть правой кнопкой мыши и на форме и выбрать пункт Editable и выбрать False. Можно выйти, и вернутся к шагу моделирования данных, и добавить там нужный атрибут.

Но можно сделать это проще: Далее Next и отобразится список атрибутов. Тип данных у этих атрибутов должен быть Boolean. Можно поменять вид атрибута на Checkbox. Так же лучше сделать по умолчанию Одобрено для этого нужно в Properties найти Default Value и указать True.

Так же можно украсить форму, добавив на неё визуальные элементы, отделить визуально Заявку и Решение. Компонент Adds a group. Единственное отличие в группе Решение: Здесь в группе решение нужно вместо атрибута вставить статичный текст , извещающий о том, что машина не выделена. Для этого используется компонент Adds a Label. Последнее что необходимо сделать для того чтобы нажать кнопку Run и запустить процесс это определить условия перехода. Если вспомнить, то, были нарисованы стрелки, но не было указанно, когда по какой стрелке идти.

На этом шаге есть 2 пункта, Define Expression и Activity Actions. Для определения условий перехода нужен 1 пункт. Кликнуть левой кнопкой мыши по стрелке, откроется окно Boolean Expression. Когда должен сработать переход? Когда значение атрибута Одобрено равно True.

Для этой стрелки нужен атрибут Одобрено. Для неё конечно можно аналогично указать, когда Одобрено равняется False. Для этого нужно закрыть первое окно Boolean Expression и произойдёт автоматический переход к ко к окну с названием Expression Selection выбрать и Is Else и нажать на кнопку Ок. После нажатия, запускается портал Bizagi , приложение cкомпилируется.

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

Для таких целей нужно добавить ещё одну таблицу и подключить её к существующей, но легче работать в одной, и Bizagi позволяет это делать. Добавить атрибут определяющий тип машины. А вот тип будет ссылка на справочник. И 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. Сотрудник, которому поступает счет на оплату, должен создать запрос на оплату.

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

В нашем примере мы должны разработать три сущности 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. Оповещения бывают двух видов: Использовать можно оба вида оповещений одновременно.

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

Документ сохраняется не только в системе, но и в печатной форме. В системе можно создавать, так называемый, document templates. Для печатной формы запроса можно использовать word, excel или простой текст.

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