Tworzenie pierwszego procesu biznesowego w jBPM

jBPM wykorzystuje język BPMN (Business Process Model and Notation) do tworzenia i modelowania procesów biznesowych. Dzięki BPMN można w prosty sposób wizualizować, definiować i wdrażać procesy, które odwzorowują rzeczywiste przepływy pracy.

Modelowanie procesów w jBPM polega na graficznym przedstawieniu kroków oraz zależności pomiędzy nimi, co umożliwia tworzenie przejrzystych schematów przepływów. Można w jBPM definiować różnorodne elementy procesów, takie jak punkty decyzyjne, zadania użytkownika, bramki logiczne czy komunikaty, tworząc w ten sposób kompletny proces, który może być zautomatyzowany i monitorowany.

jBPM wspiera także zarządzanie regułami biznesowymi i integrację z zewnętrznymi systemami, co pozwala na budowę zaawansowanych procesów, odpowiadających na potrzeby konkretnych scenariuszy biznesowych.

Menu jBPM

Po zalogowaniu się jako administrator do jBPM na stronie startowej zobaczysz stronę startową z czterema kategoriami:

Design - projektowanie i wdrażanie modeli biznesowych, tworzenie stron [raporty]

Deploy - zarządzanie wdrożonymi procesami. Umożliwia przegląd i zarządzanie kontenerami procesów, wdrażanie nowych jednostek, pracę z różnymi wersjami oraz ustawianie strategii wykonywania procesów.

Manage - umożliwia zarządzanie uruchomionymi procesami i zadaniami użytkowników. Można tu monitorować aktywne instancje procesów, zarządzać zadaniami (np. przypisywać je, zatwierdzać) oraz przeglądać historię wykonanych procesów i audytów.

Track - służy do monitorowania i śledzenia aktywności procesów biznesowych. Umożliwia przeglądanie aktualnych instancji procesów, ich statusów, historii wykonania oraz szczegółów poszczególnych kroków. Jest to pomocne przy analizie przepływów, diagnozowaniu problemów i optymalizacji procesów.

By utworzyć pierwszy projekt w jBPM i wdrożyć go, przejdziesz kolejno przez kroki:

Space => Project => Assets => Deploy

Space

W jBPM "Spaces" pełnią rolę organizacyjną, podobnie jak przestrzenie nazw (ang. namespaces) w Java, takie jak com.jakisProjekt. W Java przestrzenie nazw są tworzone przy użyciu pakietów (np. com.jakisProjekt), co pozwala grupować powiązane klasy i zasoby, unikając konfliktów nazw między różnymi projektami.

Podobnie w jBPM, spaces pomagają strukturyzować projekty w odrębne, logiczne obszary. W każdym z nich użytkownicy mogą tworzyć procesy, reguły i inne zasoby, które są niezależne od zasobów w innych przestrzeniach, co ułatwia pracę zespołów nad różnymi projektami w jednej instancji jBPM. Taka organizacja przypomina strukturę pakietów w programowaniu, umożliwiając lepsze zarządzanie zależnościami oraz wersjonowanie.

W jBPM nazwy przestrzeni (ang. spaces) powinny być jasne, opisowe i odzwierciedlać cel lub obszar działalności, do którego są przypisane. Pomaga to w zarządzaniu i organizowaniu procesów w większych środowiskach, zwłaszcza gdy wiele zespołów pracuje równolegle nad różnymi projektami.

Zalecenia dotyczące nazw przestrzeni w jBPM:

Opisowe i związane z obszarem działania:
- Przykłady: sales-processes, hr-approvals, inventory-management. Takie nazwy jasno wskazują, do jakiego obszaru lub działu organizacji należy przestrzeń.
Konsystencja z konwencjami nazw:
- Stosowanie struktury nazw podobnej do konwencji w Java, np. com.companyname.projectname, pozwala na zachowanie porządku i jednoznaczności, zwłaszcza w większych organizacjach.
Uwzględnienie wersji lub środowisk:
- Jeśli przestrzenie są używane w różnych etapach projektu lub środowiskach, warto dodać informacje o wersji lub środowisku, np. dev-sales-processes (środowisko deweloperskie) czy prod-inventory-management (środowisko produkcyjne).
Unikanie ogólnych nazw:
- Nazwy takie jak "jakaś przestrzeń" są niepraktyczne i mogą prowadzić do zamieszania. Zamiast tego, przestrzenie powinny mieć konkretne, łatwe do zrozumienia i przypisania nazwy.

