Projektowanie systemu workflow przy użyciu narzędzia BizAgi Studio

część 1
Definiowanie procesu w notacji BPMN

Instytut Systemów Informatycznych, Wydział Cybernetyki, Wojskowa Akademia Techniczna

Paweł Mieteń, Jarosław Koszela

Wprowadzenie

BizAgi Studio jest środowiskiem, które przekształca procesy zamodelowane w notacji BPMN do aplikacji bez konieczności programowania. BizAgi oferuje zestaw nazrzędzi do graficznego projektowania procesu, tworzenia modelu danych oraz definiowania reguł biznesowych.

Poniższy diagram przedstawia kolejne kroki składające się na cykl tworzenia aplikacji:

Rysunek . Cykl tworzenia aplikacji

Definiowanie procesu przy użyciu notacji BPMN

Aby rozpocząć projektowanie procesu należy uruchomić narzędzie BizAgi Studio i następnie utworzyć nowy projekt.

Rysunek . Tworzenie nowego projektu (krok 1)

Na pierwszym ekranie należy wybrać opcję New.

Rysunek . Tworzenie nowego projektu (krok 2)

Kolejnym krokiem jest nadanie nazwy projektu, w naszym przypadku będzie to TutorialBizAgi.

Rysunek . Tworzenie nowego projektu (krok 3)

Ostatnim etapem tworzenia projektu jest automatyczne skonfigurowanie projektu przez narzędzie, oraz utworzenie bazy danych, w której będzie zapisywany stan naszego projektu. BizAgi Studio utworzy bazę danych o nazwie TutorialBizAgi.

Po utworzeniu projektu, zostanie otwarte główne okno narzędzia:

Rysunek . Główne okno narzędzia BiaAgi Studio

Tworząc aplikacje przy użyciu BizAgi Studio, rozpoczynamy pracę od zdefiniowania procesu. W tym celu wybieramy opcję New Process.

Rysunek . Tworzenie nowego procesu

W pole „Proces Name” wpisujemy nazwę procesu. W naszym przypadku będzie to „Składanie wniosku o poprawę egzaminu”.

Rysunek . BizAgi Process Modeler

Tworzenie procesu odbywa się w zintegrowanym narzędziu o nazwie „BizAgi Process Modeler”.

Po lewej stronie okna mamy paletę, w której znajdują się elementy, z których budujemy Proces.

• Flow (Przepływ)

  • Task (zadanie) – Element ten symbolizuje pracę wykonywaną w procesie.

  • Start Event (zdarzenie początkowe) – Inicjuje/określa początek przepływu procesu.

  • Intermediate Event (zdarzenie pośrednie) – Jest to element znajdujący się wewnątrz procesu, który określa punkt oczekiwanie na jakieś zdarzenie. Element ten nie rozpoczyna i nie kończy procesu.

  • End Event (zdarzenie końcowe) – Element ten wskazuje miejsce zakończenia procesu.

  • Gateway (brama logiczna) – Jest to element decyzyjny, który steruje przepływem, uaktywniając odpowiednie ścieżki w zależności od reguł biznesowych. Bramy mogą rozdzielać lub łączyć przepływy.

• Artifacts (Artefakty) - elementy graficzne nie będące elementem przepływu.

  • Group (grupa) – element grupujący inne elementy diagramu. Stosowany w celu zwiększenia przejrzystości procesu.

  • Annotation (adnotacja) – Jest to element tekstowy pozwalający opisać diagram.

  • Data Object (dane) – Element pozwalający opisać dokumenty i inne obiektu wykorzystywane podczas procesu.

• Swimlines (Miejsca realizacji procesu/tory pływackie)

  • Line (tor) – Tory służą do podziału procesu w sposób horyzontalny. Zazwyczaj reprezentują osobę, rolę lub system, do którego należy wykonanie zadań znajdujących się wewnątrz.

  • Milestone (kamienie milowe) – Elementy te służą do podziału procesu na logiczne części, reprezentujące etapy systemu.

