System sterowania przepływem pracy w środowisku Oracle Workflow

Rozdział 5 System sterowania przepływem pracy w środowisku Oracle Workflow Streszczenie. Opracowanie przedstawia możliwość tworzenia aplikacji z użyciem diagramów sterowania przepływem pracy. Jako silnik workflow wykorzystano produkt Oracle Workflow, który jest bardzo dobrze zintegrowany z bazą danych Oracle. Posiada on m.in. narządzie graficzne do tworzenia definicji procesu oraz umożliwia wykonywanie procedur składowanych PL/SQL. Aplikacja przybrała formę witryny internetowej, w której praca będzie możliwa z dowolnego miejsca sieci. Wykorzystano tutaj technologię Java Server Faces, która umożliwia efektywne i szybkie tworzenie witryn internetowych. Aplikacja nie ogranicza się tylko do jednego konkretnego przypadku, ale zaimplementowano framework, co pozwoli na łatwe dostosowanie do dowolnej definicji procesu. Takie podejście do problemu umożliwia zastosowanie systemu w wielu dziedzinach. 1 Wstęp Jednym z podstawowych wyznaczników jakości tworzonego oprogramowania jest jego elastyczność. Zmiany, jakie zachodzą w środowisku, w którym aplikacja pracuje, wymuszają wprowadzanie poprawek w działaniu logiki systemu. Przy tradycyjnym modelu tworzenia oprogramowania, w którym reguły logiki biznesowej zaimplementowanie są w kodzie aplikacji, konieczność wprowadzania zmian jest bardzo trudna, a przede wszystkim czasochłonna. W systemach korporacyjnych, gdzie zmiany reguł biznesowych następują często takie rozwiązanie nie spełnia swojego zadania. W związku z tym, że opis reguł biznesowych, jest bardzo silnie sformalizowany można je bardzo łatwo przełożyć na postać definicji procesu. Dlatego też w systemach, które muszą szybko reagować na zmiany, często logika biznesowa implementowana jest w postaci diagramów przepływu pracy. Diagramy te umieszczane są następnie na serwerze workflow, który zarządza ich wykonywaniem. Takie rozwiązanie zapewnia elastyczność, której nie bylibyśmy w stanie osiągnąć umieszczając reguły w kodzie aplikacji. Teraz jeżeli chcemy zmienić logikę działania aplikacji zmieniamy definicję procesu, a w konsekwencji aplikacja zmienia sposób swojego działania. Aby sprawnie działać aplikacja i proces muszą się wzajemnie komunikować. W tym celu serwer workflow musi udostępniać interfejs umożliwiający zarządzanie procesem przy Sławomir Wiak, Paweł Drzymała, Henryk Welfle, Marek Kazimierczuk Politechnika Łódzka, Instytut Mechatroniki i Systemów Informatycznych, ul. Stefanowskiego 18/22, 90-924 Łódź, Polska email: {wiakslaw, pdrzymal, henryk.welfle}@p.lodz.pl

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk użyciu zewnętrznego systemu. Powinien on mieć możliwość uruchamiania nowego procesu, odczytywania jego stanu oraz posiadać dostęp do wszelkich danych zawartych w jego definicji, które są niezbędne do prawidłowego działania. Oracle Workflow nie dysponuje jednak dobrym interfejsem umożliwiającym zarządzanie procesem z poziomu języka Java. Dlatego niezbędną rzeczą było opracowanie koncepcji, a następnie implementacja sposobu komunikacji pomiędzy silnikiem workflow i aplikacją. Dane o procesie pobierane są z serwera, a następnie transformowane na obiekty języka Java poprzez wykorzystanie technologii mapowania obiektowego Hibernate. W ten sposób stworzono bardzo elastyczne i funkcjonalne Java API. 2 Systemy sterowania przepływem pracy Systemy sterowania przepływem pracy w są produktem stosunkowo młodym. Większość liczących się firm takich jak Oracle lub JBOSS posiada w swojej ofercie systemy klasy workflow jednakże, w odróżnieniu od systemów bazodanowych, znajdują się one dopiero w początkowej fazie rozwoju. Ich pozycję na rynku najlepiej prezentuje krzywa ekscytacji. Jako technologia porównawcza zostały przyjęte systemy zarządzania relacyjnymi bazami danych (Relational Database Management Systems - RDBMS). Jak widać z wykresu na rys. 1 systemy workflow oraz Business Process Management (BPM) znajdują się na początku swojej drogi rynkowej. Jest to faza, w której bardzo trudno mówić o standardach, a z drugiej strony pokłada się w produkcie wielkie nadzieje. Rys. 1. Krzywa ekscytacji [1] System sterowania przepływem pracy na wejściu pobiera definicję procesu. 58