Przykłady dobrych nazw:

finance-processes – procesy związane z finansami.
customer-service – przestrzeń dla procesów obsługi klienta.
order-fulfillment – przestrzeń związana z realizacją zamówień.
production-workflows – przestrzeń dla procesów produkcyjnych.
support-ticketing-system – przestrzeń dla procesów systemu zgłoszeń.

Dzięki takim nazwom łatwiej jest zarządzać i segregować procesy, co jest szczególnie ważne w dużych organizacjach. Klarowne nazewnictwo pomaga uniknąć nieporozumień i ułatwia odnalezienie potrzebnych zasobów.

Utwórz zatem przestrzeń klikając na przycisk "Add space".

Projekt

W jBPM projekt to zbiór zasobów, które umożliwiają definiowanie i zarządzanie procesami biznesowymi. Kluczowe elementy w menu 'Projekt' to:

Procesy – Zawiera definicje przepływów pracy w formacie BPMN.
Reguły – Określenie zasad biznesowych wykorzystywanych w procesach.
Deployment – Wdrożenie projektu na środowisku jBPM.
Zasoby – Elementy wspierające procesy, takie jak usługi, dane, formularze.

Projekt w jBPM służy do organizowania i zarządzania tymi zasobami, a także do ich wdrażania i monitorowania w systemie.

Wybierz zatem z menu "Add Project". Do nazewnictwa projektów (nie używaj spacji) możesz użyć trzech popularnych konwencji:

CamelCase – Każdy wyraz zaczyna się wielką literą, np. SalesProcess.
Podkreślenia (snake_case) – Wyrazy oddzielone są podkreśleniami, np. sales_process.
Kebab-case – Wyrazy oddzielone są myślnikami, np. sales-process.

Każda z tych metod poprawia czytelność nazw i zapobiega problemom z kompatybilnością, które mogą wynikać z użycia spacji lub innych znaków specjalnych.

Assets

W jBPM assets to zasoby projektu, które wspierają tworzenie i zarządzanie procesami biznesowymi. Główne typy assets w jBPM to:

Procesy – Modele BPMN definiujące sekwencje działań w procesie.
Reguły biznesowe – Logika decyzyjna sterująca przebiegiem procesów.
Formularze – Interfejsy użytkownika do wprowadzania i przetwarzania danych w procesach.
Obiekty danych (Data Objects) – Przechowują i przekazują dane między elementami procesów.

Kliknij na "Add Asset" i wybierz "Business process"

Tworząc nowy proces, zostaniesz poproszony(a) o wpisanie jego nazwy (weź pod uwagę to co napisane w wyżej) oraz przypisanie go do pakietu. Wybierz właściwy by asset znalazł się w ramach właściwego projektu (zwykle projekt w którego ramach jest dodawany 'biznes process').

Następnym ekranem który zobaczysz jest obszar roboczy modelowania procesu biznesowego. Po lewej stronie ekranu masz belkę elementów BPMN za pomocą których modelujesz proces. Po prawej stronie masz link do właściwości projektu.

Testowy proces biznesowy

Nasz testowy projekt to akceptacja faktury. Wybierając elementy z belki elementów BPMN stwórz przepływ jak przedstawiony wyżej. Pierwszym po zdarzeniu początkowym jest obiekt 'Business Rule' kóra współpracuje z zasobem 'DMN decision'. W jBPM reguły decyzyjne/biznesowe można ustawić na kilka sposóbów. O tym jak ustawić 'DMN decision' przeczytaj w innym artykule.

