Zaprojektowanie i wykonanie prototypowego systemu obiegu dokumentów (workflow) dla Dziekanatu Wydziału z wykorzystaniem narzędzi open-source i cloud computing. Jarosław Tadeusz Grabowski Maciej Zasada opiekun pracy prof. dr hab. inż. Mieczysław Muraszkiewicz Wydział Elektroniki i Technik Informacyjnych Politechnika Warszawska

Podział prezentacji Część 1. Część 2. Wprowadzenie do dziedziny problemu Cel pracy i model procesu Część 2. Opis badań i opis systemu Podsumowanie i kierunki rozwoju

Agenda 1. części prezentacji Wprowadzenie Systemy obiegu dokumentów Procesy biznesowe Chmury obliczeniowa Cel pracy Model procesu

Wprowadzenie Systemy obiegu dokumentów Źródło: Opracowanie własne

Wprowadzenie Procesy biznesowe Sekwencje operacji, które przedsiębiorstwo wykonuje w celu osiągnięcia ustalonego celu. Mnogość notacji opisu procedur BPMN; WS-BPEL; jPDL. Pozwalają na interakcję z użytkownikiem poprzez „zadania”. Uruchamiane w ramach silników procesów biznesowych.

Wprowadzenie Przykładowy proces biznesowy Źródło: Marcin Sałaciński, „Modelowanie procesów biznesowych”

Wprowadzenie Modele dystrybucji chmury obliczeniowej Źródło: Agnieszka Serafinowicz, „Nie błądzić w chmurach”.

Wprowadzenie Najczęściej wybierane formy aplikacji dystrybuowanych w modelu SaaS: Narzędzia do zarządzanie treścią; Systemy komunikacji i pracy grupowej. „(…) trendu pozbywania się własnego IT i pudełkowego oprogramowania w firmach nic już nie powstrzyma. Nawet Microsoft, całe lata zarabiający na klasycznym paradygmacie software-on-premise, coraz bardziej zachęca do swoich narzędzi online jak Office365.”

Cel pracy Wykonanie projektu i realizacja prototypu systemu obiegu umów cywilno – prawnych, zawieranych w Instytucie Informatyki na Wydziale Elektroniki i Technik Informacyjnych. Umożliwienie integracji zewnętrznych aplikacji z tworzonym systemem. Wykorzystanie technologii opartych na darmowych licencjach. System możliwy do dystrybucji w modelu SaaS chmury obliczeniowej. Porównanie funkcjonalne i wydajnościowe silników procesów biznesowych.

Przyjęte założenia – model procesu Źródło: Opracowanie własne

Przyjęte założenia – model procesu Główne elementy wymodelowanego procesu: <task> <task assignee="#{applicantUser}" name="Wydruk umowy."> <transition to="Początek procedury wypełniania oświadczeń."/> </task> <foreach> i <join> <foreach in="#{contractors}" name="Początek procedury wypełniania oświadczeń." var="contractor"> <transition name="Zleć wypełnienie oświadczeń." to="Wypełnienie oświadczenia do celów podatkowych i ZUS."/> </foreach> … <join name="Koniec procedury wypełniania oświadczeń."> <transition to="Wydruk umowy i oświadczeń."/> </join> <decision> <decision name="Czy jest wymagany protokół odbioru?"> <transition to="Wypełnienie protokołu odbioru."> <condition expr="#{isCollectionProtocolRequired}"/> </transition> <transition to="Początek procedury wystawienia rachunku."/> </decision>

Agenda 2. części prezentacji Wybór silnika procesów Testy funkcjonalne Testy wydajnościowe Architektura systemu Odpowiedzialności komponentów Kierunki rozwoju Podsumowanie

Wybór silnika procesów Pięć produktów open-source – OpenESB, jBPM, ODE, Orchestra, Drools Flow Komercyjne rozwiązanie referencyjne – Microsoft BizTalk Testy funkcjonalne i wydajnościowe Jak i dlaczego silnik procesów biznesowych został wykorzystany w projektowanej aplikacji. Jak przenosi się sformalizowane obiegi dokumentów w realia procesów biznesowych / zadań użytkowników. Jak dobrano 5 testowanych produktów i rozwiązanie referencyjne. Co obejmują (ogólnie) testy funkcjonalne i wydajnościowe.

Wybór silnika – testy funkcjonalne Porównanie oferowanego wsparcia w fazach wytwarzania oprogramowania, m.in. wspierane notacje, zdolność integracji, wdrożenie silnika i definicji procesów Zdecydowana przewaga rozwiązania referencyjnego. Jak podzielono test na kategorie. Co porównywano w ramach poszczególnych kategorii. Jak duża jest przepaść pomiędzy rozwiązaniem referencyjnym, a produktami open-source.

Wybór silnika – testy wydajnościowe Jakie testy zostały przeprowadzone. W jakich warunkach/środowiskach, jakie ustalono parametry testów. Jak badano rezultaty. Jak zagregowano wyniki widoczne na wykresie. Źródło: Opracowanie własne

Architektura rozwiązania Opis dekompozycji i komunikacji. Motywacja podjętych decyzji. Na nastepnych slajdach szczegółowo o odpowiedzialnościach. Źródło: Opracowanie własne

FluiCore Rdzeń systemu niezależny od specyfiki realizowanego obiegu Odpowiedzialności: zarządzanie procesami biznesowymi zarządzanie zadaniami użytkowników zarządzanie użytkownikami generacja plików dokumentów

FluiDoc Komponent skupia wszystkie funkcjonalności specyficzne dla realizowanego projektu Odpowiedzialności: realizacja kroków obiegu dokumentów zarządzanie danymi umów świadczenie usług repozytorium wygenerowanych umów

FluiUi Bogata aplikacja internetowa (RIA) Interfejs zbudowany z wykorzystaniem GWT i biblioteki SmartGWT Dwuwarstwowa architektura Komunikacja z FluiCore i FluiDoc oparta na usługach sieciowych Część serwerowa udostępnia usługi REST

Kierunki rozwoju Adaptacja podpisów cyfrowych Integracja z istniejącymi repozytoriami dokumentów Całkowita automatyzacja kroków obiegu Wykorzystanie generycznego silnika w innych procesach

Podsumowanie Aplikacja zbudowana na bogatej, wydajnej platformie jBPM Oparta o model chmury SaaS Wykorzystująca generyczny, udostępniający niezależny od platformy interfejs, silnik obiegu dokumentów

Dziękujemy za uwagę.