System sterowania przepływem pracy w środowisku Oracle Workflow Rys. 2. Interfejsy systemów zarządzania przepływem pracy Diagram przypadków użycia przedstawiony na rys 2. prezentuje cztery główne interfejsy systemów sterowania przepływem pracy oraz obrazuje ich rolę w systemie. Wyróżnione interfejsy są następujące: - Definicji procesu interfejs ten pozwala programiście opracować definicję procesu. Należy zauważyć, że w tym przypadku aktor programista procesu łączy w sobie funkcje jakie pełni analityk biznesowy i programista. - Wykonywania - interfejs pozwala użytkownikom i systemowi oddziaływać na instancje procesu. Instancje procesu to wykonywane definicje procesu. Dwie główne metody w interfejsie wykonywania to startowanie instancji procesu i sygnalizację zakończenia stanu. - Aplikacji interfejs odpowiada za interakcje pomiędzy WFMS (WorkFlow Management System), a systemem zewnętrznym. Kiedy użytkownik albo system zarządza wykonywaniem instancji, generowane są zdarzenia w systemie. Definicja procesu może wyspecyfikować, że dany fragment logiki programowej musi być wykonany przy konkretnym zdarzeniu. Logika programowa może także komunikować się z innymi systemami zewnętrznymi albo wewnętrznymi. - Monitorowania i audytu za pomocą tego interfejsu menadżerowie mogą obserwować statystyki, które są tworzone na podstawie logów powstałych w czasie wykonywania procesu. Logi te mogą również zostać wykorzystane do przeprowadzania audytu. 3 Oracle Workflow Oracle Workflow jest środowiskiem, które dostarcza kompletnej platformy do tworzenia, wykonywania oraz zarządzania procesem biznesowym. Został on utworzony, aby 59

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk zaspokoić coraz większe potrzeby rynku na systemy tego typu. Firmie Oracle udało się utworzyć bardzo dobry produkt, który spełnia wymagania jakie stawia się systemom klasy workflow. Środowisko to jest ściśle zintegrowane z bazą danych Oracle co z jednej strony jest dużą zaletą, gdyż znacznie został ułatwiony dostęp do danych oraz wykonywanie funkcji za pomocą procesu. Z drugiej strony zaś firma zapewnia sobie, że wszyscy chcący korzystać z tej technologii będą musieli wykupić licencję na serwer Oracle. W architekturze Oracle Workflow można wyróżnić cztery główne obszary, z których każdy zawiera wiele oddzielnych komponentów. Rys. 3. Architektura systemu Oracle Workflow [5] Możliwość integracji z pracującymi systemami zewnętrznymi sprawia, iż procesy Oracle Workflow można wdrażać w organizacjach, które posiadają już dedykowane oprogramowanie. Dzięki temu można usprawnić funkcjonowanie firmy czy instytucji. Oracle Workflow zarządza procesem zgodnie z zasadami, które zostały zdefiniowane. Te zasady nie są niczym innym jak definicją procesu zawierającego aktywności (czynności), które pojawiają się w procesie oraz uwzględniającego relacje, jakie panują między nimi. Pod pojęciem aktywności, ukrywa się bardzo wiele elementów. Może to być składowana procedura PL/SQL lub zewnętrzna funkcja, powiadomienie użytkownika albo roli, które może wymagać odpowiedzi albo podproces, który sam także składa się z szeregu aktywności. Proces jest inicjowany w momencie, gdy aplikacja wywołuje zestaw funkcji z Oracle Workflow Engine API. Po uruchomieniu procesu Workflow Engine automatycznie wykonuje kroki i wywołuje odpowiednie usługi, kiedy odwołujemy się do zewnętrznych procesów. Przykład definicji procesu jest przedstawiony na rys 4. 60

System sterowania przepływem pracy w środowisku Oracle Workflow Rys. 4. Proces Oracle Workflow Ikony na diagramie reprezentują aktywności w procesie, a strzałki oznaczają przejścia między nimi. Każdy proces ma poza tym wyróżniony jeden punkt początkowy i co najmniej jeden punkt końcowy. Poprawna definicja procesu jest podstawowym warunkiem działania Oracle Workflow. Jest także fundamentem, na którym będzie budowana aplikacja i dlatego tak ważne jest jej prawidłowe sformułowanie oraz zapewnienie elastycznego modelowania reguł biznesowych. Oracle Workflow do zarządzania definicją procesu dostarcza dedykowane oprogramowanie Workflow Builder. Posiada ono okno Navigator, w którym możemy definiować aktywności i komponenty procesu, a następnie elementy z tego okna wykorzystujemy przy budowie procesu co ma miejsce w oknie budowania definicji procesu. Obydwa komponenty programu widoczne są na rys. 5. Rys. 5. Oracle Workflow Builder 61

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk Proces Oracle Workflow jest zbudowany z komponentów połączonych ze sobą przejściami. Tak więc, aby zbudować definicję procesu należy utworzyć elementy, z których będzie się ona składała. Przy tworzeniu procesu bardzo często spotykamy się z powtarzającymi się zagadnieniami. Oracle Workflow dostarcza zestaw dostępnych w systemie komponentów, które w większości przypadków zaspokajają najczęściej występujące potrzeby. Gdyby jednak ten zastaw nie wystarczał zawsze możemy tworzyć własne elementy do budowy procesu. Potęga Oracle Workflow tkwi w możliwości wywoływania, w trakcie wykonywania procesu, zdefiniowanych przez programistę funkcji. Funkcje można definiować albo za pomocą PL/SQL albo w języku Java. Oczywiście nie każda funkcja może być wykonywania przez proces. Muszą ona spełniać określone warunki, aby mogły być użyte przez workflow. W przypadku funkcji PL/SQL jest to określona forma deklaracji, a gdy mamy do czynienia z funkcja Java dziedziczy ona po klasie WFFunctionAPI. 5 Hibernate Większość aktualnie tworzonego oprogramowania musi mieć możliwość składowania informacji w bazie danych. W obecnej formie baza danych to zbiór tabel z nałożonymi warunkami ograniczającymi. Taki model danych nazywany jest relacyjnym. Jednakże języki oprogramowania, które służą do budowy oprogramowania wykorzystują w większości model obiektowy. Opiera on się na założeniu, iż każdy byt w systemie to obiekt, a działanie aplikacji to wymiana zdarzeń i akcji między obiektami. Programowanie zorientowane obiektowo ułatwia proces tworzenia aplikacji, gdyż model systemu jest bardzo zbliżony do rzeczywistości. Skoro cały program jest zbiorem obiektów to rzeczą naturalną i łatwą dla programisty byłaby możliwość zapisywania obiektów w bazie danych. Jednakże relacyjny model przechowywania danych w bazie nie jest w stanie obsłużyć operacji na obiektach. Dlatego programista aby wykonać operację na bazie danych musi stworzyć odpowiednie zapytanie SQL, połączyć się z bazą danych i je wykonać. Jest to bardzo niewygodnie, a przede wszystkim bardzo mało elastyczne rozwiązanie. Aby uniknąć ciągłego konwertowania obiektów na polecenia SQL powstały narzędzia służące do mapowania obiektowo-relacyjnego, które po odpowiednim skonfigurowaniu umożliwiają wykonywanie operacji zapisywania, aktualizowania, usuwania obiektów do bazy danych. Przykładem takiego narzędzia jest Hibernate, który jest najbardziej popularnym systemem służącym do mapowania obiektów na tabele w bazie danych. W tym rozdziale przedstawiono framework Hibernate wykorzystany w tworzeniu aplikacji w języku Java. Omówię jego architekturę, sposób konfiguracji oraz możliwości jakie daje jego zastosowanie podczas prac nad programem. Architektura Hibernate Miejsce Hibernate w architekturze aplikacji prezentuje Rys. 6. Framework umiejscowiony jest między aplikacją a serwerem bazy danych. Wykonuje on całą niezbędną pracę związaną z utrwalaniem obiektów Java bazując na mechanizmie mapowania obiektowo-relacyjnego. 62