Process data

Zmienne procesu ("process data") pełnią kluczową rolę, ponieważ są to dane, które wspierają przepływ procesu, umożliwiając podejmowanie decyzji i kontrolowanie logiki biznesowej na różnych etapach procesu.

Przechowują stan procesu – śledzą aktualne wartości zmiennych w procesie.
Przekazują informacje między zadaniami – umożliwiają przepływ danych między etapami.
Wspierają podejmowanie decyzji – są podstawą dla warunków i bramek decyzyjnych.
Integrują się z systemami zewnętrznymi – pozwalają wymieniać dane poza jBPM.
Ułatwiają śledzenie i raportowanie – wspierają analizę i monitoring procesów.

Jak widać powyżej, nasz proces posługuje się szeregiem zmiennych. Dział - identyfikator działu, kwota - wartość faktury, poziomakceptacji - informacja czy faktura powinna przejść tylko jeden czy dwa poziomy akceptacji, document - zmienna przechowująca kolekcję załączników, akceptacja - decyzja o odrzuceniu lub akceptacji faktury.

Zmienne te przechowują wartości w ramach procesu i mogą się zmieniać po przejściu każdego z kroków przepływu. Każdy z tasków ma ustawienia 'Assignements' gdzie ustawiamy jakie zmienne mają wchodzić do tasku i jakie z niego wychodzić. Oto podgląd tych zmiennych dla 'Poziom akceptacji DMN'

Wartość zmiennych 'dział', 'kwota', 'document' została przypisana w formularzu wypełnionym przez użytkownika, inicjującym proces. Ten task zwroci zmienną 'Poziomakceptacji' (wyliczony na podstawie działu i kwoty faktury przez reguły DMN), przekaże też do następnego tasku kolekcje dokumentów (załączniki). Zmienne przekazywane są z tasku do tasku. Niektore z nich nie są przekazywane - ich rolą było tylko dostarczenie informacji do któregoś z tasków i dalej nie będą już wykorzystane. Żywot niektorych z nich rozpoczyna się dopiero od pewnego tasku - np. zmienna 'akceptacja' zostanie wypełniona dopiero przy tasku 'Zatwierdz poziom 1' i przybierze wartość 'accept' lub 'reject'.

Taski

W procesie mamy dwa typy tasków; 'User' i Business Rule'. Zadanie 'User' powinno być przypisane do osoby, 'Actors' (należy w BPM unikać przypisania zadań do konkretnych osób, powinny to być grupy) lub grupy, 'Groups'. W ten sposób proces który osiągnie zadanie przypisane do danego użytkownika pojawi się jako zadanie do zrobienia na task list użytkownika. Użytkownik przypisany przez grupę do danego tasku może uczestniczyć w różnych procesach, realizować różne zadana. Wszystkie te taski pojawią się na jego liście zadań; będzie mógł je otworzyć, podjąć i zrealizować. Po wykonaniu takiego zadanie proces kontynuuje dalej.

Formularze

Formularze są powiązane z procesami i zadaniami. Użytkownik uruchamia proces poprzez wypełnienie formularza (oczywiście proces można uruchomić także innymi sposobami). Jeśli wejdziesz we właściwości wydarzenia początkowego zobaczysz że nie można do niego przypisać żadnego formularza. jBPM pozwala nam jednak na utworzenie formularza startującego proces. By to zrobić rozwiń menu "Form generation" i zdecyduj czy chcesz utworzyć formularz dla procesu, wszystkie czy tylko dla wybranych elementów. W efekcie wybrania np. 'Generate all forms' utworzone zostaną wszystkie formularze; procesu i tasków. Znajdziesz je w na liście zasobów procesu.

Automatycznie wygenerowane formularze będą mieć pola i przypisane do nich zmienne pobrane z ustawień procesu. Możesz ręcznie zmienić te elementy, przpisać je do określonej zmiennej procesu ('Field binding'). Oto okno edycji formularza, pole do wyboru działu:

