Brány v BPMN

Vykonávací model BPMN je token, který se pohybuje diagramem. Gateway je jediná věc, která mění počet tokenů: rozdělení umí z jednoho tokenu udělat několik, sloučení je umí proměnit zpět v jeden. Všechno ostatní o gateway z toho vyplývá.

Poznámka k názvu. Specifikace říká gateway; většina lidí řekne brána a hledá brány. Je to tatáž věc a kosočtverec je tentýž kosočtverec - ale do názvu diagramu patří gateway, protože to je slovo, které bude číst každý BPMN nástroj i každý recenzent.

Dva důsledky stojí za zapamatování. Za prvé, gateway nedělá žádnou práci - vyhodnocuje podmínky, které už někdo spočítal, a chcete-li něco ověřit, je to úloha před gateway. Za druhé, rozdělení obvykle potřebuje odpovídající sloučení stejného druhu, protože to, co vytvořilo tokeny navíc, je musí zase spojit, jinak doběhnou do konce zvlášť.

Tentýž symbol dělá obě úlohy a to, kterou zrovna dělá, závisí jen na tom, zda má víc odchozích nebo víc příchozích toků. Gateway s jedním vstupem a třemi výstupy je rozdělení; tři dovnitř a jeden ven je sloučení.

Slovník je třeba ustálit, protože pro sbíhající případ se používají tři slova. Sbíhající paralelní gateway je join: čeká na každou větev. Sbíhající exkluzivní gateway je merge: nečeká na nic a propustí každý token. Obě se kreslí jako tentýž kosočtverec jako při rozdělení, a nazvat merge joinem je způsob, jakým diagram začne tvrdit, že se dokončila práce, která nikdy neběžela.

Všechno ze dvou sekcí výše je jedna dovednost: položte prst na startovací událost a počítejte. Tady je proces pojistné události z vrcholu této stránky, projitý krok za krokem, s počtem živých tokenů po každém z nich.

1. Nastane „Claim received“. Jeden token. Sedí na toku do první gateway.
2. Paralelní rozdělení. Dva tokeny. Nevyhodnocují se žádné podmínky a nic se nevybírá - paralelní rozdělení vydá vždy jeden token na každý odchozí tok.
3. Kontrola pojistky i kontrola podvodu běží. Stále dva. Jsou opravdu souběžné: diagram netvrdí nic o tom, která skončí dřív, a ani to nepotřebuje.
4. Paralelní join. Zpět na jeden. Token, který přijde první, tam počká. Když přijde druhý, join oba spotřebuje a vydá jeden.
5. „Covered?“ Jeden token, jedna větev. Exkluzivní gateway počet nikdy nemění - mění jen to, na kterém toku token je.
6. Vyplatit nebo zamítnout, pak konec. Nula. Instance procesu je hotová, když poslední token spotřebuje koncová událost.

Teď to záměrně pokazte, protože obě klasické chyby jsou vidět už ze samotného počítání.

Udělejte první gateway exkluzivní a join nechte paralelní. Rozdělení teď vydá jeden token, takže proběhne jedna kontrola. Paralelní join stále čeká na dva. Na druhém toku nikdy nic nepřijde a pojistná událost zůstane v joinu po celou životnost systému. To je ten deadlock - a stačila jedna změněná značka.

Nechte rozdělení paralelní a udělejte join exkluzivní. Přijdou dva tokeny a exkluzivní sloučení nečeká na nic, takže oba projdou rovnou. „Covered?“ se vyhodnotí dvakrát, úloha vyplacení proběhne dvakrát a zákazník dostane zaplaceno dvakrát. Tohle je horší než deadlock, protože deadlock se ohlásí sám a dvojitá platba ne.

Tohle je konstrukce, díky které jde „čekáme na dokumenty, ale ne donekonečna“ vyjádřit jedním obrázkem. Každý jiný způsob, jak to nakreslit - hraniční časovací událost na čekací úloze, cyklus s podmínkou - buď zdvojuje logiku vypršení, nebo ji skrývá.

Jdou s ní dvě pravidla. Cíli event-based gateway musí být zachytávající mezilehlé události nebo receive úlohy, nikdy obyčejné úlohy: gateway je závod mezi věcmi, které přicházejí, a úloha nepřichází. A větve musí být v čase opravdu vzájemně výlučné, což jsou automaticky - první, která nastane, ostatní zahodí.

Podmínky žijí na odchozích sekvenčních tocích, ne na gateway. Pište je jako krátké výrazy, které čtenář umí vyhodnotit - amount > 10000, policy status = active - a dejte je na čáru blíž ke gateway než k cíli.

Právě jedna větev větvící gateway by měla být výchozí tok, kreslený s malou čárkou přes ocas. Vybere se tehdy, když neplatí žádná jiná podmínka, a je to to, co zabrání, aby proces uvázl na gateway, kde se data ukázala být něčím, co nikdo nepředvídal.

Modelář, který se naučil gateway, po nich sahá u každého větvení na světě a výsledkem je diagram, který je ze 40 % kosočtverec. Čtyři další konstrukce BPMN vyjádří rozhodnutí v následujících případech lépe a jejich znalost je většina rozdílu mezi procesním modelem, který se vejde na stránku, a tím, který ne.

Test je, zda je větvení součástí procesu, nebo součástí rozhodnutí. Pojistná událost, která jde na rychlou linku nebo na manuální kontrolu, je proces: obě cesty vypadají jinak a čtenář potřebuje vidět obě. To, do kterého z devíti rizikových pásem událost patří, je rozhodnutí: cesty jsou pak identické a dát to na diagram stojí osm kosočtverců za jednu větu. Podívejte se na jak nakreslit BPMN diagram, kde ta hranice v praxi obvykle leží.

1. Paralelní rozdělení, exkluzivní sloučení. Rozdělení vyrobilo dva tokeny; exkluzivní sloučení oba propustí a všechno za ním se stane dvakrát.
2. Inkluzivní rozdělení, paralelní sloučení. Deadlock z výše uvedeného. Slaďte své gateway.
3. Práce uvnitř gateway. Kosočtverec s popisem „Ověřit a směrovat“ je úloha a gateway v jednom obrysu. Rozdělte je.
4. Neoznačené větve. Dvě čáry odcházející z kosočtverce bez popisu nutí čtenáře hádat a polovina z nich uhodne špatně.
5. Žádný výchozí tok. Přijde ten jeden vstup, na který nikdo nemyslel, a token nemá kam jít.
6. Obyčejné úlohy za event-based gateway. Není to legální a obvykle to znamená, že se myslela exkluzivní gateway.

Gateway a události jsou dvě poloviny řízení toku v BPMN: gateway rozhodují, události čekají a přerušují. Proces modelovaný jen pomocí gateway má sklon růst do dlouhých řetězců dotazování; ten, který použije hraniční události tam, kde má, zůstává mnohem blíž tomu, co se opravdu děje.