System sterowania przepływem pracy w środowisku Oracle Workflow Rys. 6. Miejsce Hibernate w aplikacji. Hibernate może być bezpośrednio wywoływany z poziomu aplikacji Java lub za pomocą innego frameworka. Najczęściej jest on jednak wykorzystywany aby utworzyć warstwę dostępu do danych umożliwiającą dowolnemu komponentowi programu pracować z bazą danych. Hibernate to obecnie najpopularniejszy na rynku framework służący do odwzorowania obiektów języka programowania na tabele bazy danych. Oprócz platformy dla języka Java Hibernate oferuje także podobne rozwiązanie dla platformy.net. Elastyczność Hibernate sprawia, iż z powodzeniem jest wykorzystywany zarówno w małych jak i zaawansowanych aplikacjach. Jego główną zaletą jest ułatwienie realizacji warstwy dostępu do danych. Aplikacja tworzona jest szybciej, jej koszt jest mniejszy i jest łatwiejsza w utrzymaniu. Ponadto Hibernate współpracuje on z wieloma bazami danych co sprawia, iż migracja z bazy jednego producenta na drugiego nie jest już taka kłopotliwa. Jest to szczególnie ważne w przypadku, gdy wymagane jest wdrożenie systemu na dostępnej już platformie klienta. 6 API do komunikacji z Oracle Workflow Podstawą budowanego projektu jest integracja Oracle Workflow z aplikacjami internetowymi pisanymi w języku Java. W tym celu koniecznością było opracowanie standardu wymiany danych pomiędzy tymi dwoma środowiskami. Aby umożliwić aplikacji Java wykonywanie operacji na workflow opracowałno zestaw funkcji reprezentujący wszystkie niezbędne działania, które są wymagane aby zapewnić aplikacji pełną funkcjonalność. Został z nich utworzony interfejs, który zapewnia aplikacji niezależność od implementacji funkcji dla danego silnika procesowego. Część logiki realizowanej przez funkcje API zostało zapisane w postaci składowanych procedur PL/SQL umieszczonych na serwerze bazy danych Oracle. Są one wywoływane przez Hibernate, który odwzorowuje zwracany przez nie wynik na obiekty Java. W tym rozdziale dokładnie omówiono koncepcję oraz implementację funkcji umożliwiających integrację Java z Oracle Workflow. Aby zarządzać procesem Oracle Workflow z poziomu język Java potrzebne było utworzenie funkcji realizujących to zadanie. Poprzez interfejs OwfDAO został wypracowany zestaw metod, których wykonywanie zapewnia całkowitą kontrolę nad wykonywaną instancją procesu. Dzięki użyciu interfejsu w przypadku wymiany serwera workflow wymagana będzie tylko zamiana implementacji OwfDAO, a reszta aplikacji zostanie bez zmian. Konkretne rozwiązanie napisane dla Oracle Workflow wykorzystuje funkcje PL/SQL, które są wywoływane poprzez Hibernate przez odpowiednie funkcje Java. 63

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk Dzięki takiemu rozwiązaniu udało się wykorzystać dostarczone przez Oracle metody PL/SQL do zarządzania procesem. Implementacja API do komunikacji z Oracle Workflow zapewnia stabilny zestaw metod do zarządzania procesem. Używając go można utworzyć zaawansowaną aplikację, której logika będzie realizowana w postaci diagramu procesu workflow. 7 Implementacja systemu sterowania przepływem pracy. Punkt ten przedstawia przykładową implementację webowego systemu sterowania przepływem pracy. Warstwa prezentacji jest wykonana przy pomocy Java Server Faces, część logiki biznesowej napisana została w języku Java natomiast działanie aplikacji oparte jest na procesie Oracle Workflow. Koncepcja aplikacji opiera się na wykorzystaniu procesu workflow. Takie rozwiązanie ma bardzo wiele zalet. Przede wszystkim można bardzo szybko dostosowywać aplikację do zmieniających się warunków. Wystarczy tylko wprowadzić zmiany w definicji procesu oraz ewentualnie dopisać odpowiednie interfejsy. Działanie aplikacji nie jest ściśle powiązane w silnikiem Oracle Workflow. Nie zostały wykorzystane standardowe metody integracji, gdyż zapewniają one zbytnie uzależnienie od stosowanych technologii. W budowie programu da się wyodrębnić dwa zasadnicze komponenty. Pierwszy związany jest z samą obsługą procesu. Jest to framework, który obsługuje całą funkcjonalność związaną z integracją z systemami workflow. Może on być wykorzystywany bez względu na definicję procesu. Tak więc utworzona została platforma, która może być użyta przy realizacji każdej aplikacji opartej o Oracle Workflow. Nie musi być ona za każdym razem pisana od nowa, ani także dostosowywana do potrzeb klienta. Drugą częścią składową aplikacji są elementy, które są specyficzne dla danej aplikacji. Składa się na nią schemat bazy danych, definicja procesu oraz interfejsy webowe. Skoro część logiki aplikacji realizowana jest w postaci definicji procesu to należy go zaprojektować indywidualnie dla każdego przypadku. Stanowi on fundament działania programu, dlatego wymaga starannego przygotowania. Jest to zadanie, które powinno być wykonywane przez analityka lub projektanta procesu. Niezbędna przy tym jest ścisła współpraca z klientem, gdyż to jego wymagania mamy zaspokoić. Schemat procesu jest bardzo naturalny do analizowania w porównaniu do innych technik projektowania aplikacji. Dlatego klient może bardzo łatwo wychwycić błędy już na wczesnym etapie tworzenia oprogramowania. Im wcześniej wychwycone są błędy tym łatwiej i szybciej można je usunąć. W zależności od zadania, które trzeba będzie zrealizować należy zaprojektować schemat bazy danych przechowujący informacje specyficzne dla konkretnego przypadku. Ta część nie może być uniwersalna, gdyż trudno jest utworzyć taki zestaw tabel, który zaspokajałby wszystkie wymagania. Warto zaznaczyć, iż nie przechowuje on żadnych informacji dotyczących elementów związanych z obsługą workflow. Za to odpowiedzialny jest schemat danych Oracle Workflow. W tym momencie dobrze widoczny jest podział aplikacji na dwie części. Pierwszą związana z zarządzaniem procesem dowolnego typu i drugą wykonaną specjalnie dla danego przypadku. Założeniem aplikacji było umożliwienie posługiwania się nią za pomocą przeglądarki internetowej. 64

