6 Wyjątki i podprocesy

Efekty uczenia się: W3, W4, U3, U7 · Treści programowe: 5, 6 · Czas: Nauka 40 min, Wyzwanie 50 min

6.1 Nauka

Ścieżka szczęśliwa i wyjątki

Każdy proces ma przebieg, na który liczą wszyscy: czytelnik zamawia książkę, książka przychodzi, czytelnik ją odbiera. To tak zwana ścieżka szczęśliwa (happy path). W rzeczywistości sprawy często idą inaczej. Czytelnik nie przychodzi po książkę. System nie zapisuje rekordu. Poszukiwania w archiwum trwają dłużej, niż przewiduje termin. Wnioskodawca wycofuje wniosek w połowie sprawy.

Takie sytuacje nazywamy wyjątkami. Model analityczny musi je pokazywać, bo właśnie w wyjątkach proces najczęściej traci czas i informację. Pracownik, który nie wie, co zrobić z nieodebraną książką, odkłada ją „na później”. Po miesiącu nikt już nie pamięta, czyja to była sprawa.

Początkujący modelują wyjątki bramkami: „Czy minął termin?”, „Czy wystąpił błąd?”. To błąd myślowy. Bramka sprawdza stan w jednej chwili, gdy proces do niej dociera. Termin może jednak minąć w trakcie pracy, a błąd pojawia się podczas wykonywania zadania. Do tego służą zdarzenia graniczne, podprocesy i podprocesy zdarzeniowe.

Zdarzenie graniczne

Zdarzenie graniczne (boundary event) to kółko z podwójną linią przyczepione do krawędzi zadania albo podprocesu. Znaczy: „jeśli w czasie wykonywania tej czynności zajdzie to zdarzenie, proces pójdzie ścieżką wychodzącą z kółka”. Zasady są proste:

zdarzenie graniczne wisi na zadaniu lub podprocesie, nigdy na bramce ani na innym zdarzeniu;
nie wchodzi do niego żadna strzałka (E012), bo uruchamia je samo zdarzenie, a nie poprzedni krok;
wychodzi z niego dokładnie jedna ścieżka, która prowadzi dalej, czasem do osobnego końca.

Najczęściej spotkasz trzy wyzwalacze na krawędzi zadania: czas (termin minął), wiadomość (ktoś coś przysłał w trakcie pracy) i błąd (czynność się nie udała).

Przerywające czy nieprzerywające

Najważniejsze pytanie przy każdym zdarzeniu granicznym brzmi: co dzieje się z zadaniem, gdy zdarzenie zajdzie?

Wygląd	Rodzaj	Co dzieje się z zadaniem	Słowa w opisie procesu
ciągła podwójna linia	przerywające (interrupting)	zadanie zostaje przerwane i odebrane; proces idzie tylko ścieżką wyjątku	„zadanie zostaje mu odebrane”, „sprawa wygasa”, „rezerwacja zostaje anulowana”
przerywana podwójna linia	nieprzerywające (non-interrupting)	zadanie trwa dalej; równolegle rusza dodatkowa ścieżka	„zadanie nadal zostaje u niego”, „jednocześnie wysyłane jest przypomnienie”, „praca trwa dalej”

W pliku BPMN różnica sprowadza się do jednego atrybutu: zdarzenie nieprzerywające ma cancelActivity="false". Na rysunku widać ją po linii kółka. Dlatego tak ważne jest czytanie opisu procesu słowo po słowie. „Po trzech dniach przełożony dostaje przypomnienie” i „po trzech dniach sprawa przechodzi do zastępcy” to dwa różne modele.

Przyjrzyj się dalszemu ciągowi wypożyczenia międzybibliotecznego. Książka przyszła z innej biblioteki i czeka na czytelnika przy ladzie.

Rysunek 6.1: Odbiór książki z wypożyczenia międzybibliotecznego: błąd zapisu, przypomnienie i termin odbioru jako zdarzenia graniczne.

Pobierz model (.bpmn)

Na diagramie widać trzy zdarzenia graniczne:

Błąd zapisu rekordu na zadaniu usługowym „Rejestracja egzemplarza w systemie”. Jeśli system nie zapisze rekordu, rejestracja automatyczna zostaje przerwana, a bibliotekarz rejestruje egzemplarz ręcznie. Obie drogi spotykają się na bramce scalającej i proces idzie dalej tak samo.
Minęły 4 dni (nieprzerywające) na zadaniu „Wydanie książki czytelnikowi”. Zadanie dalej czeka w kolejce bibliotekarza, a system wysyła czytelnikowi przypomnienie. Ścieżka przypomnienia kończy się własnym zdarzeniem końcowym.
Minęło 7 dni (przerywające) na tym samym zadaniu. Zadanie zostaje odebrane z kolejki, a książka wraca do biblioteki, która ją udostępniła.

