12 Od modelu do wykonania: Camunda 8

Efekty uczenia się: W4, W5, U1, U3 · Treści programowe: 9 · Czas: Nauka 40 min, Wyzwanie 50 min

12.1 Nauka

Model, który działa

Do tej pory modele służyły ludziom: pokazywały przebieg procesu, pomagały znaleźć bariery i uzgodnić zmiany. Model wykonywalny (executable model) czyta także program. Silnik procesów (process engine) prowadzi według modelu każdą sprawę po kolei: tworzy zadania dla ludzi, wywołuje tabele decyzyjne, wylicza wartości, pilnuje terminów i zapisuje, którędy przeszła sprawa.

Instytucje informacyjne korzystają z takich silników częściej, niż się wydaje. Elektroniczne zarządzanie dokumentacją (EZD) prowadzi pismo przez dekretację, akceptację i podpis. Systemy biblioteczne prowadzą zamówienie przez kolejne statusy. Repozytoria prowadzą pracę dyplomową od złożenia do publikacji. Często silnik jest ukryty w systemie dziedzinowym. W tym rozdziale zobaczysz go bez przebrania.

Definicja, wdrożenie, instancja

Trzy pojęcia porządkują pracę z silnikiem:

Pojęcie	Znaczenie	Przykład
definicja procesu	model przekazany silnikowi; ma identyfikator i numer wersji	„propozycja-zakupu”, wersja 1
wdrożenie (deployment)	przekazanie silnikowi plików: modelu, tabel decyzyjnych, formularzy	wdrożenie z Camunda Modeler
instancja procesu	jedna sprawa prowadzona według definicji	propozycja zakupu „Zarządzanie informacją”, złożona dziś o 10:15

Jedna definicja może mieć tysiące instancji. Gdy zmienisz model i wdrożysz go ponownie, silnik utworzy nową wersję definicji. Sprawy już rozpoczęte dokończą się według starej wersji, a nowe ruszą według nowej. To ważna cecha z punktu widzenia zarządzania informacją: każda sprawa ma jednoznacznie określoną procedurę, według której ją prowadzono.

Na spotkaniu 3 czytaliśmy diagram, przesuwając palcem żeton (token). Silnik robi dokładnie to samo. Każda instancja ma swój żeton (albo kilka żetonów po bramce równoległej), a silnik przesuwa go po przepływach sekwencji.

Camunda 8 i jej aplikacje

W kursie używamy platformy Camunda 8. To ten sam producent co Camunda Modeler, z którego korzystasz od spotkania 4. Do nauki służy Camunda 8 Run: pakiet, który uruchamia całą platformę na jednym komputerze. Producent zaznacza, że Camunda 8 Run służy do pracy lokalnej i nauki, a nie do obsługi prawdziwych spraw w instytucji.

Składnik	Do czego służy
Zeebe	silnik procesów: przechowuje instancje i przesuwa żetony
Tasklist	skrzynka zadań dla ludzi: uruchamianie procesów i wypełnianie formularzy
Operate	podgląd procesów i instancji na diagramie, zmiennych i incydentów
Admin	użytkownicy, grupy i uprawnienia
Connectors	gotowe połączenia z innymi systemami (np. wywołanie usługi REST)

Po uruchomieniu wszystkie aplikacje są dostępne w przeglądarce pod adresem http://localhost:8080, a domyślny użytkownik to demo z hasłem demo.

Co trzeba dopisać do modelu

Model analityczny z bloku B mówi, co się dzieje. Model wykonywalny musi dodatkowo powiedzieć, jak silnik ma to zrobić. Camunda zapisuje te informacje w rozszerzeniach z przestrzeni nazw zeebe:. Camunda Modeler pokazuje je w panelu właściwości po prawej stronie, gdy plik jest typu „BPMN diagram (Camunda 8)”.

Element	Co dopisujesz	Panel w Modelerze
proces	„wykonywalny” (isExecutable)	General → Executable
zadanie użytkownika	typ „Camunda user task” i formularz	Implementation, Form
zadanie reguły biznesowej	identyfikator decyzji i nazwa zmiennej na wynik	Implementation: DMN decision
zadanie skryptowe	wyrażenie FEEL i nazwa zmiennej na wynik	Implementation: FEEL expression
wyjście z bramki XOR lub OR	warunek FEEL albo oznaczenie jako przepływ domyślny	Condition
zdarzenie czasowe	czas w formacie ISO 8601, np. P7D	Timer
zdarzenie lub zadanie oczekujące na wiadomość	nazwa wiadomości i klucz korelacji	Message, Subscription correlation key
zadanie usługowe	typ zadania dla programu, który je wykona	Task definition type

