10.4 Событие
Событие – это то, что происходит в течение бизнес-процесса или его Xореографии. Событие оказывает влияние на ход бизнес-процесса и чаще всего имеет причину (триггер) или воздействие (результат). Изображается в виде круга со свободным центром, предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов. Объемное понятие «событие» включает в себя такие попадающие под эту категорию явления Процесса, как: старт Процесса, его завершение, смена статуса задействуемого документа, получение сообщения и мн.др.
Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа: Стартовое событие (указывающее на точку запуска Процесса), Конечное событие (указывающее на точку завершения Процесса) и Промежуточное событие (указывающее на что-то, происходящее на ограниченном Стартовым и Конечным Событиями отрезке Процесса).
Вышеперечисленные типы Событий, в свою очередь, могут:
- Обрабатывать триггер. Такими являются все Стартовые и некоторые Промежуточные События.
- Определять результат (возбуждать триггер). Такими являются все Конечные и некоторые Промежуточные События. Они МОГУТ влиять на другие События. Как правило, триггеры передают информацию из места, где произошло такое Событие, туда, где находится реагирующее на триггер Событие. Согласно стандартам BPMN, возбуждение триггера МОЖЕТ БЫТЬ скрытым (или каким-либо другим, являющимся разновидностью скрытого) или явным (при содействии определяющего результат События).
Фигура 10.69 – Диаграмма классов элемента Event
10.4.1 Общее представление о Событии
В зависимости от типа События, применяются различные способы запуска триггера в направлении реагирующего на него События: публикация, вынесение непосредственного решения, распространение, отмена, а также компенсация.
В рамках публикации триггер МОЖЕТ быть получен Событием, находящимся в любой части системы, где производится публикация данного триггера. События, для которых используется данный способ возбуждения триггера, образуют группу Обмена сообщениями. В качестве триггеров здесь выступают События, сформированные за рамками Пула, в котором производится их публикация. Обычно они используются для описания B2B модели сообщения между разными Процессами разных Пулов. Для указания определенного экземпляра Процесса в момент, когда такое Сообщение должно достичь данного экземпляра Процесса, используется корреляция. Триггеры, называемые Сигналами, формируются в Пуле, где производится их публикация. Как правило, они используются для распространения сообщения в Процессах и между ними, а также между Пулами и диаграммами Процессов.
Триггеры, называемые Таймер и Условие, запускаются скрыто. После запуска они ожидают условия, при котором могут повлиять на Событие, обрабатывающее триггер. Эти условия могут быть основаны на временном или статусном критериях.
Триггер, используемый в качестве распространения, передается от места, где было запущено Событие, к наиболее удаленному месту экземпляра (например, на другой уровень Процесса), к которому привязано Событие, реагирующее на триггер. Триггер, используемый в качестве Ошибки, является критичным и прекращает выполнение в месте его запуска. Эскалация, в свою очередь, критичной не является, а выполнение продолжается в месте запуска этого триггера. В случае, если для двух последних типов триггеров не определено ни одного реагирующего на них События, они считаются невыполненными (неразрешенными). В рамках Процесса или определенного экземпляра Действия рекомендуется использовать завершение, компенсацию, а также отмену. Завершение используется для указания того, что выполнение всех Действий, содержащихся в Процессе или другом Действии, должно быть немедленно завершено (без компенсации или использования События). Это касается все экземпляров многоэкземплярного Действия или Процесса.
Компенсация удачно выполненного Действия запускает обработчика этой компенсации. Обработчик компенсации может быть двух типов: определяемый пользователем и скрытый. Скрытый обработчик компенсации, используемый для Подпроцесса, вызывает обработчики компенсаций всех содержащихся в нем Действий в последовательности, обратной Потоку операций. В случае, если вызываемая компенсация предназначается для ещё не выполненного или неудачно выполненного Действия, она никак себя не проявляет (в частности, не возникает никаких ошибок).
Отмена прерывает выполнение всех активных Действий и компенсирует все успешно выполненные Действия Подпроцесса, для которого она используется. Если этот Подпроцесс является Транзакцией, то он возвращается в начало.
Моделирование данных в Событиях
Некоторые События (например, Сообщение, Эскалация, Ошибка, Сигнал, Множественное) могут содержать в себе данные. Для продвижения данных от реагирующего на триггер События к элементу данных используется Ассоциация данных. Однако при использовании Событий, содержащих данные, должны быть приняты во внимание следующие ограничения:
- Если Событие связанно с множеством элементов EventDefinitions, то каждому их этих элементов ДОЛЖЕН соответствовать один вход для данных (если Событие определяет результат) или один выход для данных (если Событие реагирует на триггер) События. Порядок расположения элементов EventDefinition и порядок размещения входов/выходов для данных определяют, какой вход/выход какому элементу соответствует.
- Если Событие имеет вход/выход для данных, то для каждой пары «элемент EventDefinition - вход/выход для данных» ДОЛЖЕН БЫТЬ определен элемент ItemDefinition, значение которого равно значению, установленному для элементов ItemDefinition Сообщения, Эскалации, Ошибки или Сигнала. В случае, если Событие определяет результат и не имеет входа для данных, то данные в Сообщение, Эскалацию, Ошибку или Сигнал переданы не будут. Если же Событие реагирует на триггер и не имеет выхода для данных, то данные из Сообщения, Эскалации, Ошибки или Сигнала не покинул пределы этого События и не попадут в Процесс.
Во время выполнения События ведут себя следующим образом:
- Определяющие результат События. После запуска События, соответствующий элемент EventDefinition ссылается на входные данные, автоматически переданные в Сообщение, Эскалацию, Ошибку и Сигнал.
- Имеющие триггер События. Когда появляется предназначенный для данного События триггер (например, при получении Сообщения), данные автоматически передаются на выход для данных, соответствующий элементу EventDefinition с описанием триггера.
Общие атрибуты События
Элемент Event наследует атрибуты и ассоциации элемента FlowElement (см. таблицу 8.44). Таблица 10.81 содержит информацию о дополнительных ассоциациях элемента Event.
Таблица 10.81 – Ассоциации элемента Event
|
Название атрибута |
Описание/использование |
|
properties: Property [0..*] |
Разработчик модели МОЖЕТ добавить в Событие какие-либо свойства. Эти свойства хранятся в Событии. |
Общие атрибуты обрабатывающего триггер События
Элемент CatchEvent наследует атрибуты и ассоциации элемента Event (см. таблицу 10.81). Таблица 10.82 содержит информацию о дополнительных атрибутах и ассоциациях элемента CatchEvent.
Таблица 10.82 – Атрибуты и ассоциации элемента CatchEvent
|
Название атрибута |
Описание/использование |
|
eventDefinitionRefs: EventDefinition [0..*] |
Ссылается на повторно используемые элементы EventDefinition, являющиеся ожидаемыми для данного вида Событий триггерами. Повторно используемые элементы EventDefinition определены как высокоуровневые элементы. Эти элементы могут быть использованы как для Событий, имеющих триггер, так и для Событий, определяющих результат.
Является упорядоченным множеством. |
|
eventDefinitions: EventDefinition [0..*] |
Определяет элементы EventDefinition События, являющиеся ожидаемыми для данного вида Событий триггерами. Значения этих элементов верны лишь в пределах текущего События.
Является упорядоченным множеством. |
|
dataOutputAssociations: Data OutputAssociation [0..*] |
Указывает Ассоциацию данных имеющего триггер События. Элемент dataOutputAssociation, относящийся к данному Событию, используется для передачи данных из События в элемент данных, находящийся в рамках этого События. В зависимости от того, какие индивидуальные триггеры имеет Многоэкземплярное событие этого вида, могут быть НЕОБХОДИМЫ множественные Ассоциации данных. |
|
dataOutputs: DataOutput [0..*] |
Определяет выходы для данных имеющего триггер События. Является упорядоченным множеством. |
|
outputSet: OutputSet [0..1] |
Определяет набор выходных данных для имеющего триггер События. |
|
parallelMultiple: boolean = false |
Данный атрибут является важным только тогда, когда указаны значения нескольких элементов EventDefinition имеющего триггер События (Множественного события). Если установленное значение равно «true», то все типы триггеров, используемых для данного События, ДОЛЖНЫ запуститься до начала Процесса. |
Общие атрибуты возбуждающего триггер События
Элемент ThrowEvent наследует атрибуты и ассоциации элемента Event (см. таблицу 10.81). Таблица 10.83 содержит информацию о дополнительных атрибутах и ассоциациях элемента ThrowEvent.
Таблица 10.83 – Атрибуты и ассоциации элемента ThrowEvent
|
Название атрибута |
Описание/использование |
|
eventDefinitionRefs: EventDefinition [0..*] |
Ссылается на повторно используемые элементы EventDefinition, являющиеся ожидаемым для данного вида Событий результатом. Повторно используемые элементы EventDefinition определены как высокоуровневые элементы. Эти элементы могут быть использованы как для Событий, имеющих триггер, так и для Событий, определяющих результат.
Является упорядоченным множеством. |
|
eventDefinitions: EventDefinition [0..*] |
Определяет элементы EventDefinition События, являющиеся ожидаемым для данного вида Событий результатом. Значения этих элементов верны лишь в пределах текущего События.
Является упорядоченным множеством. |
|
dataInputAssociations: DataInput Association [0..*] |
Указывает Ассоциацию данных определяющего результат События. Элемент dataInputAssociation используется для передачи элемента данных, находящегося в пределах События, в данные этого События. В зависимости от того, к какому результату приводит Многоэкземплярное событие этого вида, могут быть НЕОБХОДИМЫ множественные Ассоциации данных. |
|
dataInputs: DataInput [0..*] |
Определяет входы для данных определяющего результат События. Является упорядоченным множеством. |
|
inputSet: InputSet [0..1] |
Определяет набор входных данных для определяющего результат События. |
Скрытое возбуждающее триггер Событие
Подтипом определяющего результат События является скрытое возбуждающие триггер События. На диаграмме Процесса это Событие не отображается и используется для Многоэкземплярных Действий. Элемент ImplicitThrowEvent атрибуты и ассоциации элемента ThrowEvent (см. таблицу 10.84), однако, не может иметь каких-либо других дополнительных атрибутов или ассоциаций.
10.4.2 Стартовое событие
Как видно из названия, Стартовое событие указывает на то, в какой точке берет начало тот или иной Процесс. Говоря языком BPMN, от Стартового события берет начало Поток операций Процесса, а значит, оно не может иметь Входящих потоков операций.
Изображается в виде круга со свободным центром (установленное в BPMN отображение графического элемента Событие), предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов.
- Событие представляет собой круг со свободным центром, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой линией (см. фигуру 10.70).
- Текст, цвет, размер, а также линии, используемые для изображения События, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм».
- Толщина линии ДОЛЖНА БЫТЬ тонкой настолько, чтобы без труда можно было бы отличить Стартовое событие от Промежуточного или Конечного.
- Текст, цвет, размер, а также линии, используемые для изображения События, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм».
Фигура 10.70 – Графический элемент Стартовое событие
На протяжении изложения материала данного документа авторами будет обсуждаться то, в каком направлении движется Поток операций внутри Процесса. Для облегчения усвоения материала обратимся к понятию «токен». Токен пересекает Поток операций и проходит через Элементы потока, содержащиеся в Процессе. Токен – это теоретическое понятие, используемое для определения характера поведения выполняемого Процесса. Поведение элементов Процесса определяется посредством описания их взаимоотношений с токеном, когда он пересекает Процесс.
Примечание: Токен не пересекает Поток сообщений, поскольку именно Сообщение передается посредством Потока сообщений.
Стартовое событие имеет следующие особенности:
- Стартовое событие является НЕОБЯЗАТЕЛЬНЫМ. Высокоуровневый Процесс, Встроенный Подпроцесс (уровни Процесса), а также Глобальный Процесс (Процесс) МОГУТ содержать Стартовое событие, однако, это НЕ является ОБЯЗАТЕЛЬНЫМ.
Примечание: Диаграмма бизнес-процесса может включать Процессы разных уровней (например, может содержать Развернутый Подпроцесс или Действие Вызов для вызова других Процессов). Стартовое и Конечное События используются индивидуально для каждого уровня диаграммы Процесса.
- Если Процесс является сложным и/или условия его запуска не очевидны, то РЕКОМЕНДУЕТСЯ использовать Стартовое событие.
- Если Стартовое событие не включено в Состав Процесса, то скрытое Стартовое событие НЕ ДОЛЖНО реагировать на триггер.
- Если в состав Процесса включено Конечное событие, то в его состав должно также входить по-меньшей мере одно Стартовое событие.
- Все Элементы потока, не имеющие Входящих потоков операций (например, те, что не являются целью Потока операций), ДОЛЖНЫ запускаться при старте экземпляра Процесса.
- Исключения составляют Действия, используемые в качестве Компенсаций (имеют соответствующий маркер). Действие Компенсация не является частью Стандартного потока операций и НЕ ДОЛЖНО запускаться одновременно с Процессом.
- Исключением является и реагирующее на триггер Промежуточное событие Связь, которое не может иметь Входящих потоков операций.
- Исключением также является Событийный Подпроцесс, который не может иметь Входящих потоков операций и запускается только тогда, когда запускается Стартовое событие, включенное в его состав.
- Процесс МОЖЕТ содержать множество Стартовых событий на любом уровне.
- Каждое Стартовое событие является независимым, т.е. новый экземпляр Процесса ДОЛЖЕН БЫТЬ сформирован при запуске Стартового события.
Если Процесс является глобальным (Процесс, вызываемый Действиями Вызов других Процессов) и содержит множество Стартовых событий неопределенного типа, то при перемещении Потока операций из родительского Процесса в глобальный будет запущено лишь одно из Стартовых событий глобального Процесса. Атрибут targetRef Потока операций, направленного к Действию Вызов, может быть расширен с целью указать соответствующее Стартовое событие.
Примечание: Если Процесс содержит несколько Стартовых событий, его поведение может стать более сложным для понимания. РЕКОМЕНДУЕТСЯ как можно более редкое использование такой схемы во избежание неверного понимания пользователями диаграммы Процесса цели, для которой она создавалась.
При появлении триггера, предназначенного для Стартового события, запускается новый экземпляр Процесса, и для каждого Исходящего потока операций, направленного от этого События, создается токен.
Триггеры Стартового события
Стартовые события могут быть включены в состав следующих типов Процессов:
- Высокоуровневые Процессы
- Подпроцессы (встроенные)
- Глобальные Процессы (вызываемые)
- Событийные Подпроцессы
Следующие три подраздела содержат описание типов Стартовых событий, используемых для разных типов Процессов.
Стартовые события в Высокоуровневых Процессах
Существует множество способов запуска высокоуровневых Процессов и их экземпляров. Графическое изображение триггеров Стартовых событий помогает отобразить общий механизм запуска экземпляров отдельно взятого Процесса. В состав высокоуровневого Процесса могут входить как Стартовые события с неопределенным типом триггера (тип Неопределенный), так и События, имеющие триггеры: «Сообщение», «Таймер», «Условие», «Сигнал», «Множественный», «Параллельный».
Высокоуровневый Процесс, содержащий хотя бы одно Стартовое событие с неопределенным типом триггера, МОЖЕТ вызываться посредством Действия Вызов другого Процесса. Такое Стартовое событие используется для запуска Процесса Действием Вызов. Другие типы Стартового события могут использоваться только в том случае, если текущий Процесс – высокоуровневый.
Таблица 10.84 – Типы Стартового события высокоуровневого Процесса
|
Тип триггера |
Описание |
Маркер |
|
Неопределенный |
Отсутствие маркера предполагает отсутствие у Стартового события определенного триггера. Для Стартовых событий без триггера не существует конкретного подкласса EventDefinition. В случае, если Стартовое событие не связано ни с каким элементом EventDefiniton, оно ДОЛЖНО отображаться пустым, т.е. без маркера. |
|
|
Сообщение |
От Участника поступает Сообщение, которое инициирует запуск Процесса. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс MessageEventDefinition, то данное Стартовое событие будет иметь тип Сообщение. Оно ДОЛЖНО отображаться с маркером, выполненным в виде конверта. Текущий Участник, от которого было получено Сообщение, определяется посредством соединения графического элемента События с Участником при помощи Потока сообщений. В Процессе это отображается в рамках Взаимодействия (см. таблицу 10.1). |
|
|
Таймер |
Определенный временной интервал или цикл (например, еженедельно по понедельникам в 9.00 утра), инициирующий возникновение Процесса. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс TimerEventDefinition, то данное Стартовое событие будет иметь тип Таймер. Оно ДОЛЖНО отображаться с маркером, выполненным в виде аналоговых часов. |
|
|
Условие |
Стартовое событие данного типа возникает в случае, если условия для правил, типа «Повышение индекса S&P 500 с момента открытия составляет более 10%» или «Температура свыше 300С», становятся верными. Для повторного запуска данного типа События условное выражение для него ДОЛЖНО переключиться в режим «ложь» и только затем – в режим «истина». Условное выражение НЕ ДОЛЖНО ссылаться на контекст данных или атрибут экземпляра Процесса (т.к. новый экземпляр Процесса ещё не создан). Однако оно МОЖЕТ ссылаться на статические атрибуты Процесса и статусы объектов. Данный документ не содержит описания механизмов получения доступа к таким статусам. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс ConditionalEventDefinition, то данное Стартовое событие будет иметь тип Условие. Оно ДОЛЖНО отображаться с маркером, выполненным в виде фрагмента разлинованной бумаги. |
|
|
Сигнал |
Переданный из другого Процесса сигнал поступает в текущий Процесс и инициирует его запуск. Обратите внимание, что Сигнал – это не Сообщение, которое преследует совершенно другую цель. Многие Процессы могут содержать в составе Стартовые события, запускаемые с помощью одного и того же переданного Сигнала. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс SignalEventDefinition, то данное Стартовое событие будет иметь тип Сигнал. Оно ДОЛЖНО отображаться с маркером, выполненным в виде треугольника. |
|
|
Множественный |
Подразумевает наличие множества способов инициирования Процесса. Однако для запуска Процесса НЕОБХОДИМ лишь один из таких способов. Атрибуты Стартового события указывают, какой из видов Триггеров был использован. Для Стартовых событий Множественного типа не существует конкретного подкласса EventDefinition. В случае, если такое Стартовое событие связано более, чем с одним EventDefiniton, оно ДОЛЖНО отображаться с маркером, выполненным в виде пятиугольника. |
|
|
Параллельный многоэкземплярный |
Подразумевает НЕОБХОДИМОСТЬ задействования множества способов инициирования Процесса до момента его запуска. Все типы триггеров, включенные в Стартовое событие, ДОЛЖНЫ БЫТЬ активированы до того, как начнется выполнение экземпляра Процесса. Для Стартовых событий Параллельного Множественного типа не существует конкретного подкласса EventDefinition. В случае, если такое Стартовое событие связано более, чем с одним элементом EventDefiniton, а атрибут parallelMultiple События имеет значение «true», оно ДОЛЖНО отображаться с маркером, выполненным в знака «плюс» без заливки. |
|
Стартовые события в Подпроцессах
В состав Подпроцесса может входит Стартовое событие лишь одного типа: Неопределенное (см. фигуру 10.82).
Таблица 10.85 –Триггер Стартового события Подроцесса
|
Тип триггера |
Описание |
Маркер |
|
Неопределенный |
Неопределенное Стартовое событие входит в состав всех типов Подпроцессов: встроенных и вызываемых (повторно используемых). Другие типы триггеров для Подпроцессов не используются, т.к. Поток операций (токен), направленный от родительского Процесса, является триггером для Подпроцесса. В случае, если Подпроцесс является вызываемым (повторно используемым) и содержит несколько Стартовых событий, некоторые из таких Событий МОГУТ иметь триггеры, но при этом они не будут использоваться в контекста данного Подпроцесса. Вызов этих Стартовых событий запускал бы экземпляры высокоуровневых Процессов. |
|
Стартовые события в Событийных Подпроцессах
Стартовое событие может быть использовано в общем потоке для запуска экземпляра Событийного Подпроцесса. В этом случае, допускаются те же типы событий, что и для пограничных Событий (см. таблицу 10.86), а именно: Сообщение, Таймер, Эскалация, Ошибка, Компенсация, Условие, Сигнал, Множественное, Параллельное.
- Событийный Подпроцесс ДОЛЖЕН содержать одно-единственное Стартовое событие.
Таблица 10.86 – Типы Стартового события Событийного Подпроцесса
|
Тип триггера |
Описание |
Маркер |
|
Сообщение |
Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс MessageEventDefinition, то данное Стартовое событие будет иметь тип Сообщение. Оно ДОЛЖНО отображаться с маркером, выполненным в виде конверта.
Текущий Участник, от которого было получено Сообщение, определяется посредством соединения графического элемента События с Участником при помощи Потока сообщений. В Процессе это отображается в рамках Взаимодействия (см. таблицу 10.1). |
Прерывающее Непрерывающее |
|
Таймер |
Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс TimerEventDefinition, то данное Стартовое событие будет иметь тип Таймер. Оно ДОЛЖНО отображаться с маркером, выполненным в виде аналоговых часов.
|
Прерывающее Непрерывающее |
|
Эскалация |
Событийный Подпроцесс, в состав которого входит Эскалация, используется для принятия мер по ускорению выполнения Действия в случае, если Действие не выполняется в соответствии с указанными ограничениями (например, временными рамками). Стартовое событие данного типа может использоваться исключительно для запуска Событийного Подпроцесса общего потока. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс EscalationEventDefinition, то данное Стартовое событие будет иметь тип Эскалация. Оно ДОЛЖНО отображаться с маркером, выполненным в виде стрелки.
|
Прерывающее Непрерывающее |
|
Ошибка |
Стартовое событие данного типа может использоваться исключительно для запуска Событийного Подпроцесса общего потока. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс ErrorEventDefinition, то данное Стартовое событие будет иметь тип Ошибка. Оно ДОЛЖНО отображаться с маркером, выполненным в виде молнии. В силу того, что данный триггер имеет тип «ошибка», Событийный Подпроцесс, имеющий Стартовое сообщение такого типа, всегда прерывает содержащийся в нем Процесс. |
Прерывающее |
|
Компенсация |
Стартовое событие данного типа может использоваться исключительно для запуска Событийного Подпроцесса Компенсация общего потока (см. подраздел «Обработчик компенсации»). Оно запускается при появлении компенсации. Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс CompensationEventDefinition, то данное Стартовое событие будет иметь тип Компенсация. Оно ДОЛЖНО отображаться с маркером, выполненным в виде двух повернутых влево треугольников. Данное Событие не прерывает выполнение Процесса, т.к.до момента вызова Стартового события Компенсация Процесс уже должен быть выполнен. |
|
|
Условие |
Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс ConditionalEventDefinition, то данное Стартовое событие будет иметь тип Условие. Оно ДОЛЖНО отображаться с маркером, выполненным в виде фрагмента разлинованной бумаги.
|
Прерывающее Непрерывающее |
|
Сигнал |
Если Стартовое событие связано только с одним элементом EventDefinition, а этот элемент, в свою очередь, входит в подкласс SignalEventDefinition, то данное Стартовое событие будет иметь тип Сигнал. Оно ДОЛЖНО отображаться с маркером, выполненным в виде треугольника.
|
Прерывающее Непрерывающее |
|
Множественный |
Подразумевает наличие множества способов инициирования Процесса. Однако для запуска Процесса НЕОБХОДИМ лишь один из таких способов. Для Стартовых событий Множественного типа не существует конкретного подкласса EventDefinition. Если Стартовое событие связано более, чем с одним элементом EventDefinition, то данное Стартовое событие будет иметь тип Множественный. Оно ДОЛЖНО отображаться с маркером, выполненным в виде треугольника.
|
Прерывающее Непрерывающее |
|
Параллельный Множественный |
Подразумевает НЕОБХОДИМОСТЬ задействования множества способов инициирования Процесса до момента его запуска. Все эти способы НЕОБХОДИМЫ для запуска Процесса. Для Стартовых событий Параллельного Множественного типа не существует конкретного подкласса EventDefinition. В случае, если такое Стартовое событие связано более, чем с одним элементом EventDefiniton, а атрибут parallelMultiple События имеет значение «true», оно ДОЛЖНО отображаться с маркером, выполненным в знака «плюс» без заливки.
|
Прерывающее Непрерывающее |
Атрибуты Стартового события
Элемент StartEvent наследует атрибуты и ассоциации элемента CatchEvent (см. таблицу 10.82). Таблица 10.87 содержит информацию о дополнительных атрибутах элемента StartEvent.
Таблица 10.87 – Атрибуты элемента StartEvent
|
Название атрибута |
Описание/использование |
|
isInterrupting: boolean = true |
Данный атрибут подходит лишь для Стартовых событий работающих с данными Подпроцессов и игнорируется другими Стартовыми событиями. Атрибут указывает на то, должен ли быть отменен Подпроцесс, окружающий работающий с данными Подпроцесс, или нет. Если выполнение окружающего Подпроцесса не отменяется, то множественные экземпляры работающего с данными События будут двигаться одновременно. Данный атрибут не может быть использован для Сообщений типов: Ошибка (т.к. значение данного атрибута всегда равно «true») и Компенсация (где он не может быть применен в принципе). |
Соединение с Потоком операций
Для того, чтобы увидеть полный список графических элементов и узнать, каким образом они МОГУТ являться целями и источниками Потока операций, обратитесь к пункту 7.5.1 «Правила Соединения Потоков Операций».
- Стартовое событие НЕ ДОЛЖНО являться целью Потока операций. Оно НЕ ДОЛЖНО БЫТЬ соединено с каким-либо Входящим потоком операций.
- Исключением является ситуация, когда Стартовое событие используется в Развернутом Подпроцессе и соединяется с границами данного Подпроцесса. В этом случае Поток операций, относящийся к Процессу более верхнего уровня, МОЖЕТ БЫТЬ соединен со Стартовым событием, а не с границей Подпроцесса.
- Стартовое событие ДОЛЖНО являться источником Потока операций.
- Множественный поток операций МОЖЕТ начинаться со Стартового события. Необходимо создание нового параллельного маршрута для каждого Потока операций, использующего в качестве источника Стартовое событие.
- Атрибут conditionExpression для всех Исходящих потоков операций ДОЛЖЕН иметь значение «None».
- В случае, если Процесс не содержит Стартового события, то каждый Элемент потока, не имеющий Входящего потоков операций, ДОЛЖЕН стать началом независимого параллельного маршрута.
- Каждый маршрут обладает уникальным Токеном, пересекающим Поток операций.
Соединение с Потоком сообщений
Примечание: Все Потоки сообщений ДОЛЖНЫ соединять два разных Пула. Они МОГУТ быть присоединены к границам Пула, а также к Элементам потока внутри этого Пула. Они НЕ ДОЛЖНЫ использоваться для соединения двух элементов внутри одного Пула.
Для того, чтобы увидеть полный список графических элементов и узнать, каким образом они могут являться целями Потока сообщений, обратитесь к пункту 7.5.2 «Правила Соединения Потоков Сообщений».
- Стартовое событие МОЖЕТ БЫТЬ целью Потока сообщений и иметь как несколько Входящих потоков сообщений, так и ни одного. Любой Поток сообщений, являющийся входящим для Стартового события, представляет собой механизм запуска (триггер) Процесса. Для запуска нового Процесса требуется лишь один из триггеров.
Стартовое событие НЕ ДОЛЖНО являться источником Потока сообщений; оно также НЕ ДОЛЖНО соединяться с какими-либо Исходящими потоком сообщений