Brány v BPMN

Vykonávací model BPMN je token, ktorý sa pohybuje diagramom. Gateway je jediná vec, ktorá mení počet tokenov: rozdelenie vie z jedného tokenu urobiť niekoľko, zlúčenie ich vie premeniť späť na jeden. Všetko ostatné o gateway z toho vyplýva.

Poznámka k názvu. Špecifikácia hovorí gateway; väčšina ľudí povie brána a hľadá brány. Je to tá istá vec a kosoštvorec je ten istý kosoštvorec - ale do názvu diagramu patrí gateway, lebo to je slovo, ktoré bude čítať každý BPMN nástroj aj každý recenzent.

Dva dôsledky stoja za zapamätanie. Po prvé, gateway nerobí žiadnu prácu - vyhodnocuje podmienky, ktoré už niekto vypočítal, a ak chcete niečo overiť, je to úloha pred gateway. Po druhé, rozdelenie zvyčajne potrebuje zodpovedajúce zlúčenie rovnakého druhu, pretože to, čo vytvorilo tokeny navyše, ich musí zase spojiť, inak dobehnú do konca zvlášť.

Ten istý symbol robí obe úlohy a to, ktorú práve robí, závisí len od toho, či má viac odchádzajúcich alebo viac prichádzajúcich tokov. Gateway s jedným vstupom a tromi výstupmi je rozdelenie; tri dnu a jeden von je zlúčenie.

Slovník si treba ustáliť, lebo na zbiehajúci prípad sa používajú tri slová. Zbiehajúca paralelná gateway je join: čaká na každú vetvu. Zbiehajúca exkluzívna gateway je merge: nečaká na nič a prepustí každý token. Obe sa kreslia ako ten istý kosoštvorec ako pri rozdelení, a nazvať merge joinom je spôsob, akým diagram začne tvrdiť, že sa dokončila práca, ktorá nikdy nebežala.

Všetko z dvoch sekcií vyššie je jedna zručnosť: položte prst na štartovaciu udalosť a počítajte. Tu je proces poistnej udalosti z vrchu tejto stránky, prejdený krok po kroku, s počtom živých tokenov po každom z nich.

1. Nastane „Claim received“. Jeden token. Sedí na toku do prvej gateway.
2. Paralelné rozdelenie. Dva tokeny. Nevyhodnocujú sa žiadne podmienky a nič sa nevyberá - paralelné rozdelenie vydá vždy jeden token na každý odchádzajúci tok.
3. Kontrola poistky aj kontrola podvodu bežia. Stále dva. Sú naozaj súbežné: diagram netvrdí nič o tom, ktorá skončí skôr, a ani to nepotrebuje.
4. Paralelný join. Späť na jeden. Token, ktorý príde prvý, tam počká. Keď príde druhý, join oba spotrebuje a vydá jeden.
5. „Covered?“ Jeden token, jedna vetva. Exkluzívna gateway počet nikdy nemení - mení len to, na ktorom toku token je.
6. Vyplatiť alebo zamietnuť, potom koniec. Nula. Inštancia procesu je hotová, keď posledný token spotrebuje koncová udalosť.

Teraz to zámerne pokazte, lebo obe klasické chyby vidno už zo samotného počítania.

Urobte prvú gateway exkluzívnou a join nechajte paralelný. Rozdelenie teraz vydá jeden token, takže zbehne jedna kontrola. Paralelný join stále čaká na dva. Na druhom toku nikdy nič nepríde a poistná udalosť ostane v joine po celú životnosť systému. To je ten deadlock - a stačila jedna zmenená značka.

Nechajte rozdelenie paralelné a urobte join exkluzívnym. Prídu dva tokeny a exkluzívne zlúčenie nečaká na nič, takže oba prejdú rovno. „Covered?“ sa vyhodnotí dvakrát, úloha vyplatenia zbehne dvakrát a zákazník dostane zaplatené dvakrát. Toto je horšie než deadlock, lebo deadlock sa ohlási sám a dvojitá platba nie.

Toto je konštrukcia, vďaka ktorej sa „čakáme na dokumenty, ale nie donekonečna“ dá vyjadriť jedným obrázkom. Každý iný spôsob, ako to nakresliť - hraničná časovacia udalosť na čakacej úlohe, cyklus s podmienkou - buď zdvojuje logiku vypršania, alebo ju skrýva.

Idú s ňou dve pravidlá. Cieľmi event-based gateway musia byť zachytávajúce medziľahlé udalosti alebo receive úlohy, nikdy obyčajné úlohy: gateway je preteky medzi vecami, ktoré prichádzajú, a úloha neprichádza. A vetvy musia byť v čase naozaj navzájom výlučné, čo sú automaticky - prvá, ktorá nastane, ostatné zahodí.

Podmienky žijú na odchádzajúcich sekvenčných tokoch, nie na gateway. Píšte ich ako krátke výrazy, ktoré vie čitateľ vyhodnotiť - amount > 10000, policy status = active - a dajte ich na čiaru bližšie ku gateway než k cieľu.

Práve jedna vetva vetviacej gateway by mala byť predvolený tok, kreslený s malou čiarkou cez chvost. Vyberie sa vtedy, keď neplatí žiadna iná podmienka, a je to to, čo zabráni, aby proces uviazol na gateway, kde sa dáta ukázali byť niečím, čo nikto nepredvídal.

Modelár, ktorý sa naučil gateway, po nich siaha pri každom vetvení na svete a výsledkom je diagram, ktorý je zo 40 % kosoštvorec. Štyri ďalšie konštrukcie BPMN vyjadria rozhodnutie v nasledujúcich prípadoch lepšie a ich znalosť je väčšina rozdielu medzi procesným modelom, ktorý sa zmestí na stranu, a tým, ktorý nie.

Test je, či je vetvenie súčasťou procesu, alebo súčasťou rozhodnutia. Poistná udalosť, ktorá ide na rýchlu linku alebo na manuálnu kontrolu, je proces: obe cesty vyzerajú inak a čitateľ potrebuje vidieť obe. To, do ktorého z deviatich rizikových pásiem udalosť patrí, je rozhodnutie: cesty sú potom identické a dať to na diagram stojí osem kosoštvorcov za jednu vetu. Pozrite si ako nakresliť BPMN diagram, kde tá hranica v praxi zvyčajne leží.

1. Paralelné rozdelenie, exkluzívne zlúčenie. Rozdelenie vyrobilo dva tokeny; exkluzívne zlúčenie oba prepustí a všetko za ním sa stane dvakrát.
2. Inkluzívne rozdelenie, paralelné zlúčenie. Deadlock z vyššie uvedeného. Zlaďte svoje gateway.
3. Práca vnútri gateway. Kosoštvorec s popisom „Overiť a smerovať“ je úloha a gateway v jednom obryse. Rozdeľte ich.
4. Neoznačené vetvy. Dve čiary odchádzajúce z kosoštvorca bez popisu nútia čitateľa hádať a polovica z nich uhádne zle.
5. Žiadny predvolený tok. Príde ten jeden vstup, na ktorý nikto nemyslel, a token nemá kam ísť.
6. Obyčajné úlohy za event-based gateway. Nie je to legálne a zvyčajne to znamená, že sa myslela exkluzívna gateway.

Gateway a udalosti sú dve polovice riadenia toku v BPMN: gateway rozhodujú, udalosti čakajú a prerušujú. Proces modelovaný len pomocou gateway má sklon rásť do dlhých reťazcov dopytovania; ten, ktorý použije hraničné udalosti tam, kde má, ostáva oveľa bližšie k tomu, čo sa naozaj deje.