Ostatni wiersz wymaga komentarza. Zadanie usługowe (service task) w Camunda 8 czeka, aż osobny program, nazywany workerem, pobierze je i wykona. Bez takiego programu instancja zatrzyma się na zadaniu usługowym. Na zajęciach nie piszemy programów, dlatego automatyczne kroki modelujemy jako zadania skryptowe z wyrażeniem FEEL albo zadania reguły biznesowej. W prawdziwej instytucji w tym miejscu pojawiłyby się zadania usługowe połączone z systemem bibliotecznym albo z pocztą.

Dane procesu

Każda instancja ma zmienne procesu (process variables): nazwane wartości, które powstają w trakcie sprawy. Formularz zapisuje pola jako zmienne, tabela decyzyjna zapisuje swój wynik, a skrypt swoje wyliczenie. Warunki na bramkach czytają te zmienne.

Projektując model wykonywalny, trzeba więc wiedzieć, skąd bierze się każda informacja i kto ją wprowadza. To pytanie znamy z kolumny „Dokumenty” w tabeli kroków. Teraz dokument rozpada się na pola.

FEEL: język wyrażeń

Warunki i wyliczenia zapisuje się w języku FEEL (Friendly Enough Expression Language). Pochodzi on ze standardu DMN, który poznałeś na spotkaniu 8. W Camunda wyrażenie w modelu BPMN zaczyna się od znaku równości.

Wyrażenie	Znaczenie
=zgoda = true	zmienna zgoda ma wartość prawda (tu pojedynczy znak = w środku oznacza porównanie)
=tryb = "kierownik"	tekst porównujemy w cudzysłowie
=cena > 150 and rodzaj = "drukowana"	dwa warunki naraz
=cena + 12.5	wyliczenie; część dziesiętną oddziela kropka
=if cena > 150 then "drogo" else "tanio"	wybór wartości
="Zamówienie: " + tytul	łączenie tekstów

Częsty błąd to warunek bez znaku = na początku. Silnik potraktuje wtedy tekst zgoda = true jako zwykły napis, a nie wyrażenie. Polecenie tok check z opcją --camunda zgłasza ten błąd kodem C071.

Przykład: propozycja zakupu książki

Czytelnik proponuje bibliotece zakup książki. System sam ustala, czy propozycja wymaga akceptacji kierownika. Tanie książki drukowane przechodzą od razu, a e-booki (ze względu na licencje) i droższe pozycje trafiają do kierownika Oddziału Gromadzenia. Kierownik ma 7 dni na decyzję. Po tym czasie propozycja wygasa. Na końcu bibliotekarz gromadzenia składa zamówienie u dostawcy.

Rysunek 12.1: Propozycja zakupu książki: model wykonywalny dla Camunda 8.

Pobierz model (.bpmn)

Tabela decyzyjna „Tryb akceptacji” ma politykę trafień F (first): wygrywa pierwsza pasująca reguła.

	Rodzaj publikacji (rodzaj)	Cena (cena)	→ Tryb akceptacji (tryb)	Uwagi
1	"e-book"	—	"kierownik"	e-booki zawsze akceptuje kierownik (licencje)
2	"drukowana"	<= 150	"automatyczny"	tania książka drukowana bez akceptacji
3	—	—	"kierownik"	pozostałe propozycje

Zmienne procesu powstają w czterech miejscach:

Zmienna	Skąd się bierze	Kto ją czyta
tytul, autor, rodzaj, cena, uzasadnienie	formularz startowy czytelnika	tabela decyzyjna, formularze kolejnych zadań
tryb	tabela decyzyjna „Tryb akceptacji”	warunek =tryb = "kierownik" na bramce
zgoda, komentarz	formularz kierownika	warunek =zgoda = true na bramce
koszt	zadanie skryptowe =cena + 12.5 (cena z wysyłką)	formularz zamówienia
dostawca, numer_zamowienia	formularz bibliotekarza gromadzenia	zapis w historii instancji

Zwróć uwagę na trzy szczegóły modelu:

• bramki mają przepływy domyślne. Gałąź „nie” przy pytaniu o akceptację kierownika nie potrzebuje warunku, bo jest domyślna. Silnik wybierze ją zawsze, gdy warunek gałęzi „tak” nie jest spełniony;
• złączenie XOR przed wyliczeniem kosztu przyjmuje sprawy z obu dróg: z akceptacją i bez niej;
• termin 7 dni to przerywające zdarzenie graniczne. Gdy minie, silnik odbierze zadanie kierownikowi i zakończy sprawę jako „Propozycja wygasła”.

Co pokazuje Operate

Operate wyświetla diagram wdrożonego procesu i nakłada na niego dane z instancji. Liczba przy elemencie mówi, ile spraw jest w nim teraz. Ścieżka zakończonej instancji jest wyróżniona, a panel zmiennych pokazuje wartości z formularzy i decyzji.

