Proces oraz jego elementy mają parametry, które powinny być dopracowane w trakcie tworzenia diagramu. Zapewnia to późniejszą poprawną konfigurację schematu procesu, a także ułatwia odnalezienie się w procesie.
Konfiguracja procesu i elementu typu User Task
Kluczowe parametry procesu ustalane są na poziomie basenu. Baseny i tory pływackie wykorzystywane są w modelach procesów biznesowych notacji BPMN do prezentacji działań w ramach np. danego stanowiska pracy. Basen reprezentuje jedną organizację i zawiera obiekty przepływu (np. zadania), które wykonywane są w naszej organizacji. Gdy diagram nie zawiera basenu, należy kliknąć na obszar poza obiektami. Są to:
- Process ID – klucz biznesowy dla silnika BPMN potrzebny do budowy Schematu procesu.
Każdy podmiot może posiadać w EZD RP tylko jeden Schemat BPMN z przypisanym na diagramie identyfikatorem Process ID. Może jednak dodać do Schematu BPMN nową Wersję Schematu BPMN ze zmodyfikowanym Diagramem BPMN i tym samym identyfikatorze Process ID).
- Process name – nazwa Diagramu BPMN a zarazem nazwa Schematu BPMN.
Parametr ID jest nadawany automatycznie dla procesu i każdego obiektu w nim, jest również unikatowy. Aby ułatwić korzystanie z procesu, warto ten parametr zmienić na bardziej zrozumiały dla użytkownika, zachowując jego unikatowość.
Od wersji 7.20 Silnika Camunda wymagany jest też nowy parametr History cleanup > Time to live, który określa, przez ile dni Silnik Camunda ma przechowywać historię o zakończonym procesie. Jeżeli pole nie będzie uzupełnione, to EZD RP automatycznie ustawi wartość na 5 dni podczas ładowania Diagramu BPMN do Silnika Camunda.
EZD RP przechowuje informacje o historii Procesów BPMN i zrealizowanych zadaniach użytkowników, niezależnie od Silnika Camunda.
Elementy diagramu edytujemy analogicznie do właściwości procesu.
- Name – nazwa elementu; w przypadku zadania – to ta nazwa wyświetlana jest użytkownikom w systemie EZD RP.
- ID – klucz biznesowy elementu:
- parametry zadania
- parametry przepływu
- parametry zdarzenia (event)
Konfiguracja zadania typu Service Task – przypisanie workera Zadania Procesowego
Zgodnie ze standardem BPMN 2.0, każdy proces może zawierać zadania wykonywane bez interakcji z użytkownikami przez tzw. workery, czyli niezależne od siebie moduły lub aplikacje. W zależności od miejsca, w którym zadanie jest wykonywane, workery możemy podzielić na dwa rodzaje:
- Internal – wywoływanie kodu Java;
- External – odwoływanie się do zewnętrznego workera, logiki zaimplementowanej w postaci usługi sieciowej spoza silnika procesu (więcej informacji na ten temat znajduje się w artykule External Tasks na stronie z dokumentacją Camunda).
Sposób definiowania elementu Service Task typu External wraz z przykładowym kodem aplikacji jest opisany w artykule Executing automated steps na stronie z dokumentacją Camunda.
Aplikacje realizujące funkcje workera typu External mogą być napisane w dowolnym języku programowania, który obsługuje komunikację HTTP/REST-API (np. C#, Java, Python, Node.js).
Na diagramie BPMN można dodawać wbudowane w EZD RP uniwersalne workery. Od wersji 19 systemu zostały dodane workery:
- ezdrp-worker-zakoncz-proces
- ezdrp-worker-zapisz-dane-do-rejestru
- ezdrp-worker-wizualizuj-proces-pdf
- ezdrp-worker-dodaj-zalaczniki-do-sprawy
- ezdrp-worker-powiadomienie-uzytkownika
- ezdrp-worker-wyslij-email-uzytkownikom-ezdrp
Każdy z podmiotów ma możliwość utworzenia własnych workerów, które będą realizować dopasowaną do ich potrzeb logikę biznesową.
Przejdźmy do omówienia sposobu konfigurowania wymienionych wyżej workerów. Każdy Proces BPMN, który jest uruchamiany w Silniku BPMN za pośrednictwem EZD RP, powinien zostać zakończony przez dodanie workera o nazwie ezdrp-worker-zakoncz-proces (przykład konfiguracji widoczny jest na poniższym zrzucie).
Podczas konfiguracji workera należy w polu Type wybrać z listy opcję External, a następnie w polu Topic wpisać nazwę workera, który będzie obsługiwał zadanie.
Aby skonfigurować worker ezdrp-worker-zapisz-dane-do-rejestru, należy w polu Type wybrać z listy opcję External, a następnie w polu Topic wpisać nazwę workera, który będzie obsługiwał zadanie.
Wymagane jest, aby Schemat BPMN miał przypisany Rejestr BPMN (w Kreatorze Schematu BPMN), inaczej worker zgłosi błąd podczas wykonywania procesu, a proces się zatrzyma.
Aby skonfigurować worker ezdrp-worker-wizualizuj-proces-pdf, należy w polu Type wybrać z listy opcję External, a następnie w polu Topic wpisać nazwę workera, który będzie obsługiwał zadanie.
Pozwala on na każdym etapie działania Procesu BPMN dodać do sprawy wszystkie dostępne załączniki Procesu BPMN (dodawane podczas realizacji Zadania BPMN Użytkownika) lub dodane przez workery (np. ezdrp-worker-wizualizuj-proces-pdf).
Wymagane jest, aby Model Danych Procesu BPMN posiadał Zmienną Procesu CaseSignature, w której przed wywołaniem workera musi być zapisany numer sprawy, do której mają być dodane załączniki.
Z kolei ezdrp-worker-powiadomienie-uzytkownika przeznaczony jest do powiadamiania użytkownika bezpośrednio w systemie EZD RP (ikona dzwonka). Podczas podłączania go do zadania w Diagramie BPMN można użyć widocznego niżej elementu typu Service Task.
Można też zamiast niego zastosować element typu Message Intermediate Throw Event.
Konfiguracja workera jest analogiczna dla obu elementów:
W sekcji Extension Properties należy uzupełnić następujące parametry:
Parametr EZDRP_ENCODED_USERS z wartością 1000 oznacza przekazanie komunikatu do użytkownika, który uruchomił proces. W polu Value można zastosować wszystkie kombinacje opisane do przypisywania użytkowników lub grup do zadania typu User Task (z wyjątkiem komórki organizacyjnej).
Z kolei parametry EZDRP_MESSAGE_HEADER i EZDRP_MESSAGE_BODY służą do przekazania wiadomości dla użytkownika. Jeżeli EZD RP wykryje w komunikacie nazwę Zmiennej Procesu, zamieni ją na wartość, która jest aktualnie w Procesie BPMN.
Aby skonfigurować worker ezdrp-worker-wyslij-email-uzytkownikom-ezdrp, należy w polu Type wybrać z listy opcję External, a następnie w polu Topic wpisać nazwę workera, który będzie obsługiwał zadanie.
Dodatkowo należy skonfigurować następujące atrybuty:
Konfigurując parametr Name, poza EZDRP_EMAIL_TO, do dyspozycji mamy również: EZDRP_EMAIL_DW i EZDRP_EMAIL_UDW. Wpisujemy je w pole, oddzielając średnikami. Adresy e-mailowe wpisywane w polu Value również oddzielamy średnikiem.
Dostępny jest też parametr EZDRP_EMAIL_FORMAT – format wiadomości (domyślnie HTML.
Gdy chcemy przekazać e-mail do użytkownika lub grupy użytkowników EZD RP, jako parametr Name ustawiamy odpowiednio: EZDRP_EMAIL_TO_ENCODED_USERS, EZDRP_EMAIL_DW_ENCODED_USERS lub EZDRP_EMAIL_UDW_ENCODED_USERS. W pole Value wpisać należy listę typów stanowisk zdefiniowanych w EZD RP, np. Kierownik, dyrektor (wielkość liter nie ma znaczenia).
Listę należy wpisać w postaci: element1,element2,…,elementN, gdzie każdy z elementów jest zapisany w formacie: RodzajGrupy:Nazwa, np.: TypS:Kierownik, gdzie TypS oznacza grupę typu – Typ stanowiska. Grupa ta jest grupą domyślną. Wpisując grupy domyślne można pominąć element RodzajGrupy:, zapisując go w sposób uproszczony, np.: Kierownik. Wartość 1000 przypisana jest do użytkownika uruchamiającego proces.
Do tworzenia prostych workerów można użyć elementów Service Task typu Internal, które są wykonywane bezpośrednio w Silniku BPMN). Jeżeli podmiot nie ma oddzielnej instalacji Silnika Camunda 7, to bez dodania modułu Java może użyć jedynie typu Expression.
EZD RP nie ma dodatkowej obsługi dla tego elementu, więc w razie jego użycia, należy skorzystać ze standardowej dokumentacji Silnika Camunda 7. Zalecane jest używanie workerów typu Internal, które oparte są na elemencie typu Script Task (opisany w dalszej części artykułu).
Przed implementacją workera rekomendowane jest zapoznanie się z artykułem Best practices na stronie z dokumentacją Camunda.
Wbudowane w EZD RP workery działają zgodnie z poniższym schematem:
Workery są uruchamiane cyklicznie, zgodnie z ustalonym harmonogramem zapisanym w konfiguracji EZD RP.
Konfiguracja elementu typu Script Task / Worker
Element Script Task podlega standardowej konfiguracji, zgodnie z dokumentacją Silnika Camunda 7. Zalecane jest używanie języka Groovy.
Przykład 1
Skrypt, który tworzy strukturę XML i zapisuje wynik do zmiennej procesu o nazwie WYNIK_XML:
Przykład 2
Ustawienie w skrypcie wartości dla więcej niż jednej Zmiennej Procesu (VAR1 i VAR2):
Więcej przykładów można znaleźć w dokumentacji Silnika Camunda 7 oraz dokumentacji języka Groovy dostępnej na stronie projektu Apache Groovy.
Przed wdrożeniem skryptu do Diagramu BPMN należy upewnić się, że Silnik Camunda 7 ma zainstalowane i wspiera wybrane biblioteki programistyczne.
Konfiguracja warunków przepływu procesu
Gdy sekwencja zdarzeń w procesie jest w jakiś sposób uwarunkowana, np. zależna od progów kwotowych, możliwych do podjęcia decyzji, kwalifikacji do danej kategorii itp., konieczne staje się odzwierciedlenie tych warunków na diagramie procesu. Narzędziem do tego są m.in. bramki decyzyjne (gateway).
W przypadku bramek decyzyjnych warunki opisuje się na strzałkach przepływu w sekcji Condition (1). Do wyboru mamy dwa typy opisu warunku: Script (2) oraz Expression (3).
Proste warunki można zapisać w typie Expression, który obsługuje zapis w języku JUEL. Więcej informacji na ten temat można znaleźć w artykule Expression Language na stronie z dokumentacją Camunda.
Typ Script obsługuje zapis we wspomnianym już języku Groovy, który umożliwia opis złożonych warunków.
Jak widać na powyższym przykładzie, przepływy wychodzące z jednej bramki mogą być opisane różnymi typami warunków. Uwaga! Istotne jest, aby każda ścieżka była opisana. W innym przypadku Silnik BPMN nie będzie w stanie obsłużyć procesu.
Niezależnie od przyjętego opisu warunku języka, stałymi elementami skryptu są zmienne i ich wartości występujące w formularzu (więcej na ten temat w artykule Formularze EZD RP).
Komunikacja między elementami odbywa się poprzez API. W przedstawionym przykładzie bramkę decyzyjną na formularzu reprezentuje obiekt checkbox (pole wyboru), który użytkownik może zaznaczyć (przybiera wartość „true”, gdy jest zaznaczony, lub „false”, gdy jest odznaczony).
Pole, które stanowi klucz pomiędzy formularzem a przepływem (bramką decyzyjną), na diagramie ma nazwę „ZgodaPrzelozonegocheckbox”.
Inną metodą obsługi warunków na diagramie jest zastosowanie warunkowego zdarzenia pośredniego (conditional boundary event).
Analogicznie jak w przypadku bramek decyzyjnych, również tutaj odwołujemy się do zmiennych i ich wartości obecnych w formularzu. W tym przykładzie na formularzu widoczne jest pole wyboru, którego wartość API ma nazwę „ZwrotdopoprawyCheckbox”.
Więcej informacji na ten temat można znaleźć w artykule Conditional Events na stronie z dokumentacją Camunda.