Zwróć uwagę, że zadanie „Wydanie książki czytelnikowi” trwa od chwili, gdy pojawia się w kolejce bibliotekarza, do chwili, gdy czytelnik przychodzi i odbiera książkę. Zegary liczą czas właśnie od początku tego zadania.

Błąd zawsze przerywa

Błąd (error) oznacza, że czynność nie może się zakończyć normalnie. Dlatego graniczne zdarzenie błędu jest zawsze przerywające. Walidator zgłosi nieprzerywający błąd jako E012. Jeśli w opisie czytasz, że coś „się nie udało, a praca toczy się dalej”, to nie jest błąd w rozumieniu BPMN. Może to być eskalacja albo zwykła bramka po zakończonym zadaniu („Czy zapis się powiódł?”).

Błąd w BPMN dotyczy przebiegu procesu, a nie pomyłki człowieka. Literówka w nazwisku czytelnika nie jest zdarzeniem błędu, tylko powodem do poprawki. Zdarzenie błędu modeluje sytuację, w której czynność zostaje zerwana: system nie zapisał rekordu, płatność nie przeszła, plik okazał się uszkodzony.

Każdy błąd ma deklarację na poziomie całego modelu (<bpmn:error>) z nazwą i kodem. Zdarzenie graniczne wskazuje ją atrybutem errorRef. Dzięki temu można odróżnić od siebie różne błędy tej samej czynności i obsłużyć je różnymi ścieżkami.

Podproces

Podproces (sub-process) to czynność złożona z kilku kroków, które tworzą całość. Na diagramie ogólnym może być widoczny na dwa sposoby:

zwinięty (collapsed): mały prostokąt z plusem w kwadracie na dole; szczegóły są na osobnym diagramie;
rozwinięty (expanded): duży prostokąt, w którym widać kroki.

Podproces ma własny start i własny koniec. Start wewnątrz zwykłego podprocesu jest pusty, bez wyzwalacza (E010), bo podproces uruchamia strzałka z procesu głównego. Strzałki procesu głównego nie wchodzą do środka podprocesu (E006). Wchodzą do jego krawędzi, a wychodzą z niej, gdy wewnątrz podprocesu wszystkie ścieżki dojdą do końca.

Po co dzielić model na podprocesy? Są trzy powody:

czytelność: diagram główny mieści się na ekranie i pokazuje etapy, a nie każdy krok;
wspólna obsługa wyjątku: jedno zdarzenie graniczne na krawędzi podprocesu obejmuje wszystkie kroki wewnątrz, np. jeden termin na cały etap poszukiwań;
odpowiedzialność: podproces często odpowiada etapowi, za który odpowiada jedna osoba albo zespół.

Eskalacja: sprawa idzie wyżej, praca trwa

Eskalacja (escalation) to zgłoszenie sprawy osobie wyżej w hierarchii. W przeciwieństwie do błędu praca zwykle się nie zatrzymuje. Ktoś po prostu musi się dowiedzieć o problemie i coś zrobić.

Eskalacja ma w BPMN dwie strony:

wewnątrz podprocesu stoi zdarzenie rzucające eskalację (wypełniona strzałka w górę), pośrednie albo końcowe;
na krawędzi tego podprocesu wisi graniczne zdarzenie eskalacji, które ją łapie. Oba wskazują tę samą deklarację escalationRef.

Jeśli eskalacji nic nie łapie, walidator zgłosi W053. Jeśli na podprocesie wisi zdarzenie eskalacji, ale nic wewnątrz go nie rzuca, zobaczysz W052. Graniczne zdarzenie eskalacji bywa przerywające albo nieprzerywające. W praktyce częściej spotyka się nieprzerywające: „kierownik zostaje powiadomiony, a poszukiwania trwają dalej”.

Podproces zdarzeniowy

Niektóre zdarzenia mogą nastąpić w dowolnym momencie trwania procesu, niezależnie od tego, na jakim jest etapie. Wnioskodawca może wycofać wniosek o kwerendę zaraz po złożeniu albo tuż przed wysłaniem odpowiedzi. Zdarzenia granicznego nie da się powiesić na wszystkich zadaniach naraz. Do takich sytuacji służy podproces zdarzeniowy (event sub-process).

Podproces zdarzeniowy rysuje się jako prostokąt z kropkowaną krawędzią wewnątrz procesu. Ma trzy cechy:

