Zdarzenia BPMN

Zdarzenie w BPMN oznacza coś, co się wydarza, a nie pracę wykonywaną przez uczestnika. Może utworzyć token, zatrzymać go do chwili nadejścia bodźca, zmienić ścieżkę albo zakończyć instancję. Cienka krawędź oznacza start, podwójna — zdarzenie pośrednie, a gruba — koniec.

Catching i throwing

Zdarzenie wychwytujące (catching) czeka: na wiadomość, termin lub sygnał. Zdarzenie rzucające (throwing) emituje rezultat, np. wysyła wiadomość albo zgłasza błąd. Timer jest zawsze wychwytujący — procesu nie da się „wysłać czasu”. Starty są zasadniczo catching, końce throwing. Znacznik wypełniony pomaga rozpoznać zdarzenie rzucające.

Typ	Znaczenie	Przykład
Message	Komunikacja między odrębnymi uczestnikami	Otrzymano zamówienie / wysłano decyzję
Timer	Data, czas trwania albo cykl	Po 48 godzinach przypomnij
Error	Błąd przerywający bieżący zakres	Integracja odrzuciła płatność
Signal	Rozgłoszenie do nieokreślonych odbiorców	Ogłoszono awarię globalną
Terminate end	Natychmiast usuwa wszystkie tokeny w zakresie	Zatrzymaj całą obsługę sprawy

Zdarzenie brzegowe: przerwać czy uruchomić obok?

Zdarzenie dołączone do zadania lub podprocesu obserwuje jego wykonanie. Brzeg ciągły oznacza wariant przerywający: po zdarzeniu aktywność zostaje anulowana, a token przechodzi ścieżką wyjątku. Brzeg przerywany oznacza wariant nieprzerywający: powstaje dodatkowy token, a pierwotna praca trwa dalej. Nieprzerywający timer może więc wysłać przypomnienie bez zamykania zadania.

Przypadek: oczekiwanie na dokumenty klienta

Po wysłaniu prośby proces czeka na jedno z dwóch zdarzeń za bramką event-based: wiadomość z dokumentami albo timer 14 dni. Jeśli dokumenty nadejdą pierwsze, timer jest anulowany i rozpoczyna się weryfikacja. Jeśli mija termin, sprawa kończy się jako niekompletna. Na zadaniu oczekiwania umieszczono dodatkowo nieprzerywający timer po 7 dniach, który wysyła przypomnienie, ale nie kończy oczekiwania.

Message, signal czy zwykły przepływ?

Przepływ sekwencji działa wewnątrz jednego basenu. Message flow łączy różne baseny i reprezentuje konkretną komunikację. Signal ma charakter rozgłoszeniowy: nadawca nie adresuje jednego odbiorcy. Nie modeluj wymiany pomiędzy systemami jako strzałki sekwencji przecinającej granice uczestników.

Starty i końce wpływają na całą instancję

Brak znacznika na starcie oznacza, że przyczyna uruchomienia nie została wyspecyfikowana. Jest to dopuszczalne na modelu wysokiego poziomu, ale niewystarczające dla automatyzacji. Message start tworzy nową instancję po wiadomości, timer start według kalendarza, a conditional start po spełnieniu obserwowanego warunku. Nie myl message start z wiadomością korelowaną do już istniejącej sprawy — ta powinna zostać wychwycona wewnątrz procesu.

Zwykły none end kończy tylko token, który do niego dotarł. Inne równoległe tokeny mogą nadal pracować. Message end najpierw emituje wiadomość, error end zgłasza błąd do zakresu nadrzędnego, a terminate end natychmiast usuwa wszystkie tokeny w bieżącym procesie lub podprocesie. Jeśli jedna gałąź AND dochodzi do none end, nie oznacza to automatycznie końca drugiej gałęzi.

Timer musi mieć precyzyjną podstawę czasu

„Po trzech dniach” nie mówi, czy chodzi o 72 godziny, trzy dni kalendarzowe czy robocze, od którego momentu liczyć i jaka strefa czasu obowiązuje. Artefakt uzupełniający powinien zawierać typ timera, punkt startu, kalendarz, zachowanie w dzień wolny i możliwość zmiany terminu. Dla cyklu określ także warunek zakończenia, aby przypomnienia nie trwały po zamknięciu sprawy.

Scenariusz testowy	Oczekiwane zdarzenie	Oczekiwany skutek
Dokumenty w dniu 6	Message catch	Weryfikacja; brak przypomnienia
Brak dokumentów w dniu 7	Nieprzerywający timer	Przypomnienie, oczekiwanie trwa
Dokumenty w dniu 9	Message wygrywa z terminem	Weryfikacja; timer 14 dni anulowany
Brak dokumentów w dniu 14	Timer za event-based gateway	Zamknięcie jako niekompletne

Korelacja wiadomości i duplikaty

Zdarzenie message musi wiedzieć, do której instancji należy komunikat. Numer sprawy, zamówienia lub inny klucz korelacji powinien być stabilny i przekazywany przez uczestników. Ustal zachowanie dla wiadomości spóźnionej, powtórzonej i niepasującej. Diagram może pokazać ścieżkę oczekiwania, lecz wymaganie integracyjne doprecyzowuje deduplikację, retencję i kolejność komunikatów.

W przykładzie dokumentów ponowne wysłanie tego samego pliku nie powinno uruchomić drugiej weryfikacji. Wiadomość po zamknięciu sprawy trafia do kolejki wyjaśnień albo otrzymuje jawne odrzucenie. Bez takiej reguły poprawny symbol message catch pozostawia niebezpieczną lukę wykonawczą.

Zdarzenie w podprocesie

Error end w podprocesie może zostać przechwycony przez zdarzenie brzegowe na tym podprocesie i skierować token do obsługi błędu. Escalation sygnalizuje sytuację wymagającą wyższego poziomu bez semantyki awarii technicznej; może być nieprzerywająca. Dobieraj typ do znaczenia biznesowego, nie do koloru alertu. Jeśli wyjątek ma anulować całą pracę wewnętrzną, użyj wariantu przerywającego świadomie.

Wydzielony event subprocess reaguje na zdarzenie w obrębie procesu, np. globalne anulowanie sprawy. Może przerwać główny przebieg albo działać obok niego. Jest użyteczny, gdy reakcja dotyczy wielu miejsc i nie chcesz dołączać tego samego zdarzenia do każdego zadania, ale jego zakres musi być widoczny dla odbiorcy.

Checklista zdarzenia

• Czy symbol opisuje fakt lub oczekiwanie, a nie ukrytą pracę?
• Czy wiadomo, co tworzy start i jaki rezultat oznacza koniec?
• Czy timer ma jednoznaczną datę, czas trwania lub cykl oraz kalendarz biznesowy?
• Czy zdarzenie brzegowe świadomie przerywa albo pozostawia aktywność?
• Czy terminate end jest zamierzony i nie kasuje potrzebnej pracy równoległej?

Alternatywę „wiadomość albo czas” modeluje się z bramką event-based. Różnicę między oczekiwaniem i wykonywaniem pracy rozwija materiał zadania BPMN.