System sterowania przepływem pracy w środowisku Oracle Workflow Rys. 7. Architektura przykładowego sytemu sterowania przepływem pracy. Całość programu ma dodatkowo działać w oparciu o proces workflow. Wymagania projektowe wpłynęły na architekturę systemu, która jest zaprezentowana na rys. 7. Klientem końcowym aplikacji jest przeglądarka internetowa. Przez nią będą wykonywane wszystkie procesy. Takie rozwiązanie sprawia, iż z dowolnego komputera podłączonego do sieci będzie można z korzystać z aplikacji. Centralne przechowywanie programu upraszcza proces wprowadzania zmian, gdyż cały kod znajduje się w jednym miejscu i wszystkie wymagane zmiany są od razu dostępne dla użytkowników. Eliminuje to także problem aktualizowania wersji. Skoro jest to dynamiczna aplikacja internetowa to wymaga serwera, który przetwarza żądania użytkowników. Zdecydowałem się na użycie kontenera Tomcat. Jest on udostępniany za darmo przez firmę Apache. W warstwie prezentacji został wykorzystany framework Java Server Faces. Umożliwia on bardzo szybkie tworzenie interfejsów użytkownika, gdyż udostępnia szereg komponentów reprezentujących określony zestaw znaczników języka HTML. Logika obsługująca zachowanie elementów strony internetowej napisana jest w języku Java. W warstwie dostępu do danych korzystam z Hibernate, który zarządza wymianą informacji pomiędzy warstwą logiki a repozytorium bazy danych. Program będzie wykorzystywał dwa schematy bazy danych. Pierwszy to schemat Oracle Workflow zawierający dane związany z wykonywaniem procesu. Drugi przechowuje informacje ściśle związane z aplikacją. 7.1 Założenia aplikacji Aplikacja ma wspomagać proces obsługi studentów w dziekanacie. Jej głównym zdaniem jest umożliwienie studentom przejście przez wybrany proces za pomocą przeglądarki internetowej. Praktycznie każda sytuacja związana ze studiowaniem ma charakter procesu. Wyspecyfikowane są kroki, które muszą mieć miejsce oraz określone są wymagania jakie mają być spełnione. Skoro wszystko odbywa się na zasadzie procesu to można go usprawnić poprzez zautomatyzowanie. Zostanie zbudowana definicja procesu, która będzie odzwierciedlała proces obsługi studenta w dziekanacie. Na niej będzie opierać się działanie aplikacji. Dodatkowo zostanie udostępniona możliwość pobierania danych o studentach i o ich ocenach osiąganych w danych semestrach poprzez integracje z zewnętrznymi 65

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk systemami. System ma obsługiwać kilka przypadków użycia. Pierwszy zaprezentowany jest diagram przypadków dla aktora student. Jest on przedstawiony na rys. 8. Rys. 8. Diagram przypadków użycia dla aktora student Student jak każdy użytkownik przed skorzystaniem z systemu musi się zalogować. Następnie powinien mieć możliwość podejrzenia jakie zadania ma do wykonania. System pozwala studentowi zadać pytanie do dziekanatu. Dodatkowo poprzez aplikację udostępniona jest możliwość występowania z podaniem o stypendium sportowe, a także o stypendium socjalne. Oba te przypadki są związane są z uruchomieniem nowej instancji procesu. Kolejny przypadek użycia został przedstawiony dla aktora Dziekanat. Jest on przedstawiony na rys. 9. Rys. 9. Diagram przypadków użycia dla aktora dziekanat Głównym zadaniem aktora Dziekanat jest reagowanie na akcje podjęte ze strony aktora Student. Wszystkie funkcjonalności są dostępne po zalogowaniu. Przede wszystkim odpowiada on na zadane pytania oraz podejmuje decyzje o przyznaniu stypendium 66