Jeśli silnik nie może wykonać kroku, tworzy incydent (incident). Przykład: zadanie reguły biznesowej wywołuje decyzję, której nie wdrożono. Operate zgłasza wtedy błąd CALLED_DECISION_ERROR z opisem „no decision found”. Po wdrożeniu brakującej tabeli wystarczy ponowić krok przyciskiem Retry. Incydenty to ważne źródło wiedzy o procesie. Pokazują miejsca, w których model rozmija się z rzeczywistością albo z konfiguracją systemu.

Sprawdzenie modelu przed wdrożeniem

Polecenie tok check, z którego korzysta pakiet bpmn-agent, ma tryb dla Camunda 8. Sprawdza rozszerzenia zeebe:, warunki FEEL oraz to, czy formularze i decyzje, do których odwołuje się model, leżą w tym samym folderze:

tok check propozycja-zakupu.bpmn --camunda --lang pl

Kody C… są opisane w pliku references/elementy.md skilla, w sekcji D. Ten sam tryb wykorzysta agent na spotkaniu 13, gdy będzie przygotowywał Twój własny proces wykonywalny.

12.2 Wyzwanie

Polecenie: uruchom Camunda 8 Run, wdróż gotowy proces „Propozycja zakupu książki” i przeprowadź przez niego trzy sprawy. Potem zmień tabelę decyzyjną i sprawdź, jak zmiana wpłynęła na nowe sprawy.

Dane wejściowe: pakiet camunda-start: model, tabela decyzyjna i trzy formularze. Instrukcja instalacji jest w pliku README.md pakietu.

Pobierz pakiet camunda-start (.zip)

Kroki:

1. Uruchom Camunda 8 Run i zaloguj się do Operate (demo / demo).
2. Otwórz pliki pakietu w Camunda Modeler i wdróż najpierw tabelę decyzyjną i formularze, a potem model.
3. W Tasklist uruchom trzy sprawy:
   1. książka drukowana za 89,90 zł;
   2. e-book za 120 zł, kierownik się zgadza;
   3. książka drukowana za 240 zł, kierownik odmawia.
4. W Operate otwórz każdą instancję. Zapisz, którędy przeszła i jakie miała zmienne.
5. Zmień w Modelerze tabelę decyzyjną: próg ceny z 150 na 200 zł. Wdróż ją ponownie i uruchom sprawę za 180 zł. Sprawdź w Operate, którą wersję decyzji wykorzystała.
6. Uruchom tok check propozycja-zakupu.bpmn --camunda --lang pl. Potem usuń w Modelerze warunek z gałęzi „tak” przy pytaniu „Czy kierownik się zgodził?”, zapisz plik i uruchom sprawdzenie ponownie. Odczytaj komunikat i przywróć warunek.

Rezultat: krótka notatka (notatka-12.md) z tabelą trzech spraw (ścieżka, zmienne), opisem efektu zmiany tabeli decyzyjnej i komunikatem tok check z kroku 6. Notatka nie jest oddawana, ale przyda się przy projekcie Z4.

Praca: indywidualnie. Jeśli Twój komputer ma mniej niż 8 GB pamięci RAM, pracuj na komputerze w pracowni albo w parze.

Czas: 50 minut, z czego instalacja i pierwszy start silnika zajmują zwykle 10–15 minut.

Na co zwrócić uwagę

• Silnik musi działać przez cały czas ćwiczenia. Nie zamykaj okna terminala, w którym go uruchomiłeś.
• Formularz nie pojawia się w Tasklist? Sprawdź, czy wdrożyłeś plik .form i czy jego id zgadza się z identyfikatorem formularza w modelu.
• Zdarzenie czasowe „Minęło 7 dni” naprawdę czeka 7 dni. W Operate zobaczysz instancję oczekującą na akceptację z aktywnym zegarem. Na zajęciach nie czekamy na jego upływ.
• Po zajęciach zatrzymaj silnik (.\c8run.exe stop albo ./shutdown.sh). Dane wdrożonych procesów zostaną na dysku do następnego uruchomienia.

12.3 Pytania sprawdzające

1. Czym różni się definicja procesu od instancji procesu? Co dzieje się z rozpoczętymi sprawami po wdrożeniu nowej wersji modelu?
2. Dlaczego w kursie automatyczne kroki modelujemy jako zadania skryptowe, a nie usługowe? Co byłoby potrzebne, żeby zadanie usługowe zadziałało?
3. Skąd w przykładowym procesie bierze się wartość zmiennej tryb? Które elementy modelu z niej korzystają?
4. Zapisz w FEEL warunek: „cena przekracza 300 zł albo publikacja jest e-bookiem”.
5. Czym jest incydent w Operate? Podaj przykład sytuacji, która go wywoła, i sposób, w jaki go usuniesz.