О начале обучения |
Моделирование. Бизнес-процесс
4.4 Эмуляция процесса
После создания модели бизнес-процесса мы можем выполнить ее эмуляцию в WebSphere Business Integration Modeler, чтобы оценить ее производительность и внести соответствующие корректировки.
Если вы хотите использовать здесь готовую модель, создайте новый проект или новое рабочее пространство и импортируйте файл .\SG24-6636\Modeler\Projects\ PreBPEL.zip. Результаты эмуляции находятся в файле .\SG24-6636\Modeler\Projects\ Simulation Results.zip. Обращайтесь к прил. "А", "Дополнительные материалы".
4.4.1 Создание эмуляционного снимка
Сейчас мы можем запустить эмуляцию для процесса RequestExternalReports.
- Щелкните правой кнопкой мыши по модели процесса в дереве проектов и
выберите пункт меню Simulate (Эмуляция). Будет создан эмуляционный снимок
процесса (simulation snapshot), показанный на
рис.
4.48.
Этот снимок содержит:
- копию бизнес-процесса;
- копию всех элементов модели в проекте на данный момент времени;
- набор локальных настроек атрибутов эмуляции, показанный на рис. 4.49.
Примечание. Многие значения локальных настроек эмуляции происходят от глобальных параметров эмуляции. Настройки эмуляции конкретного процесса и задачи также происходят от локальных настроек эмуляции. Однако для эмуляции берутся значения, специально заданные для конкретного процесса или задачи. - Щелкнув мышью по пустой области снимка процесса в редакторе эмуляции, показанном на рис. 4.50, вы откроете настройки эмуляции, заданные для всего процесса ( рис. 4.51).
- Кроме того, мы можем указать атрибуты эмуляции задачи, выделив эту задачу. На рис. 4.52 показаны атрибуты эмуляции задачи IdentifyAssessors. Они дополняют собой те атрибуты, которые были определены в настройках эмуляции процесса.
- Проверьте значения на других закладках параметров эмуляции процесса. В частности, внесите изменения в закладку Resources (Ресурсы), чтобы сюда включались только те ресурсы, которые мы хотим использовать при эмуляции ( рис. 4.53).
4.4.2 Определение значений для эмуляции
Мы можем определить запуск нескольких эмуляций путем создания эстафет (tokens). Эстафета представляет собой единицу работы, которую получает процесс и которая передается между разными задачами в потоке процесса. Указывая параметры создания эстафеты, вы определяете количество и скорость поступления входных данных, которые процесс обрабатывает в ходе эмуляции. Вы также можете создавать эстафеты для каждой задачи. Обычно это не делается, поскольку работа движется по потоку от входа в бизнес-процесс, но вам может понадобиться проанализировать часть потока.
- Перейдите на закладку Inputs (Входы) представления Attributes (Атрибуты) параметров
эмуляции процесса (
рис.
4.51). Выберите строку, в которой отображаются
входные данные. Окно будет выглядеть примерно так, как показано
на
рис.
4.54:
- Мы можем выбрать вариант Time trigger (Временной триггер), если нужно, чтобы эстафеты поступали с определенными интервалами, или Random time trigger (Триггер случайного срабатывания), если нужно, чтобы эстафеты поступали случайным образом.
- При выборе варианта Random time trigger (Триггер случайного срабатывания) мы можем выбрать определенное распределение.
- При выборе варианта Time trigger (Временной триггер) мы можем указать начальный момент создания эстафеты и Recurring time interval for bundle creation (Периодичность создания пакетов).
- При указании параметра Recurring time interval for bundle creation (Периодичность создания пакетов) указывается время проведения эмуляции. Например, мы указываем:
Совет. Хорошей практикой является до изменения любых параметров всегда запускать эмуляцию всего процесса, указывая число эстафет равным 1. Таким образом, вы можете проверить правильность логики процесса при сохранении минимального времени эмуляции. - Чтобы предсказать объем поступления претензий, мы будем использовать данные
из реальной жизни, которые показывают, что в год в среднем поступает 1.5 претензии
на 100 полисов автострахования. Для объединенной компании это даст
нам следующий ожидаемый объем поступления претензий:
- 6 000 000 * 1.5/100 = 90 000 претензий в год.
- предполагая, что в году 250 рабочих дней, получаем 90 000/250 = 360 претензий в день;
- предполагая, что оценка требуется для 70% претензий, получаем 360 * 70% = 252 оценки в день;
- теперь мы можем получить периодичность создания пакетов: 8 * 60/252 = 1 минута 54 секунды, где количество эстафет в пакете = 1.
Установите 1-часовую обработку претензий на основе данных, указанных в шаге 2, чтобы длительность эмуляции была приемлемой. При таких данных эмуляция занимает около 5 минут на 2 ГГц Intel Pentium IBM Mseries Thinkpad (см. рис. 4.55).
Указание продолжительности для каждой задачи
Для каждой задачи, входящей в процесс, нужно заполнить в эмуляционном снимке5Начиная с WebSphere Business Integration Modeler 5.1.1.2 эти значения можно задавать как в модели, так и в эмуляционном снимке. Это удобно при работе с несколькими эмуляционными снимками. два поля ( рис. 4.56):
- Resource wait time (Время ожидания ресурса).
Это максимальное время ожидания доступа к ресурсу. Задайте здесь длительный период времени (скажем, год), если только вы не хотите прервать эмуляцию при недоступности ресурса.
-
Processing time (Время обработки).
Это время, которое требуется ресурсу для выполнения задачи. Сумма времени обработки и времени ожидания ресурса иногда называется в планировании проекта использованным временем (elapsed time).
Время обработки отличается от времени, установленного в требованиях роли. Время обработки может превышать время, которое требуется роли для выпол- нения задачи. Например, роль может инициировать выполнение задачи, но ее участие на всем протяжении времени обработки может и не требоваться.
Например, предположим, что специалист по обработке претензий может одновременно обрабатывать несколько претензий, отбирая по нескольку требований из списка зараз и работая с ними одновременно. Также предположим, что бизнес-аналитик решил, что страховая претензия должна быть изучена специалистом по обработке в течение дня после попадания ее в очередь.
- Время ожидания ресурса в модели должно быть определено как 1 день.
- В требованиях роли Claim handler можно указать время 10 минут - это то время, которое специалист в действительности тратит на рассмотрение претензии.
- Время обработки можно определить как 1 час - это время, проходящее между тем, как специалист запрашивает претензию и принимает решение по ее результату, завершая тем самым выполняемую вручную операцию.
В некоторых случаях время обработки и время в требованиях роли имеют одинаковые значения. В этом случае роль тратит все время на выполнение данной задачи.
В других случаях в этих двух полях указываются разные значения. Например, в задаче RequestAvailability наша система посылает запросы всем подходящим оценщикам и ожидает от них ответ, показывающий, доступны они или нет. Может случиться так, что за несколько часов запрос никто не увидит. Однако после того как оценщик увидит запрос, ему нужно лишь несколько минут, чтобы просмотреть свой график работы и сообщить данные о своей готовности. В данном случае мы устанавливаем параметр Time required to finish task (Время, необходимое для выполнения задачи) (это время равно 4 часам), в то время как параметр Time required (Необходимое время) соответствует времени, равному 2 минутам.
В табл. 4.3 перечислены параметры времени для задач. Введите эти числа в эмуляционный снимок, как показано на рис. 4.56.
Указание выходов для элементов Decision (Решение)
Для элементов Decision (Решение) мы указываем вероятность для каждого типа выхода, как показано в табл. 4.4.
Элемент Decision | Вероятность ответа "Да" | Вероятность ответа "Нет" |
---|---|---|
Any assessor? | 90% | 10% |
Confirmed? | 95% | 5% |
Параметры, приведенные в табл. 4.4, предполагают следующую ситуацию:
- Существует 90%-я вероятность того, что хотя бы один оценщик будет доступен. Существует 10%-я вероятность того, что доступных оценщиков не окажется и, следовательно, специалисту по обработке претензий придется назначать его самому.
- Существует 95%-я вероятность того, что оценщик, оказавшийся доступным, сможет выполнить оценку. Существует 5%-я вероятность того, что оценщик не сможет выполнить оценку из-за исключительных обстоятельств, например несчастного случая.
Теперь мы укажем в поле Method of selecting an output path (Метод выбора пути выхода) значение Based on probabilities to single path (Один путь на основе вероятности), как показано на рис. 4.57.