System sterowania przepływem pracy w środowisku Oracle Workflow sportowego. Ma on także możliwość uruchamiania procesu ale musi to zrobić w imieniu któregoś ze studentów. Kolejnym aktorem wyodrębnionym w systemie jest Akademicki Związek Sportowy (AZS). Jego diagram przypadku użycia jest przedstawiony na rys. 10. Rys. 10. Diagram przypadków użycia dla aktora AZS Podobnie jak w innych sytuacjach aktor AZS będzie odpowiedzialny za realizację przypadku użycia związanego z opiniowaniem. Jego działanie jest wymagane, gdy aktor Student będzie wystąpi z prośbą przyznanie stypendium sportowego. Do jego otrzymania niezbędna jest opinia AZS na podstawie której podejmowana jest decyzja. 7.2 Definicja procesu Na podstawie wymagań jakie ma spełniać aplikacja oraz bazując na przypadkach użycia rozpisanych na poszczególnych aktorów systemu, została utworzona definicja procesu. Zadanie ( Item type ) wspomagające obsługę studenta w dziekanacie składa się z trzech procesów. Pierwsze to proces główny, a dwa następne są to podprocesy odpowiadające za przyznawanie stypendium socjalnego oraz sportowego. Ich lista przedstawiona jest na rys.11. Zanim zostanie omówiona budowa procesu należy wspomnieć o atrybutach zadania (item type), które zostały zdefiniowane. Pokazane są one na rys.11 wraz z procesami. Atrybuty Student, Dziekanat oraz AZS są typu Role. Odpowiadają one grupom użytkowników, którzy biorą udział w procesie. Atrybut StudentID przechowuje wartość liczbową określającą, identyfikator studenta będącego podmiotem wykonywania instancji. 67

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk Rys. 11. Lista atrybutów i procesów zdefiniowanych w ramach jednego item type. Proces główny pokazany jest na rys. 12. Po jego uruchomieniu wykonywanie zatrzymuje się na pierwszej notyfikacji Start. Ma ona za zadanie poinformowanie o możliwościach systemu. Jej wykonawca, którym jest osoba z grupy Student może kontynuować proces lub zakończyć go. W przypadku gdy nie zostanie podjęta przez 30 minut żadna akcja workflow skorzysta ze ścieżki przejścia oznaczonej jako timeout. Prowadzi ona do zakończenia wykonywania instancji. W ten sposób można się zabezpieczyć przed instancjami, które zostały pomyłkowo uruchomione lub przed tymi, których wykonanie zostało zaniechane. Jeżeli użytkownik zadecydował o kontynuowaniu to następuje przejście do następnego kroku Cel studenta. Jego wykonawcą jest również rola Student. Z tego miejsca należy zadecydować jaką sprawę chcemy zrealizować. Do wyboru jest wniosek o stypendium oraz możliwość zadania pytania. Na podjęcie decyzji jest pięć minut. Po tym czasie workflow skorzysta z ścieżki timeout i zakończy wykonywanie instancji. W przypadku gdy celem jest zadanie pytania użytkownik zostaje przekierowany do notyfikacji Zapytanie. Do tego kroku dołączony jest interfejs webowy, w którym użytkownik będzie miał możliwość wprowadzenia swojego pytania, które zostanie zapisane w bazie danych. Po wykonaniu tej notyfikacji wykonanie procesu przechodzi do miejsca, w którym następuje wstępna selekcja jego pytania przez osobę, która należy do grupy Dziekanat. Notyfikacja Rozpatrz zapytanie ma za zadanie wstępną ocenę pytania w celu dopuszczenia go do fazy odpowiedzi. W przypadku gdy pytanie zostało ocenione negatywnie następuje zakończenie procesu. Jeżeli tak się nie stało następuje przejście do dwóch równoległych wykonań procesu. Jedna gałąź, wraz z notyfikacją Zapytanie rozpatrywane, jest informacją dla roli Student, iż jego pytanie zostało wstępnie zaakceptowane i powinien oczekiwać na odpowiedź. Jest to ostatni moment w którym można jeszcze wycofać zadane pytanie poprzez wybranie opcji Zakończ. Druga gałąź zawiera notyfikację Odpowiedz, która jest przypisana do roli Dziekanat. W tym miejscu podczepiony jest interfejs, za pomocą którego osoba wykonująca może udzielić odpowiedzi na zadane pytanie. Notyfikacja pozwala także na anulowanie procesu poprzez wybranie Zakończ. Równoległe ścieżki wykonywania połączone są w jednym miejscu za pomocą funkcji And. Powoduje ona, iż proces będzie czekał aż obydwie notyfikacje zostaną wykonane. Gdy tak się stanie następuje przejście do Odpowiedz na zadane przez Ciebie pytanie, w której student w imieniu którego został uruchomiony proces otrzymuje odpowiedź. Po zapoznaniu się z nią następuje zakończenie wykonywania instancji procesu. 68