nie wchodzi do niego i nie wychodzi z niego żadna strzałka (E013);
ma dokładnie jeden start, i to start z wyzwalaczem: wiadomością, sygnałem, czasem, błędem albo eskalacją (E013);
jest przerywający (start z ciągłą linią) albo nieprzerywający (start z przerywaną linią).

Przerywający podproces zdarzeniowy kończy resztę procesu, w którym się znajduje. Nieprzerywający działa obok. Na przykład zapytanie wnioskodawcy „na jakim etapie jest moja sprawa?” obsługujemy, a kwerenda trwa dalej.

Oba mechanizmy, eskalację i podproces zdarzeniowy, widać na modelu kwerendy archiwalnej:

Rysunek 6.2: Kwerenda archiwalna: podproces poszukiwań z eskalacją do kierownika oddziału oraz podproces zdarzeniowy dla wycofania wniosku.

Pobierz model (.bpmn)

Prześledź model krok po kroku:

Kancelaria rejestruje wniosek, a archiwista rozpoczyna podproces Poszukiwania w zasobie.
Jeśli akt nie ma w inwentarzach, archiwista rzuca eskalację „Zgłoszenie szerszych poszukiwań” i przeszukuje zespoły pokrewne.
Eskalację łapie nieprzerywające zdarzenie na krawędzi podprocesu. Kierownik oddziału wyznacza nowy termin odpowiedzi i zawiadamia o nim wnioskodawcę. Poszukiwania trwają w tym czasie dalej. Tak samo działa w praktyce zawiadomienie o niezałatwieniu sprawy w terminie.
Podproces zdarzeniowy Wycofanie wniosku uruchamia wiadomość od wnioskodawcy. Jego start jest przerywający, więc wycofanie kończy całą kwerendę, a pracownik kancelarii zamyka sprawę w rejestrze.

Koniec natychmiastowy

Zwykłe zdarzenie końcowe kończy jedną ścieżkę. Jeśli proces ma kilka równoległych ścieżek, pozostałe trwają dalej, a proces kończy się dopiero wtedy, gdy wszystkie dojdą do końca.

Koniec natychmiastowy (terminate end event, grube kółko z czarną kropką w środku) kończy cały proces od razu, łącznie ze wszystkimi trwającymi ścieżkami. Używaj go oszczędnie. Pasuje tam, gdzie opis mówi „sprawa zostaje zamknięta niezależnie od tego, co jeszcze trwa”, np. gdy zamawiający rezygnuje, a równolegle trwają już wycena i przygotowanie obiektu do skanowania. Jeśli wszystkie ścieżki i tak kończą się same, koniec natychmiastowy niczego nie wnosi i tylko utrudnia czytanie modelu.

Kompensacja: cofnięcie skutków

Czasem trzeba cofnąć coś, co już się wydarzyło. Biblioteka zarezerwowała salę na spotkanie autorskie, a autor odwołał przyjazd. Rezerwacja została już zrobiona, więc nie da się jej „przerwać”. Trzeba ją anulować. Do takich sytuacji służy kompensacja (compensation):

na zadaniu „Rezerwacja sali” wisi graniczne zdarzenie kompensacji (dwa trójkąty skierowane w lewo);
zdarzenie to łączy się asocjacją (linia kropkowana, nie strzałka) z czynnością kompensacyjną „Anulowanie rezerwacji”, oznaczoną tym samym symbolem;
czynność kompensacyjna nie ma żadnych przepływów sekwencji (E014);
kompensację uruchamia w innym miejscu procesu zdarzenie rzucające kompensację.

Kompensacja działa tylko dla zadań, które już się zakończyły. Na tym kursie wystarczy, że rozpoznasz ją na diagramie i wiesz, czym różni się od przerwania. Przerwanie zatrzymuje pracę, która trwa. Kompensacja cofa skutki pracy już wykonanej.

Czynność wywołania

Niektóre fragmenty powtarzają się w wielu procesach. Pobranie opłaty od czytelnika występuje w wypożyczeniu międzybibliotecznym, w zamówieniu skanów i przy wydaniu duplikatu karty. Zamiast rysować go trzy razy, można opisać go raz jako osobny proces i wywoływać go czynnością wywołania (call activity). Na diagramie wygląda jak podproces, ale ma grubą ramkę.

Różnica między podprocesem a czynnością wywołania jest ważna dla organizacji. Podproces należy do jednego procesu i zmienia się razem z nim. Proces wywoływany jest wspólny. Jego zmiana, np. nowy sposób płatności, od razu dotyczy wszystkich procesów, które go używają.

Jak rozpoznać wyjątek w opisie