• Connectors (Połączenia)

  • Sequence Flow (Sekwencja przepływu) – Element ten określa kolejność wykonywania się odpowiednich aktywności wewnątrz procesu.

  • Association (Asocjacja) – Połączenie to łączy ze sobą artefakty i obiekty przepływu.

W modelowanym procesie wyodrębnimy cztery role: student, dziekanat, dziekan i księgowość. W związku z tym z wcześniej opisanej palety na nasz diagram przenosimy czterokrotnie ikonkę „Line” i ją upuszczamy. Każdy tor nazywamy zgodnie z rolami. Czynimy to przez dwuklik na nazwie lub na kliknięciu na nazwę i wpisaniu nowej nazwy w okienku „Element Properties” na dole głównego okna. Druga metod umożliwia wpisanie polskich znaków. W analogiczny sposób zmieniamy nazwę każdemu innemu elementowi na diagramie.

Rysunek . Zdefiniowanie torów

Kolejnym krokiem jest wyodrębnienie etapów procesu, tak zwanych kamieni milowych. Do tego celu użyjemy elementu „Milestone”. Trzy krotnie przeciągamy go na diagram procesu i odpowiednio ustawiamy nazwy: przyjmowanie wniosku, dokonanie wpłaty, odbiór dokumentów.

Rysunek . Zdefiniowanie torów i kamieni milowych

Proces będzie inicjowany przez studenta, a więc element „Start event” umieszczamy w torze studenta w pierwszym etapie. Jego pierwszym zadaniem będzie złożenie wniosku, w związku z tym obok elementu startowego umieszczamy „Task” i nazywamy go odpowiednio. Oba elementy łączymy elementem „Sequence Flow”, również przeciągniętym z lewego panelu.

Rysunek . Rozpoczęcie procesu

System daje inny sposób dodawania nowych elementów do procesu. A mianowicie chcąc dodać kolejny element do przepływu, połączony elementem „Sequence Flow” należy kliknąć na obiekt, z którego ma wychodzić strzałka. W tym momencie pojawią się elementy, które mogą być następnymi w procesie. Należy chwycić odpowiedni i umieścić go w dowolnym miejscu.

Rysunek . Element "Start event" w trybie tworzenia następnego elementu

Rysunek . Element "Task" w trybie tworzenia następnego elementu

Jak widać drugi sposób jest znacznie szybszy i wygodniejszy.

Pierwszy etap procesu wygląda następująco:

Rysunek . Przyjmowanie wniosku - pierwszy etap procesu

Powyższy proces możemy opisać słownie w następujący sposób:

1. Student składa wniosek o poprawę egzaminu

2. Dziekanat poobiera dane o studencie z serwisu zewnętrznego

3. Dziekanat decyduje czy wniosek jest prawidłowo złożony i czy student spełni warunki formalne

   1. Jeśli student definitywnie nie spełnia warunków formalnych to wniosek zostaje odrzucony oraz wygenerowany zostaje sygnał(powstaje inicjatywa) o skreślenie go z listy studentów. Koniec procesu.

   2. Jeśli wniosek wymaga dodatkowych czynności ze strony studenta to należy go o tym poinformować (przejście do punktu 4.)

   3. Wniosek poprawny formalnie, więc zostaje przyjęty i przekazany do dziekana(przejście do punktu 5.)

4. Student dokonuje wymaganych czynności (przejście do punktu 3.)

5. Dziekan ostatecznie rozpatruje wniosek.

   1. Dziekan odrzuca wniosek, co kończy proces oraz wygeneruje sygnał(powstaje inicjatywa) o skreślenie danej osoby z listy studentów.

   2. Dziekan przyjmuje wniosek(Przejście do punktu 6.)

6. Dziekanat wysyła informacje do studenta, że jego wniosek został przyjęty.