System sterowania przepływem pracy w środowisku Oracle Workflow Rys. 12. Schemat głównego procesu Jeżeli student chciałby złożyć wniosek o przyznanie stypendium powinien w kroku Cel studenta wybrać opcję Stypendium. Proces przejdzie wtedy do kroku Rodzaj stypendium. Należy w nim określić o jakie stypendium chodzi. Możliwymi opcjami są stypendium sportowe oraz naukowe. Gdy zamiarem jest złożenie wniosku o stypendium sportowe należy wybrać odpowiednią opcję. Następuje wtedy uruchomienie procesu odpowiedzialnego za tą funkcjonalność. W tym przypadku jest to proces o nazwie Sportowe. W odróżnieniu od procesu głównego musi się on zakończyć się określonym rezultatem. Jest on ustawiany w oknie właściwości w polu Result type. W przypadku obydwu podprocesów jest to lookup type Warunki na stypendium, który posiada dwa lookup code: Nie spełnił wymagań oraz Spełnił wymagania. Na ich podstawie student jest informowany czy jego wniosek został rozpatrzony pozytywnie czy nie. Schemat procesu przyznawania stypendium sportowego jest zaprezentowany na rys.13. Rys. 13. Diagram procesu przyznawania stypendium sportowego 69

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk Od razu po rozpoczęciu wykonywania proces dzieli się na dwie równoległe ścieżki. Trafiają one do dwóch notyfikacji Uzasadnienie i Opinia AZS. Wykonywanie Uzasadnienia jest przypisane do roli Student. To w tym momencie osoba wnioskująca o stypendium sportowe powinna napisać, dlaczego uważa, że powinna je dostać. W tym miejscu jest podczepiony interfejs umożliwiający wprowadzenie oraz wysłanie uzasadnienia. Wykonanie notyfikacji Opinia AZS jest przeznaczone dla grupy AZS. Gdy aplikacja dotrze do tego kroku użytkownikowi zostanie wyświetlony formularz, w którym będzie musiał wyrazić swoją opinię na temat studenta wnioskującego o stypendium. Obydwie notyfikacje muszą się wykonać, aby proces mógł kontynuować wykonanie. Jest to zapewnione poprzez użycie funkcji And. Kolejnym krokiem, jest decyzja o przyznaniu stypendium. Dokonuje się tego w notyfikacji Zatwierdzenie stypendium sportowego. Wykonuje ją osoba z roli Dziekanat. Na podstawie uzasadnienia oraz opinii AZS podejmuje ona decyzję. W zależności od niej proces kończy swoje działanie z odpowiednim wynikiem. Sterowanie jest przekazywane z do procesu głównego. Na podstawie rezultatu zwracanego przez proces Sportowe następuje przejście albo do notyfikacji Decyzja o stypendium pozytywna albo do Odmowa przyznania stypendium. Za ich pomocą student jest informowany o tym czy jego wniosek został rozpatrzony pozytywnie. Jeżeli zapoznał się z decyzją to następuje zakończenie instancji procesu. Drugi z podprocesów obsługuje przypadek przyznawania stypendium naukowego. Jego schemat pokazany jest na rys.14. Rys. 14. Diagram procesu przyznawania stypendium naukowego Podobnie jak w przypadku procesu realizującego przyznawanie stypendium sportowego, zwracanym wynikiem jest albo Spełnił wymagania albo Nie spełnił wymagań. Ten proces nie posiada żadnych zadań, które wymagają ingerencji użytkownika, wszystkie kroki są wykonywane automatycznie. Jest to realizowane poprzez funkcje PL/SQL, które są podpięte do danych aktywności. Po uruchomieniu tego procesu wykonują się dwie metody. Pierwsza Złożenie indeksu w terminie sprawdza czy student nie przekroczył terminu składania indeksów w dziekanacie. Jeżeli zrobił to wystarczająco wcześnie zwracany jest wynik Yes. W przeciwnym przypadku No. Zbyt późne oddanie indeksu sprawia iż proces kończy się z wynikiem Nie spełnił wymagań. Odbywa się to poprzez funkcję Or. Druga funkcja Odpowiednia średnia ma za zadanie sprawdzić w systemie czy student uzyskał odpowiednio wysoką średnią niezbędną do uzyskania stypendium naukowego. Na podstawie danych dostępnych w systemie następuje wyliczenie średniej dla aktualnego 70