W formularzu przypisanym do zadania użytkownika, pola które nie powinny być edytowane przez użytkownika ustaw na 'Read only". Okno edycji formularza dla zadania "Zatwierdź poziom 1" (akceptacja poziomu 2 wyglądać będzie podobnie):

Przepływy - między taskami

Czyli 'strzałki' między elementami BPM mogą zawierać warunki (wg specyfikacji BPMN możliwa jest rezygnacja z bramek) ale w naszym modelu procesu nie posługujemy się takimi warunkami w przepływach jeśli przepływ łączy jedno zadanie z drugim - pozostaw właściwość 'Condition Expression' nie wypełnioną.

Bramki

W naszym modelu procesu posługujemy się bramkami 'Exclusive'. Bramka Exclusive Gateway (bramka wykluczająca) umożliwia rozgałęzienie przepływu na podstawie warunku, ale tylko jeden z dostępnych przepływów może zostać wybrany i wykonany. Działa na zasadzie "albo-albo" – spośród dostępnych ścieżek wybierana jest wyłącznie jedna, w zależności od tego, która spełnia określony warunek. Oczywiście od bramki mogą odchodzić więcej niż dwa przepływy. Bramki te mogą mieć ustawione 'Default Route' - ścieżkę która zostanie obrana jeśli inne warunki nie zostały spełnione. W naszym scenariuszu nie używamy tej właściwości. Zauważ ze przepływ rozwidlony bramkami Exclusive używa tych samych typów bramek by połączyć przepływy, np po odrzuceniu z poziomu 1 i poziomu 2.

Przepływy - odchodzące od bramek

By nasz proces przebiegał zgodnie z decyzjami użytkoników i wartościami zmiennych, posługujemy się warunkami ustawionymi na przepływach powiązanych z bramkami. Oto przykład warunku jeśli wymagany był tylko jeden poziom akceptacji i jeśli akceptujący ten poziom zaakceptował fakturę:

Stosowanie wyrażeń JavaSkrypt daje nam większą swobodę; możemu umieścić w takim wyrażeniu kilka warunków - w GUI możemy ustawić tylko jeden warunek

Powiadomienia mailowe

W ustawieniach 'Notifications' dla danego zadania użytkownika możesz ustawić powiadomienie mail'em o oczekującym zadaniu do realizacji. Można tam określić po jakim czasie od pojawienia się zadania do wykonania użytkownik/grupa mają być poinformowani i czy powtwórzyć przypomnienie (opcje przypomnienia).

Ustawienia procesu

W 'Settings' procesu musisz ustawić dwie rzeczy by proces obsługiwał załączniki oraz by proces dostępny był tylko dla określonych ról.

W Deployments => Marshalling Strategies definiujesz politykę zarządzania dokumentami. Dodająć:

new org.jbpm.document.marshalling.DocumentCollectionImplMarshallingStrategy(new org.jbpm.document.marshalling.DocumentMarshallingStrategy())

z typem MAVEL uruchomisz możliwość obsługi kolekcji dokumentów (wiele załączników, pole typu 'Document collection' w formularzu). Pamiętaj by utworzyć katalog '.docs' w katalogu bin servera - tam będą przechowywane załączniki (taką nazwę możesz utworzyć w Windows poprzez wpisanie '.docs.'). jBPM tworzy oddzielny katalog dla każdego pliku (może utworzyć wiele katalogów dla jednego procesu - tyle ile załączonych plików). Zmienna 'document' przechowujaca załączniki jest typu 'org.jbpm.document.DocumentCollection'. Więcej o załącznikach w jBPM przeczytasz tutaj.

Uruchamianie procesu

Finalnie proces uruchamiasz poprzez kliknięcie przycisku 'Deploy'. Definicja procesu nie jest przechowywana w bazie lecz plikach w katalogu M2_MAVEN. Jeśli więc uruchomisz nową instancję jBPM, z nową bazą a nowa instalacja będzie korzystać z tego samego repozytorium, projekty będą gotowe do uruchomienia.