Słowa w opisie	Element
„jeśli w ciągu N dni nie…, zadanie zostaje odebrane / sprawa wygasa”	graniczne zdarzenie czasowe przerywające
„po N dniach przypomnienie, a zadanie nadal zostaje u niego”	graniczne zdarzenie czasowe nieprzerywające
„jeśli system zgłosi błąd, czynność zostaje przerwana”	graniczne zdarzenie błędu
„kroki tworzą zamkniętą całość z własnym początkiem i końcem”	podproces
„blok zgłasza na zewnątrz, że sprawa wymaga interwencji wyżej”	eskalacja rzucana wewnątrz podprocesu i łapana na jego krawędzi
„w dowolnym momencie trwania procesu”, „niezależnie od etapu”	podproces zdarzeniowy
„cofnij / anuluj to, co już zostało zrobione”	kompensacja
„ten sam fragment jest wspólny dla kilku procesów”	czynność wywołania

6.2 Wyzwanie

Polecenie: zbuduj w Camunda Modeler model procesu „Digitalizacja na zamówienie” z tabeli kroków poniżej. Opisy nie nazywają elementów BPMN. Wywnioskuj je ze sformułowań.

Dane wejściowe: Pracownia Digitalizacji biblioteki uniwersyteckiej wykonuje skany obiektów ze zbiorów specjalnych na zamówienie osób z zewnątrz. Zamawiający jest osobą spoza biblioteki. Nie modelujemy jego czynności, tylko wiadomości, które wymienia z biblioteką. Ta sama tabela jest podstawą zadania Z2.

Nr kroku	Nr kolejnego kroku	Nazwa kroku	Wariant	Opis kroku	Kto wykonuje?	Dokumenty
1	2	Wpływ zamówienia		Proces rozpoczyna się, gdy od zamawiającego wpływa przez formularz na stronie biblioteki zamówienie skanów wskazanych obiektów.	Pracownik Pracowni Digitalizacji	Zamówienie [złożone]
2	3	Weryfikacja zamówienia		Pracownik sprawdza w katalogu, czy obiekty są w zbiorach, i ustala ich status prawnoautorski.	Pracownik Pracowni Digitalizacji	Zamówienie; Katalog zbiorów specjalnych
3	4	Czy obiekty można digitalizować?	T	Tak, obiekty są w zbiorach i można je udostępnić w postaci kopii.
	17		N	Nie, obiektów nie ma albo prawa autorskie nie pozwalają na kopię.
4	5	Ocena stanu zachowania		Pracownik ogląda obiekty w magazynie i ocenia, czy można je bezpiecznie skanować.	Pracownik Pracowni Digitalizacji	Karta stanu zachowania
5	7	Czy potrzebna konsultacja konserwatorska?	N	Nie, stan obiektów pozwala na skanowanie.
	6		T	Tak, obiekty są uszkodzone albo bardzo cenne.
6	7	Konsultacja konserwatora		Konserwator ocenia obiekty i określa warunki skanowania. Ma na to 5 dni roboczych. Po ich upływie konsultacja trwa dalej, ale sprawa zostaje jednocześnie zgłoszona wyżej (krok 6a).	Konserwator	Karta stanu zachowania [uzupełniona]
6a	—	Interwencja kierownika		Gdy konsultacja przekroczy termin, kierownik Pracowni ustala z konserwatorem nowy termin. Konsultacja nie zostaje przerwana. Po rozmowie ta ścieżka się kończy.	Kierownik Pracowni Digitalizacji
7	8	Wycena zamówienia		Koszt wynika wyłącznie z cennika: liczba skanów, rozdzielczość, tryb realizacji i rodzaj obiektu. Nikt go nie ocenia.	System biblioteczny	Wycena; Cennik usług
8	9	Wysłanie wyceny		Pracownik wysyła zamawiającemu wycenę z prośbą o akceptację.	Pracownik Pracowni Digitalizacji	Wycena
9	10 (po 14 dniach: 18)	Oczekiwanie na akceptację		Zamawiający ma 14 dni na akceptację wyceny. Gdy akceptacja wpłynie, zaczyna się realizacja. Jeśli w tym czasie nie odpowie, zamówienie wygasa.	Pracownik Pracowni Digitalizacji	Akceptacja wyceny
10	12 (przy awarii: 11)	Skanowanie obiektów		Operator skanuje obiekty zgodnie z warunkami konserwatora. Jeśli skaner ulegnie awarii, skanowanie zostaje przerwane.	Operator skanera	Skany [surowe]
11	10	Zgłoszenie awarii		Operator zgłasza awarię serwisowi i przenosi zlecenie na drugi skaner. Potem skanowanie zaczyna się od początku.	Operator skanera	Zgłoszenie serwisowe
12	13	Obróbka skanów		Operator przycina skany, nadaje im nazwy i metadane techniczne.	Operator skanera	Skany [opracowane]
13	14	Kontrola jakości		Inna osoba niż operator ogląda skany i porównuje je z zamówieniem.	Pracownik Pracowni Digitalizacji	Skany [opracowane]
14	15	Czy skany poprawne?	T	Tak, skany są zgodne z zamówieniem.
	12		N	Nie, skany wymagają poprawek.