System sterowania przepływem pracy w środowisku Oracle Workflow semestru oraz porównanie jej z wartością progową. Gdy zostanie ona przekroczona funkcja zwraca wynik Yes. W przypadku posiadania zbyt niskiej średniej rezultatem zwracanym jest No. Oba warunki muszą być spełnione, aby osoba mogła otrzymać stypendium. Dlatego została użyta funkcja And która zapewnia, iż tylko w przypadku gdy obydwie funkcje zwrócą Yes proces zakończy się z rezultatem pomyślnym. Funkcja Or natomiast powoduje zakończenie wykonywania procesu z rezultatem negatywnym w przypadku gdy któraś w funkcji, sprawdzających warunki do przyznania warunków, zwróci wartość No. Gdy proces Naukowe zakończy się sterowanie zostaje przekazane do procesu głównego. W zależności od zwróconego wyniku zostaje wykonana jedna z notyfikacji: Decyzja o stypendium pozytywna albo do Odmowa przyznania stypendium. Służą one do informowania studenta jaka decyzja została podjęta. Po zapoznaniu się z nią proces kończy się. 7.3 Schemat bazy danych Dla części aplikacji, która nie jest bezpośrednio związana z wykonywaniem procesu należało przygotować odpowiedni schemat bazy danych, który umożliwia przechowywanie danych, z którymi aplikacja bezpośrednio pracuje. Diagram jest przedstawiony na rys.15. Rys. 15. Schemat bazy danych aplikacji. Aplikacja przydziela uprawnienia na podstawie grup, do których należy użytkownik. Informacja o nich przechowywana jest w tabeli MGR_ROLES_T. Zawiera ona dwie flagi, 71

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk które umożliwiają realizację uprawnień. Kolumna START_PROCESS służy do określenia czy dana rola ma uprawnienie do rozpoczynania procesu. Natomiast za pomocą kolumny PROCESS_OWNER można decydować czy użytkownicy danej roli mogą występować jako właściciele procesu. Pytania zadane przez studenta przechowywane są w tabeli MGR_QUESTIONS_T. Treść pytania umieszczana jest w kolumnie CONTENT. Dodatkowo przy wprowadzaniu pytania należy wybrać kategorię, do której ono należy. Kategorie zdefiniowane są w tabeli słownikowej MGR_QUESTION_TYPES_T. W tabeli z pytaniami jest utworzony klucz obcy na polu PRIORITY_ID odnoszący się do klucza głównego danej kategorii. Oprócz kategorii należy wybrać jaki priorytet ma pytanie. Priorytety są przetrzymywane w tabeli MGR_PRIORITIES_T. Odwołanie do nich następuje poprzez klucz obcy na polu PRIORITY_ID w tabeli MGR_QUESTIONS_T. Każde pytanie zadane jest przez konkretnego użytkownika, więc informacja o nim musi być utrwalana. Jest to realizowanie poprzez założenie klucza obcego na kolumnie QUESTIONER_ID z referencją do pola ID w tabeli MGR_USERS_T. Na zadane pytanie musi być możliwość udzielania odpowiedzi. Dlatego utworzona została tabela MGR_ANSWERS_T przechowująca jej treść. Posiada ona cztery klucze obce oraz pole, w którym przechowywana jest treść pytania. W kolumnie ANSWERER_ID przechowywany jest identyfikator użytkownika, który udziela odpowiedzi. To na jakie pytanie, definiowane jest poprzez identyfikator umieszczony w kolumnie QUESTION_ID. Aby posiadać informację, w ramach którego procesu dana odpowiedź została udzielona na kolumnie PROCESS_ID jest założony klucz obcy do identyfikatora instancji procesu umieszczonego na schemacie Oracle Workflow. Aplikacja ma możliwość przeprowadzenia automatycznego procesu przyznawania stypendium naukowego. Decyzja podejmowana jest na podstawie średniej ocen uzyskanych w danym semestrze. Założeniem aplikacji jest zintegrowanie się z systemem przechowującym oceny studentów. Informacje związane z osiągniętymi wynikami poprzez zdefiniowany mechanizm wymiany danych są transferowane z systemu zewnętrznego do schematu bazy danych. Miejscem w bazie danych programu, w którym przechowywane są dane z systemu jest tabela MGR_AVERAGE_T. Posiada ona klucz obcy założony na kolumnie TERM_ID, który odnosi się do klucza głównego w tabeli CRM_TERMS_T, która jest tabelą słownikową przechowująca informacje o semestrach. Tabela MGR_AVERAGE_T w polu AVERAGE przechowuje wartość średniej z danego semestru. Kolumna STUDENT_ID przechowuje identyfikator studenta, za pomocą którego można określić, który student w danym semestrze osiągnął jaką średnią. Kolejnym możliwym przypadkiem jest wystąpienie studenta o przyznanie stypendium sportowego. Do przechowywania uzasadnienia wniosku została utworzona tabela MGR_SPORT_SCHOLAR_REQ. W polu CONTENT zapisywana jest treść podania. Oprócz tej informacji zachowywana jest jeszcze data złożenia wniosku. W kolumnie REQUESTOR_ID jest przechowywany identyfikator użytkownika, który wystąpił z podaniem. Na tym polu założony jest klucz obcy powiązany z polem ID w tabeli MGR_USERS_T. Dodatkowo, aby wiedzieć w ramach której instancji procesu zostało złożone podanie, dodane zostało pole PROCESS_ID, który zawiera identyfikator danego wykonywania procesu. Równolegle do wniosku o stypendium sportowe wysyłana jest prośba o opinię na temat zawodnika. Ta informacja jest umieszczana w tabeli MGR_OPINIONS_T. Posiada ona pole CONTENT przechowujące informację o udzielonej opinii. Dodatkowo aby posiadać informację kogo zaopiniowano i w ramach jakiego procesu tabela posiada pola PROCESS_ID oraz USER_ID, które przechowują identyfikatory odpowiednich encji. 72

System sterowania przepływem pracy w środowisku Oracle Workflow Oprócz tabel zawierających dane związane bezpośrednio z definicją procesu istnieją jeszcze w aplikacji takie, które przechowują informacje pomocnicze. Pierwszą jest MGR_DICTIONARIES_T. Jest to tabela słownikowa, która może przechowywać dane, które nie są aktualnie uwzględnione podczas analizy. Dzięki tej tabeli można zdefiniować dowolną ilość słowników. Posiada ona trzy pola, w których w zależności od potrzeby można umieścić liczby, tekst lub datę. Ponadto dzięki kolumnie PARENT_ID słownik pozwala przechowywać dane w formie drzewa. Drugą tabelą pomocniczą jest MGR_OWF_INTERFACES_T. Została ona utworzona, aby przechowywać definicję interfejsów oraz ich kody. Koncepcja aplikacji zakłada, iż proces workflow w momencie osiągnięcia danej notyfikacji, poprzez wiadomość przekazuje do warstwy wyższej kod formularza, który należy aktualnie wyświetlić. Aplikacja sprawdza w tej tabeli, gdzie znajduje się interfejs o danym identyfikatorze i dołącza go na stronie internetowej. Dzięki takiemu zastosowaniu za pomocą zawartości tabeli MGR_OWF_INTERFACES_T można zarządzać treścią przypisaną do danego procesu. 7.4 Prezentacja systemu Dostęp do systemu jest możliwy poprzez przeglądarkę internetową. Główna strona programu składa się kilku komponentów. Na górze witryny znajduje się menu główne. Za jego pomocą można przechodzić do wybranych działów. Rys. 16. Strona główna aplikacji W centralnej części głównej strony umieszczona jest podręczna lista zadań do wykonania dla danego użytkownika. Aby zobaczyć pełną listę należy skorzystać z pozycji Inbox w menu głównym. Następny krok procesu pozwala studentowi wybrać cel uruchomienia procesu. Zgodnie z jego definicją z notyfikacji Cel studenta, możliwe są trzy wyjścia w tym jedno typu timeout. W na tym etapie wykonywania procesu użytkownikowi prezentowany jest interfejs pokazany na rys.17. 73

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk Rys. 17. Interfejs umożliwiający wybór stypendium lub zadanie pytania Po kliknięciu następuje przejście do odpowiedniej strony. W przypadku, gdy student zachce zadać pytanie musi wybrać opcję Pytanie, po czym instancja procesu przechodzi do następnej notyfikacji, a użytkownikowi zostaje zaprezentowany interfejs umożliwiający wprowadzanie pytania. (Rys. 18). Rys. 18. Interfejs umożliwiający zadanie pytania W czasie, gdy osoba z grupy DZIEKANAT udziela odpowiedzi student jest informowany, iż jego pytanie przeszło wstępną selekcję i powinien oczekiwać na odpowiedź. Ten interfejs jest zaprezentowany na rys. 19. W procesie jest to realizowane poprzez dwie równoległe ścieżki wykonywania. Oba te zadania muszą zostać wykonane, aby proces mógł pójść do następnego kroku. 74

