Model i notacja procesu biznesowego (BPMN) pełni rolę uniwersalnego języka do opisywania przepływów pracy. W ramach tego standardu wizualnegozdarzeniasą wyzwalaczami i wynikami, które napędzają cały proces do przodu. Bez jasnego zrozumienia, jak działają te zdarzenia, model procesu może stać się niejasny lub technicznie niemożliwy do wykonania. Ten przewodnik analizuje trzy główne kategorie: zdarzenia początkowe, pośrednie i końcowe.
Zdarzenia są przedstawiane jako okręgi w notacji BPMN. Ich wewnętrzne symbole określają ich konkretne zachowanie. Oznaczają początek, wystąpienie lub zakończenie aktywności procesu. Poprawne ich ustawienie zapewnia, że logika płynnie przepływa od jednego zadania do drugiego.
🟢 Zdarzenia początkowe: punkt wyzwalania
Zdarzenie początkowe inicjuje proces. Jest to punkt wejścia, w którym przepływ pracy zaczyna się wykonywać. Wizualnie zdarzenie początkowe to okrąg o cienkim obramowaniu. Istnieją konkretne typy zdarzeń początkowych, które określają sposób uruchomienia procesu.
1. Zdarzenie początkowe typu Brak
- Symbol:Pusty okrąg wewnątrz większego okręgu.
- Zachowanie: Jest to domyślne ustawienie. Oczekuje na interwencję ręczną lub wywołanie zewnętrznej usługi, aby rozpocząć proces.
- Przykład zastosowania:Idealne dla procesów, które rozpoczynają się na żądanie, takich jak przepływ pracy „Prośba o zatwierdzenie” uruchamiany przez użytkownika.
2. Zdarzenie początkowe typu Wiadomość
- Symbol:Ikona koperty wewnątrz okręgu.
- Zachowanie: Proces rozpoczyna się, gdy odbierana jest określona wiadomość. Oznacza to asynchroniczne wyzwalanie.
- Przykład zastosowania:Odbieranie potwierdzenia e-mail lub wywołania API, które uruchamia cykl realizacji.
3. Zdarzenie początkowe typu Timer
- Symbol:Ikona tarczy zegara wewnątrz okręgu.
- Zachowanie: Proces rozpoczyna się w określonym czasie lub na podstawie cyklicznego harmonogramu.
- Przykład zastosowania: Generowanie dziennych raportów, miesięczne wypłaty czy kopie zapasowe systemu.
4. Zdarzenie początkowe typu Sygnał
- Symbol: Żółty błyskawica wewnątrz okręgu.
- Zachowanie: Proces rozpoczyna się, gdy sygnał jest nadawany. Ten sygnał może być przechwycony przez wiele procesów jednocześnie.
- Przypadek użycia: Globalne ostrzeżenie systemowe, które uruchamia zadania konserwacyjne w różnych działach.
5. Zdarzenie początkowe błędu
- Symbol: Wykrzyknik wewnątrz okręgu (zazwyczaj czerwony).
- Zachowanie: Rzadko używane jako zdarzenie początkowe w standardowych przepływach, ale technicznie możliwe, jeśli proces został zaprojektowany w taki sposób, aby od razu po uruchomieniu przywrócić stan z określonego błędu.
Krytycznie ważne jest zaznaczenie, że proces musi mieć dokładnie jedno zdarzenie początkowe. Posiadanie wielu zdarzeń początkowych może prowadzić do nieporozumień co do tego, które warunki inicjują przepływ pracy.
🟡 Zdarzenia pośrednie: wystąpienie
Zdarzenia pośrednie występują podczas wykonywania procesu. Położone są pomiędzy zdarzeniem początkowym a końcowym. Te zdarzenia mogą albo przechwytywać zdarzenie (czekanie na coś) albo wywoływać zdarzenie (wysyłanie czegoś). Wizualnie są to okręgi z grubym obramowaniem.
1. Zdarzenia pośrednie przechwytywania
Te zdarzenia zatrzymują przepływ procesu, dopóki nie zostanie spełniony określony warunek. Gdy warunek zostanie spełniony, przepływ kontynuuje się.
- Przechwytywanie wiadomości: Czeka na przyjście określonej wiadomości. Proces jest zatrzymywany, dopóki dane nie zostaną otrzymane.
- Przechwytywanie timera: Opóźnia proces przez określoną długość czasu (np. poczekaj 3 dni) lub do określonej daty.
- Przechwytywanie błędu: Czeka na rzucenie określonego błędu przez zadanie górne. Często używane w podprocesach obsługi błędów.
- Przechwytywanie sygnału: Czeka na nadanie sygnału. W przeciwieństwie do wiadomości, sygnały są nadawane, a nie wysyłane do konkretnego odbiorcy.
- Przechwytywanie linku: Łączy się z zdarzeniem Link Throw w ramach tego samego procesu. Użyteczne w przypadku długich pętli lub złożonych przepływów.
- Przechwytywanie eskalacji: Czeka na rzucenie eskalacji. Jest to specyficzne dla obsługi eskalacji procesu.
2. Zdarzenia pośrednie wywoływania
Te zdarzenia natychmiast wywołują działanie, gdy przepływ przechodzi przez nie. Nie zatrzymują przepływu.
- Wywoływanie wiadomości: Wysyła wiadomość do innego uczestnika lub systemu natychmiast.
- Wyrzucenie sygnału: Rozsyła sygnał do wszystkich procesów nasłuchujących na ten konkretny sygnał.
- Wyrzucenie eskalacji:Wyzwala eskalację w logice procesu.
- Wyrzucenie linku: Przesyła przepływ sterowania do zdarzenia typu Link Catch w innym miejscu schematu.
3. Przerywane zdarzenia pośrednie
Specjalny rodzaj zdarzenia pośredniego przypiętego do brzegu zadania lub podprocesu. Pozwala obsłużyć przerwania bez natychmiastowego zatrzymania głównego przepływu.
- Brzeg anulowania:Anuluje działanie, jeśli zdarzy się wydarzenie.
- Brzeg timera:Wyzwala alternatywną ścieżkę, jeśli zadanie trwa zbyt długo (przekroczenie czasu oczekiwania).
- Brzeg wiadomości: Pozwala zadaniu kontynuować działanie, jednocześnie nasłuchując wiadomości.
- Brzeg błędu: Przechwytuje błąd wywołany podczas wykonywania przypisanego zadania.
Zrozumienie różnicy między przechwytywaniem a wyrzucaniem jest kluczowe. Przechwytywanie czeka; wyrzucanie działa. Pomylenie ich może spowodować procesy, które zawieszą się na zawsze lub wykonają się zbyt wcześnie.
🔴 Zdarzenia końcowe: Zakończenie
Zdarzenia końcowe oznaczają sukces lub niepowodzenie zakończenia procesu. Oznaczają końcowy punkt wykonywania. Podobnie jak zdarzenia początkowe, są one okręgami, ale często mają grubą obramowkę, aby wskazać na ich ostateczność.
1. Zdarzenie końcowe bez typu
- Symbol:Pusty okrąg.
- Zachowanie:Proces po prostu się zatrzymuje. Nie wysyłany żaden dane, nie wysyłana żadna zewnętrzna informacja.
- Przypadek użycia:Standardowy przepływ pracy, który kończy się bez potrzeby dalszego zewnętrznego potwierdzenia.
2. Zdarzenie końcowe wiadomości
- Symbol:Ikona koperty.
- Zachowanie: Wysyła wiadomość jako ostatni krok procesu.
- Przypadek użycia: Wysyłanie e-maila potwierdzającego „Zamówienie zakończone” do klienta.
3. Zdarzenie zakończenia sygnału
- Symbol: Żółty błyskawica.
- Zachowanie: Rozsyła sygnał w celu zakończenia innych powiązanych procesów lub powiadomienia systemu.
- Przypadek użycia: Powiadamianie o globalnym aktualizacji stanu, że określona transakcja została zakończona.
4. Zdarzenie zakończenia błędu
- Symbol: Znak wykrzyknika.
- Zachowanie: Wskazuje, że proces został zakończony z powodu warunku błędu.
- Przypadek użycia: Rejestrowanie nieudanej transakcji, która nie może zostać odzyskana.
5. Zdarzenie zakończenia zakończenia
- Symbol: Pogrubiony okrąg z krzyżykiem (X) lub grubym obramowaniem.
- Zachowanie: Natychmiast zatrzymuje całą instancję procesu, anulując wszystkie aktywne równoległe ścieżki.
- Przypadek użycia: Anulowanie zamówienia, w którym wszystkie kolejne kroki muszą zostać natychmiast anulowane.
📊 Tabela porównawcza zdarzeń
Aby wizualnie przedstawić różnice, odwołaj się do porównania poniżej.
| Cecha | Zdarzenie początkowe | Zdarzenie pośrednie | Zdarzenie końcowe |
|---|---|---|---|
| Kształt | Koło (cienki obramowanie) | Koło (grube obramowanie) | Koło (grube obramowanie) |
| Połączenie przepływu | Tylko jeden przepływ wychodzący | Jeden przepływ przychodzący, jeden wychodzący | Tylko jeden przepływ przychodzący |
| Liczba procesów | Dokładnie jedno na proces | Zero lub więcej na proces | Zero lub więcej na proces |
| Czasowanie | Inicjuje przepływ | Występuje podczas przepływu | Zakończenie przepływu |
| Główna funkcja | Wyzwalacz | Czekaj, wyślij lub obsłuż | Zakończ lub przerwij |
⚠️ Najlepsze praktyki i typowe pułapki
Podczas modelowania złożonych procesów przestrzeganie standardów zapobiega niejasnościom. Oto kluczowe zasady, które pomagają utrzymać przejrzystość i integralność techniczną.
1. Unikaj samotnych zdarzeń
Upewnij się, że każde zdarzenie jest połączone z przepływem. Zdarzenie bez przepływu przychodzącego lub wychodzącego często wskazuje na błąd modelowania. Zdarzenia pośrednie muszą mieć po jednym połączeniu przychodzących i wychodzących, chyba że są przyłączone do granicy zadania.
2. Różnica między typami timera
Nie myl zdarzeń startowych z timera z zdarzeniami pośrednimi z timera.
- Zdarzenie startowe z timera: Proces zaczyna się ponieważ timera.
- Przomoczenie zegara: Proces się zatrzymuje ponieważ timera.
3. Użyj zdarzeń granicznych do obsługi wyjątków
Zamiast tworzyć złożone bramki do sprawdzania błędów, dołącz zdarzenia graniczne błędów do zadań. Dzięki temu ścieżka pozytywna pozostaje jasna, a logika błędów jest wizualnie oddzielona.
4. Zasady nazewnictwa
Jasno oznacz swoje zdarzenia. Zdarzenie „Przechwytywanie wiadomości” powinno być oznaczone nazwą wiadomości (np. „Odbiór potwierdzenia płatności”). Pomaga to stakeholderom zrozumieć, jakie dane są wymagane w tym konkretnym momencie.
5. Ogranicz złożoność sygnałów
Choć sygnały są potężne, ich nadmierne wykorzystanie może utrudnić śledzenie procesu. Sygnały są globalne. Jeśli sygnał zostanie wyemitowany, wiele procesów może na niego odpowiedzieć. Dokumentuj te zależności na diagramie towarzyszącym lub w specyfikacji.
6. Kierunek przepływu sekwencji
Zawsze upewnij się, że przepływ porusza się od Start do End. Zdarzenia pośrednie nigdy nie powinny tworzyć pętli, chyba że zostały jawnie zaprojektowane z użyciem bramek. Nieskończone pętle wskazują na błąd logiki obsługi zdarzeń.
🛠 Uwagi dotyczące wdrożenia
Przekształcanie diagramu w wykonywalny kod wymaga szczególnej uwagi na semantykę zdarzeń.
- Zarządzanie stanem:Zdarzenia pośrednie często wymagają od silnika utrzymania stanu (np. oczekiwanie na wiadomość). Może to wpływać na wydajność, jeśli zbyt wiele procesów oczekuje jednocześnie.
- Zachowanie asynchroniczne:Zdarzenia wiadomości oznaczają komunikację asynchroniczną. System musi obsługiwać kolejki wiadomości i ponowne próby.
- Obsługa wygaśnięcia limitu czasu:Zdarzenia timera muszą być odporności na zmiany zegara lub przestój systemu. Timer ustawiony na 1 godzinę nie powinien zawieść, jeśli system zostanie ponownie uruchomiony na 10 minut.
- Rozprzestrzenianie błędów:Zdarzenia błędów powinny być rozprzestrzeniane w górę hierarchii, jeśli nie są obsługiwane lokalnie. Upewnij się, że warunki brzegowe są poprawnie zdefiniowane.
🔍 Analiza szczegółowego zachowania zdarzeń
Przeanalizujmy subtelności interakcji konkretnych zdarzeń w rzeczywistym scenariuszu.
Scenariusz: Przetwarzanie zamówienia
Wyobraź sobie przepływ pracy do przetwarzania zamówienia klienta. Ten scenariusz wykorzystuje wszystkie trzy typy zdarzeń.
- Start: A Zdarzenie startowe wiadomości otrzymuje ładunek „Nowe zamówienie” z platformy e-commerce.
- Pośredni: Po sprawdzeniu stanu magazynowego, Zdarzenie pośrednie z timera czeka 24 godziny na potwierdzenie płatności. Jeśli płatność nie zostanie otrzymana, Zdarzenie pośrednie wysyłające wiadomość wysyła przypomnienie.
- Koniec: Po potwierdzeniu płatności, Zdarzenie końcowe wiadomości wysyła dane wysyłki do magazynu.
W tym przepływie Zdarzenie pośrednie z timera działa jak strażnik. Jeśli timer wygaśnie, przepływ przechodzi do alternatywnej ścieżki (Przypomnienie). Jeśli wiadomość zostanie otrzymana przed wygaśnięciem timera, przepływ kontynuuje się do Zdarzenia końcowego.
Obsługa zdarzeń współbieżnych
Co się stanie, jeśli proces oczekuje na wiadomość, ale wystąpi błąd? Oto gdzie wchodzą w grę procesy podzdarzeń. Proces podzdarzeń pozwala zdefiniować osobną ścieżkę wyzwalaną zdarzeniem, niezależnie od głównego przepływu. Jest to kluczowe dla utrzymania stabilności w przypadku nieoczekiwanych zdarzeń.
- Wyzwalacz procesu podzdarzeń: Może być tylko Zdarzeniem pośrednim odbierającym (Błąd, Timer, Wiadomość, Sygnał, Utrudnienie).
- Wykonanie: Działa współbieżnie z głównym procesem.
- Zakres: Jest zawarte w głównym procesie, ale ma własny wewnętrzny przepływ.
🔗 Zdarzenia połączeń i połączenia
Zdarzenia połączeń to unikalna podgrupa zdarzeń pośrednich używanych do łączenia przepływów, które fizycznie są od siebie oddalone na schemacie, lub do zarządzania skomplikowaną logiką pętli.
- Wyrzucanie połączenia: Działa jako znacznik docelowy.
- Odbieranie połączenia: Działa jako znacznik źródłowy.
Choć zmniejszają potrzebę krzyżowania się linii, nadmierne ich wykorzystanie może utrudnić odczyt diagramu. Używaj ich oszczędnie, aby zachować intuicyjny przepływ wizualny.
📝 Podsumowanie kluczowych wniosków
Opanowanie subtelności zdarzeń BPMN jest kluczowe do tworzenia solidnych modeli procesów. Zdarzenia startowe definiują wejście, zdarzenia pośrednie zarządzają przepływem i przerwaniami, a zdarzenia końcowe definiują wyjście.
- Spójność:Przestrzegaj standardowych kształtów. Nie mieszaj dowolnie cienkich i grubych obramowań.
- Jasność:Nazwij swoje zdarzenia na podstawie działania, a nie kształtu.
- Logika:Upewnij się, że każdy przepływ kończy się zakończeniem lub poprawnym pętlą.
- Weryfikacja:Sprawdź, czy każde zdarzenie Start i End jest unikalne dla każdego wystąpienia procesu.
Stosując te zasady, architekci procesów mogą tworzyć modele, które są nie tylko wizualnie jasne, ale także technicznie poprawne dla silników wykonawczych. Różnica między oczekiwaniem (przyjmowaniem) a działaniem (wyrzucaniem) pozostaje najważniejszym pojęciem do internalizacji.
