220 likes | 367 Views
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
E N D
Zaprojektowanie i wykonanie prototypowego systemu obiegu dokumentów (workflow) dla Dziekanatu Wydziału z wykorzystaniem narzędzi open-source i cloudcomputing. 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. • 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> <taskassignee="#{applicantUser}"name="Wydruk umowy."> <transitionto="Początek procedury wypełniania oświadczeń."/> </task> • <foreach> i <join> <foreachin="#{contractors}"name="Początek procedury wypełniania oświadczeń."var="contractor"> <transitionname="Zleć wypełnienie oświadczeń."to="Wypełnienie oświadczenia do celów podatkowych i ZUS."/> </foreach> … <joinname="Koniec procedury wypełniania oświadczeń."> <transitionto="Wydruk umowy i oświadczeń."/> </join> • <decision> <decisionname="Czy jest wymagany protokół odbioru?"> <transitionto="Wypełnienie protokołu odbioru."> <conditionexpr="#{isCollectionProtocolRequired}"/> </transition> <transitionto="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, DroolsFlow • Komercyjne rozwiązanie referencyjne – Microsoft BizTalk • 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.
Wybór silnika – testy wydajnościowe Źródło: Opracowanie własne
Architektura rozwiązania Ź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