System sterowania przepływem pracy w środowisku Oracle Workflow Rys. 19. Interfejs informujący o rozpatrywaniu zadanego pytania Ostatnim krokiem procesu jest poinformowanie go o tym jaka odpowiedź została udzielona na jego pytanie(rys.20). Prezentuje on pytanie, które zostało zadane oraz odpowiedź, która została udzielona. Rys. 20. Interfejs z informacją o udzielonej odpowiedzi Po zapoznaniu się z odpowiedzią i wybraniu przycisku Zakończ następuje koniec wykonywania procesu i użytkownik przechodzi na stronę główną aplikacji skąd może uruchomić następną instancję procesu. Omówiona została tylko ścieżka procesu związana z zadawaniem przez studenta pytania. Definicja procesu przewiduje także możliwość wnioskowania o stypendium sportowe i naukowe. Ich przebieg jest analogiczny do zadawania pytań. Różnią się tylko dołączonymi interfejsami. Dodatkowo proces przyznawania stypendium naukowego nie wymaga żadnej akcji ze strony użytkowników systemu, gdyż wykonywany jest automatyczne za pomocą funkcji dołączonych do definicji procesu. Student jest jedynie informowany o tym czy przyznano mu stypendium czy nie. 8 Podsumowanie. Poprzez wykorzystanie technologii języka Java oraz środowiska Oracle Workflow udało się utworzyć aplikację internetową do obsługi studentów w dziekanacie. Co ważne, jej logika 75

P.Drzymała, H. Welfle, S. Wiak, M. Kazimierczuk nie jest umieszczona w kodzie tylko opiera się na definicji procesu. W ten sposób udało się utworzyć bardzo elastyczny system, którego działanie opiera się na regułach zdefiniowanych w sposób jasny i przejrzysty. Wykorzystanie systemu ról, udostępnionych przez Oracle Workflow wyeliminowało potrzebę implementacji własnego sytemu uprawnień. Oparcie działania systemu o proces sprawiło, iż w bardzo łatwy sposób można zmieniać sposób działania aplikacji. Wystarczy tylko wprowadzić zmiany w definicji procesu. Ponadto aplikacja została zaprojektowana tak, iż tworzy framework, który można wykorzystać dla dowolnej definicji procesu. Taka konstrukcja sprawia, iż aplikacja może być stosowana wszędzie tam, gdzie przebieg czynności ma charakter procesu. Narzędzie Workflow Builder pozwala w bardzo wygodny sposób projektować nawet najbardziej skomplikowane procesy sterowania przepływem pracy. Wykorzystanie funkcji PL/SQL sprawia, iż kroki procesu są wykonywane automatycznie bez ingerencji użytkownika. Pozwala to na utworzenie systemu samodzielnie decydującego, na podstawie zebranej wiedzy, jaką ścieżkę przejścia obrać. Warstwa prezentacji aplikacji wykonana jest w formie strony internetowej. Użyto Java Server Faces technologię języka Java umożliwiającą tworzenie webowych interfejsów użytkownika. Aplikacja działa w oparciu o proces sterowania przepływem pracy, dlatego koniecznie było utworzenie funkcji Java zapewniających komunikację z Oracle Workflow. Opracowano zestaw metod, które umożliwiają zarządzanie wykonywaniem definicji procesu. Dzięki nim można z poziomu strony internetowej dokonywać operacji na serwerze workflow. Są one zapisane w postaci interfejsu. Ułatwia to ewentualną migrację programu na inne środowiska workflow. Dostępna jest implementacja interfejsu napisana specjalnie dla Oracle Workflow. Wykorzystuje ona technologię Hibernate, za pomocą której pobierane są informacje z bazy danych oraz wykonywane są procedury PL/SQL. Użycie Hibernate znacznie ułatwiło tworzenie projektu. Struktury bazy danych są automatycznie konwertowane na obiekty języka Java. Ponadto, nie trzeba już tworzyć zapytań SQL, gdyż Hibernate udostępnia funkcje, które umożliwiają wykonanie operacji bezpośrednio na obiekcie. Reguły dotyczące sposobu przełożenia zawartości obiektów na schemat bazy danych zapisane są w plikach konfiguracyjnych XML. Ponadto za pomocą Hibernate wywoływane są funkcje PL/SQL wykonujące operacje na procesie. Utworzono zestaw metod, które są w stanie w pełni obsłużyć każdy przypadek procesu. Mogą być wykorzystywane w dowolnym projekcie Java mającym działać w oparciu diagramu przepływu pracy. Wykonano w pełni funkcjonalny system, którego logika opiera się na definicji procesu workflow. Jest niezależny od użytej bazy danych oraz posiada architekturę umożliwiającą łatwą wymianę silnika procesowego. Jego budowa pozwala na proste dostosowanie go do każdej definicji procesu, czyli może znaleźć zastosowanie w wielu dziedzinach. Literatura 1. Tom Baeyens: The State of Workflow, 2004,www.jboss.com/products/jbpm/stateofworkflow. 2. Oracle Workflow Developer s Guide, Release 2.6.4. 3. Oracle Workflow API Reference, Release 2.6.4. 4. Oracle Workflow User's Guide, Release 2.6.4. 5. Matthew Searle: Developing with Oracle Workflow, O'Reilly Media 2006. 6. Kito D. Mann: Java Server Faces in Action, Manning 2005. 7. Christian Bauer, Gavin King: Hiberante in Action, Manning 2005. 8. Dave Minter, Jeff Linwood: Hibernate of Nowicjusza do Profesjonalisty, Power Net 2007. 76