Bramka nie jest ozdobnym rombem ani synonimem decyzji. Steruje tokenami procesu: rozdziela przepływ na alternatywy lub równoległe ścieżki, a przy łączeniu ustala, na co trzeba poczekać. Najczęstsze błędy powstają wtedy, gdy autor dobiera symbol do wyglądu diagramu, a nie do zachowania procesu.
| Bramka | Split: ile ścieżek uruchamia? | Join: na co czeka? | Typowy przykład |
|---|---|---|---|
| XOR — wykluczająca | Dokładnie jedna spełniająca warunek | Nie synchronizuje; przepuszcza token | Wniosek zaakceptowany albo odrzucony |
| AND — równoległa | Wszystkie wychodzące | Na token z każdej przychodzącej | Równoległa kontrola prawna i finansowa |
| OR — inkluzywna | Jedna lub więcej spełniających warunek | Na wszystkie ścieżki aktywowane w danej instancji | Wymagane wybrane zestawy ekspertyz |
| Event-based | Jedna — wygrywa pierwsze zdarzenie | Nie służy do łączenia | Odpowiedź klienta albo upływ terminu |
XOR: decyzja na podstawie danych
Przy bramce wykluczającej ocenia się warunki i wybiera jedną ścieżkę. Warunki powinny być wzajemnie rozłączne lub mieć określoną kolejność oceny. Dobrą praktyką jest ścieżka domyślna, gdy żadna reguła nie pasuje. Dla decyzji „kwota do 10 000 / kwota powyżej 10 000” granica jest jasna; etykiety „mała / duża” wymagają zewnętrznej definicji.
XOR-join nie czeka na alternatywne ścieżki. Każdy docierający token przepuszcza dalej. Jeśli wcześniej AND utworzył dwa tokeny, połączenie ich XOR-em uruchomi kolejne zadanie dwukrotnie. Symetryczny rysunek nie gwarantuje poprawnej synchronizacji.
AND: wszystkie ścieżki i pełna synchronizacja
AND-split kopiuje token na każdą gałąź bez sprawdzania warunków. AND-join czeka na token ze wszystkich przychodzących przepływów. Jeśli jedna gałąź może nigdy nie zostać uruchomiona, join będzie czekał bez końca. Dlatego nie wolno używać AND-join do łączenia opcjonalnych ścieżek wybranych przez XOR.
Przykład: po rejestracji dostawcy zawsze wykonywane są kontrola sankcyjna i weryfikacja rachunku. Dopiero obie pozytywne kontrole pozwalają aktywować dostawcę. Jeżeli jedna kontrola kończy całą instancję zdarzeniem końcowym typu terminate, trzeba świadomie opisać konsekwencję dla drugiej pracy.
OR: dowolny niepusty zestaw ścieżek
OR-split może uruchomić jedną, kilka albo — przy błędnych warunkach — żadną gałąź. Warto zdefiniować ścieżkę domyślną. OR-join czeka na wszystkie tokeny, które mogą jeszcze dotrzeć z gałęzi aktywowanych w tej instancji. To zachowanie jest bardziej złożone niż AND i XOR; stosuj OR tylko wtedy, gdy biznes rzeczywiście dopuszcza wiele niezależnych kombinacji.
Event-based: wynik zależy od tego, co zdarzy się pierwsze
Bramka oparta na zdarzeniach nie sprawdza danych. Proces czeka na alternatywne zdarzenia, np. wiadomość od klienta albo timer 48 godzin. Pierwsze zdarzenie kontynuuje proces, pozostałe oczekiwania są anulowane. Za bramką powinny znajdować się zdarzenia wychwytujące lub zadania odbioru, nie zwykłe zadania biznesowe.
Przypadek: ocena szkody ubezpieczeniowej
Po rejestracji szkody XOR rozdziela sprawy kompletne od wymagających uzupełnienia. Dla kompletnej sprawy OR uruchamia ekspertyzy zależnie od rodzaju szkody: rzeczoznawcę, kontrolę antyfraudową i opinię medyczną. Jedna szkoda może wymagać dwóch z nich. OR-join czeka tylko na zlecone ekspertyzy. Następnie AND uruchamia równolegle wyliczenie świadczenia i przygotowanie uzasadnienia; AND-join synchronizuje oba wyniki.
Ślad tokenów
Sprawa S-17: kompletna → aktywne „rzeczoznawca” i „antyfraud” → dwa tokeny wracają do OR-join → jeden token po joinie → AND tworzy dwa tokeny → wyliczenie i uzasadnienie → AND-join czeka na oba → decyzja. Taki zapis pozwala zweryfikować, czy następny krok wykona się raz i we właściwym momencie.
Checklista bramki
- Czy wybór wynika z danych (XOR/OR), czy z pierwszego zdarzenia (event-based)?
- Czy może ruszyć jedna, wszystkie, czy kilka ścieżek?
- Czy warunki pokrywają pełny zakres i mają jednoznaczne granice?
- Czy join czeka dokładnie na tokeny, które zostały uruchomione?
- Czy każdą kombinację da się zakończyć bez zakleszczenia lub podwójnego wykonania?
Warunki i przepływ domyślny
Warunek powinien być zapisany jako stwierdzenie dotyczące danych, np. „kwota > 10 000 PLN”, a nie jako polecenie „sprawdź kwotę”. W XOR tylko jedna ścieżka może wygrać. Jeśli reguły nakładają się, trzeba ustalić kolejność albo przepisać przedziały. W OR nakładanie jest zamierzone, ponieważ każda prawdziwa reguła aktywuje własną gałąź. Przepływ domyślny obsługuje sytuację, w której żaden warunek nie pasuje; nie powinien ukrywać brakującej reguły biznesowej.
Tabela testowa dla split/join
| Dane przypadku | Aktywne gałęzie | Tokeny oczekiwane na joinie |
|---|---|---|
| Ryzyko niskie, szkoda rzeczowa | Rzeczoznawca | 1 z rzeczoznawcy |
| Ryzyko wysokie, szkoda rzeczowa | Rzeczoznawca + antyfraud | 2, po jednym z obu gałęzi |
| Ryzyko wysokie, szkoda osobowa | Medyczna + antyfraud | 2, po jednym z obu gałęzi |
Jeżeli przewidywana liczba tokenów nie zgadza się z zachowaniem joinu, diagram wymaga korekty. Tabela jest też dobrym punktem wyjścia do testów procesu.
Czy każda decyzja potrzebuje bramki?
Nie. Jeżeli zadanie ma kilka wyjść warunkowych, bramka może poprawić czytelność, ale semantycznie warunki można umieścić na przepływach. Bramki warto stosować jawnie, gdy trzeba rozdzielić odpowiedzialność za pracę od reguły sterującej albo później zsynchronizować ścieżki. Nie wstawiaj bramki AND przed każdą parą strzałek, jeżeli niezależne przepływy wynikają już z semantyki zdarzenia lub aktywności.
Złożone reguły lepiej utrzymywać w tabeli decyzyjnej i na diagramie wskazać jej wynik. BPMN pokazuje konsekwencję wyniku, a tabela zapewnia kompletność kombinacji. Dzięki temu zmiana progu nie wymaga przebudowy obrazu, ale nadal uruchamia analizę wpływu na ścieżki.
Przed publikacją odegraj diagram dla każdej kombinacji warunków. Jeśli dopiero zaczynasz, wróć do podstaw w BPMN dla początkujących. Zdarzenia używane za event-based gateway wyjaśnia materiał zdarzenia BPMN.