Porównując oba opisy tego samego procesu łatwo dostrzec, że reprezentacja graficzna jest łatwiejsza w zrozumieniu. A sama notacja jest na tyle intuicyjna, że osoba niemająca doświadczenia jest w stanie zrozumieć sens procesu.

Rysunek . Nadawanie typu zadaniu

Rysunek . Service Task

Zadaniu „Pobieranie informacji o studencie” nadaliśmy typ „Service Task”, co oznacza, że zadanie to będzie korzystało z serwisu zewnętrznego. Narzędzie umożliwia nam transformacje zadania do jednego z powyżej zaprezentowanych typów. Robi się to przez menu kontekstowe, a więc należy kliknąć na dany element, wcisnąć prawy przycisk myszy a następnie wybrać odpowiednią opcję.

Rysunek . Pętla wykorzystująca bramę logiczną

Zgodnie z zastosowaniem element w kształcie rombu użyliśmy do stworzenia pętli. Brama logiczna służy do sterowania przepływem. W powyższym przypadku, w zależności od akcji podjętej na zadaniu „Przyjmowanie wniosku do rozpatrzenia”, proces może obrać jeden z trzech przewidzianych wariantów. W przypadku „Odrzucenia warunkowego” przechodzimy do kroku „Dokonanie wymaganych czynności” i ponownie wracamy do przyjmowania wniosku.

Rysunek . Send Task

Kolejnym przykładem użycia zadania określonego typu jest task „Wysłanie wiadomości o przyjęciu wniosku”, któremu nadaliśmy typ „Send Task”. Opcja ta została ustawiona po przez menu kontekstowe, w analogiczny sposób jak w przypadku „Service Task”.

Rysunek . Nadawanie typu dla zdarzenia końcowego

Rysunek . End Event - Signal

W pierwszym etapie naszego przykładu możliwe jest zakończenie całego procesu. Koniec procesu oznaczony jest po przez czerwoną obręcz. „End Event” również może przyjmować jeden z kilku typów. Nasze zdarzenie końcowe otagowaliśmy typem „Signal”. Oznacza to, że w trakcie zakończenie zostanie wygenerowany sygnał, który np. może zostać wykorzystany do automatycznego uruchomienia innego procesu.

Rysunek . Dokonanie wpłaty - Drugi etap procesu

Kolejnym etapem w naszym procesie jest „Dokonanie wpłaty”. System oczekuje na wpłatę 5 dni, jeśli w tym czasie nie zostanie odnotowane wpłynięcie pieniędzy to proces zostanie zakończony. W przypadku, jeśli księgowa odnotuje wpłynięcie pieniędzy na konto rozpocznie się podproces księgowania wpłaty.

Rysunek . Wykorzystanie Event Based Gateway oraz zdarzeń Intermediate Event

Rysunek . Nadawanie typu bramce logicznej

Rysunek . Bramka logiczna typu "Event Base Gateway"

Jeśli chcemy, aby proces obrał różny przebieg w zależności od zdarzenia, które zajdzie najwcześniej, należy użyć bramki logicznej i ustawić jej typ „Event Based Gateway”. Następnie trzeba dodać zdarzenia pośrednie. System wybierze jedną ze ścieżek, a mianowicie tę, na której pierwszej zajdzie zdarzenie.

Rysunek . Nadawanie typu zdarzeniu pośredniemu

Rysunek . Zdarzenie pośrednie typu "Timer"

Rysunek . Właściwości zdarzenia pośredniego typu "Timer"

Aby zdarzenie odpaliło się po pięciu dniach należy wejść we właściwości obiektu i w parametrze „Duration” ustawić odpowiednią wartość.

Kolejnym korkiem w naszym procesie jest podproces „Zaksięgowanie wpłaty”. Aby go utworzyć należy najpierw zapisać aktualny proces oraz przejść do głównego okna w narzędziu BizAgi Studio, gdzie będziemy mogli dodać nowy proces, który następnie podepniemy jako podproces.