15	16	Archiwizacja kopii matek		System zapisuje pliki matki w repozytorium cyfrowym biblioteki.	System biblioteczny	Repozytorium cyfrowe
16		Koniec — skany przekazane		Proces kończy się, gdy system wysyła zamawiającemu odnośnik do pobrania skanów.	System biblioteczny	Skany [przekazane]
17		Koniec — odmowa		Proces kończy się wysłaniem zamawiającemu informacji o odmowie wraz z uzasadnieniem.	Pracownik Pracowni Digitalizacji
18		Koniec — zamówienie wygasło		Zamówienie wygasa, bo minął termin akceptacji wyceny. Nikt nie jest o tym dodatkowo informowany.		Zamówienie [wygasłe]

Wymagania:

basen „Biblioteka uniwersytecka” z liniami: Pracownik Pracowni Digitalizacji, Kierownik Pracowni Digitalizacji, Konserwator, Operator skanera, System biblioteczny; zamawiający jako zamknięty basen, połączony przepływami komunikatów;
kroki 10–14 (skanowanie, obróbka i kontrola jakości) jako rozwinięty podproces „Realizacja skanowania” z własnym startem i końcem;
zdarzenia graniczne zgodne z opisem: sprawdź, które przerywają czynność, a które nie;
nazwa każdego elementu zaczyna się numerem kroku, np. „10. Skanowanie obiektów”;
przy krokach 1, 10, 12 i 18 obiekty danych ze stanem z kolumny „Dokumenty”.

Praca: w parach. Najpierw 10 minut na papierze: zaznaczcie w tabeli słowa, które decydują o typie elementu. Potem modelujcie w Camunda Modeler.

Rezultat: plik digitalizacja.bpmn i rysunek digitalizacja.svg (menu File, eksport obrazu w formacie SVG). Na marginesie tabeli kroków albo w osobnym pliku zapiszcie, które słowa z opisu zdecydowały o wyborze każdego zdarzenia granicznego. Zachowajcie model, bo przyda się w zadaniu Z2 po spotkaniu 8.

Czas: 50 minut, w tym 10 minut na porównanie modeli dwóch par na forum grupy.

Na co zwrócić uwagę

Krok 9 to czekanie na odpowiedź. Zastanów się, czy lepiej zamodelować go jako zadanie odbioru z granicznym zegarem, czy jako bramkę opartą na zdarzeniach (spotkanie 5). Obie odpowiedzi da się obronić. Ważne, żeby po 14 dniach zamówienie naprawdę wygasało.
Termin w kroku 6 nie przerywa konsultacji, ale uruchamia ścieżkę 6a. Zdecyduj, czy wystarczy nieprzerywające zdarzenie czasowe, czy konsultację warto ująć w podprocesie, który zgłasza eskalację na zewnątrz (zdarzenie rzucające wewnątrz i graniczne zdarzenie eskalacji na krawędzi).
Awaria skanera przerywa skanowanie, ale nie kończy procesu. Ścieżka wyjątku wraca do kroku 10. Taki powrót jest poprawny, o ile nie prowadzi przez krawędź podprocesu.
Nie dodawaj bramki „Czy minęło 14 dni?”. Termin modeluje zdarzenie czasowe.

6.3 Pytania sprawdzające

Dlaczego terminów nie modeluje się bramką „Czy minął termin?”? Co się wtedy dzieje z zadaniem, które trwa?
Opis mówi: „Po 5 dniach roboczych do kierownika trafia powiadomienie, a sprawa zostaje u referenta”. Jakie zdarzenie graniczne zastosujesz i jak będzie wyglądała jego linia?
Dlaczego graniczne zdarzenie błędu nie może być nieprzerywające?
Czym różni się eskalacja od błędu? Podaj przykład z archiwum albo biblioteki, w którym właściwa jest eskalacja.
Kiedy zamiast zdarzenia granicznego trzeba użyć podprocesu zdarzeniowego? Jakie dwie zasady musi spełniać podproces zdarzeniowy?
Czym różni się przerwanie zadania od kompensacji?
Kiedy warto użyć czynności wywołania zamiast podprocesu? Jakie ma to skutki dla organizacji?