Rysunek . Dodanie nowego procesu - Zaksięgowanie wpłaty

Analogicznie jak to robiliśmy w na początku należy dodać nowy proces. Nazwijmy go „Zaksięgowanie wpłaty”. Po utworzeniu procesu opuśćmy go i powróćmy do głównego procesu. Proces księgowania wpłaty zamodelujemy na końcu.

Rysunek . Główne okno BizAgi Studio - zmienianie kontekstu procesu

W celu powrócenia do głównego procesu należy zmienić kontekst pracy narzędzia. W tym celu w prawnym górnym rogu okna należy z listy rozwijanej wybrać odpowiedni proces. Następnie trzeba kliknąć opcję „Edit Process”.

Rysunek . Stworzenie podprocesu

Rysunek . Podproces

W celu wykorzystanie uprzednio stworzonego procesu w głównym procesie należy dodać Task’a, nadać mu odpowiednią nazwę oraz z menu kontekstowego wybrać opcję „Transfer to subprocess”. Operacja ta uruchomi kreator za pomocą, którego będziemy mogli skonfigurować odpowiednio podproces.

Rysunek . Podproces - wybieranie typu

Do wyboru mamy cztery rodzaje procesów:

• Embedded –Podproces wbudowany jest aktywnością, która zwiera inne aktywności. Pracuje on na danych głównego procesu. Nie istnieje możliwość wykorzystanie tego podprocesu w innym miejscu w tym procesie ani żadnym innym.

• Resuable – Podproces wielokrotnego użytku jest aktywnością, która wywołuje inny proces. Istnieje możliwość przekazania danych z głównego procesu do podprocesu oraz w drugą stronę.

• Multiple – Wielokrotny podproces umożliwia wywołanie go wielokrotnie. Ilość wywołań zdefiniowana jest przez określona liczbę lub przez liczność kolekcji danych. Kolejne wywołania mogą działać w trybie równoległym lub sekwencyjny.

• Transactional – Transakcyjny podproces daje nam mechanizm potwierdzający, że dana partia aktywności wykonała się w całości poprawnie lub cała została wycofana.

W naszym przypadku użyjemy opcji „Resuable”.

Rysunek . Podproces - procesu

Kolejnym krokiem jest wybranie procesu, który będzie uruchamiany w ramach tej aktywności. Wybieramy uprzednio stworzony proces „Zaksięgowanie wpłaty”.

Rysunek . Wybranie trybu pracy podprocesu

Do dyspozycji mamy dwa tryby:

• Integrated – tryb ten oznacza, że dany podproces musi się zakończyć zanim główny proces przejdzie do następnego kroku.

• StandAlone –opcja ta pozwala w procesie głównym kontynuować przebieg, bez znaczenia na jakim etapie jest pod proces.

W naszym przypadku wybieramy tryb StandAlone, co oznacza, że dziekanat może wydać karty poprawkowe studentowi nie czekając na zakończenie procesu księgowania wpłaty.

Rysunek . Odbiór dokumentów - Trzeci etap procesu

Ostatnim etapem całego procesu jest „Odbiór dokumentów”. Dziekanat równolegle przygotowuje karty poprawkowe oraz wprowadza odpowiednie dane do systemu E-dziekanat. Po zakończeniu obu tych kroków, może wydać dokumenty studentowi.

Rysunek . Przebieg równoległy

W celu uruchomienia wielu równoległych wątków w przebiegu procesu należy użyć bramki logicznej typu „Parallell Gateway”. Aby sprowadzić rozdzielone wątki ponownie do jednego przebiegu, również trzeba użyć tej samej bramki. Bramka ta będzie oczekiwać, do póki nie spłyną do niej wszystkie doprowadzone wątki.

Rysunek . Widok całego procesu

W celu manipulowania wielkością diagramu należy wcisnąć przycisk Ctrl oraz użyć scrolla w myszce.