JBoss jBPM!?
Słowem wprowadzenia jBPM (Business Process Management) jest platformą przeznaczoną do modelowania procesów biznesowych .Wprowadzenie.
Na jBPM składają się:
- jPDL-grafowy język programowania oparty o xml,
- GPD - graficzny edytor (wtyczka do Eclipse), który pozwala na szybkie i w miarę intuicyjne utworzenie modelu procesu w języku jPDL,
- PVM - Proces Virtual Machine za pomocą którego jPDL ożywa.
Siłą jBPM jest właśnie jPDL który łączy pracę analityka i programisty w jednym pliku. Analityk najpierw modeluje proces (np. sprzedaż produktu) wyszczególniając na grafie kierunkowym wszystkie istotne kroki danego procesu. Etap ten jest podobny do modelowania diagramu przepływu lub przypadków użycia znanych z UML czyli przyjazny dla analityka. Następnie programista po otrzymaniu takiego pliku zaczyna podpinać do poszczególnych węzłów grafu różne akcje i zadania (np. wywołanie zdalnego systemu, zapis do bazy danych). Użyłem słowa podpinać gdyż programista przy pomocy GPD wskazuje po prostu klasy które mają być użyte do obsługi. Kolejną miłą właściwością jBMP jest persystencja oparta o Hibernate co pozwala na umieszczenie tabel jBPM’a zarówno obok tabel naszej aplikacji jak i w całkowicie oddzielnej bazie danych. W bazie danych zapisywane są definicje procesów, instancje procesów oraz dane zgromadzone w zadaniach (task).
Jak to się robi.
Początek jest banalnie prosty wpisujemy http://www.jboss.org/jbossjbpm/ pojawia nam się strona z wielkim przyciskiem DOWNLOAD i idąc tym tropem ściągamy sobie jPDL Suite. Tak zdobytą paczkę rozpakować należy w dowolnym miejscu i przejść do katalogu “designer” z tego miejsca odpalamy anta który zainstaluje nam eclipse. Można też po prostu ściągnąć sobie eclipse i rozpakować go do katalogu ./designer/eclipse.
Po uruchomieniu eclipse tworzymy nowy projekt JBoss jBPM/Process Project. Dajemy mu nazwę i klikamy ‘Finish’. Naszym oczom ukazuje się przykładowy projekt wraz z jednym handlerem i JUnit testem. Najważniejszą częścią tego przykładu jest plik procesdefinition.xml który zawiera graf kierunkowy determinujący przebieg procesu, jest napisany w języku jPDL.
Bloki procesu (grafu) dzielą się na kilka grup. Dokładny opis wszystkich bloków był by bardzo obszerny więc przedstawię tylko podstawowe.
States służą do określenia kolejnych kroków procesu istotnych z punktu biznesowego i wykonywanych automatycznie(bez ingerencji użytkownika) np. odpytanie o dane jakiegoś zewnętrznego systemu.
Nodes są podobne do States jednak są wyposażone w pole odpowiadające za wykonanie konkretnej akcji.
Tasks Node jest specyficznym stanem gdyż jest przeznaczony do umieszczania w nim zadań do wykonania dla człowieka. Proces przechodzi dalej w chwili zakończenia zadania przez człowieka np. następnego dnia. W czasie obsługi danego zadania w dowolnym momencie można zapisać jego aktualny stan.
Fork i Join służące do rozdzielenia procesu na kilka równolegle wykonywanych ścieżek. Istotną rzeczą jest że fork i join zawsze pracują w parach i wszystkie ścieżki wychodzące z jednego forka muszą skończyć się w jednym joinie. Proces oczekuje na bloku Join do zakończenia wszystkich ścieżek.
Transition jest to połączenie pomiędzy blokami procesu określające kierunek przejścia. Z bloku może wyjść dowolna liczba połączeń. Jeśli podczas wyjścia z bloku nie jest podana nazwa połączenia proces przechodzi po pierwszym (kolejność w xml).
Każdy blok ma możliwość podpięcia klasy obsługującej wyjątki, oraz dowolną liczbę klas obsługujących akcje, wykonywanych gdy nastąpi zdarzenie do których są przyporządkowane(np. node enter, node leave). Akcje mogą być również przyporządkowane do Transitions.
Na powyższym rysunku widać prosty przykładowy proces. Widok źródła wygląda następująco:
<?xml version="1.0" encoding="UTF-8"?> <process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="simple"> <start-state name="start"> <transition name="to_state" to="first"> <action name="action" class="com.sample.action.MessageActionHandler"> <message>Going to the first state!</message> </action> </transition> </start-state> <state name="first"> <transition name="to_end" to="end"> <action name="action" class="com.sample.action.MessageActionHandler"> <message>About to finish!</message> </action> </transition> </state> <end-state name="end"></end-state> </process-definition>
public class MessageActionHandler implements ActionHandler {
String message;
public void execute(ExecutionContext context) throws Exception {
context.getContextInstance().setVariable("message", message);
}
}
Jak widać w powyższym kodzie pole message nie posiada metod get i set jego wartość jest bezpośrednio wstrzykiwana z definicji procesu. Interfejs ActionHandlera posiada tylko jedną metodę do której jako parametr przychodzi ExecutionContext zawierający definicję procesu i jego instancje(wszystkie).
W momencie wykonania kompletnej implementacji wszystkich zdarzeń oraz podpięciu interfejsu użytkownika, mieli byśmy piękną trzy etapową obsługę czegoś. Gdyby była to aplikacja wykonana tradycyjnie każda zmiana wymagała by w mniejszym lub większym stopniu dostosowania istniejących elementów. Lecz gdy mamy do czynienia z grafem możemy po postu w dowolnym miejscu dodać kolejny element. Jak widać na rysunku poniżej.
Wbrew pozorom takie rozszerzanie aplikacji zdarza się dość często szczególnie jak mamy do czynienia z procesami decyzyjnymi oraz organizacją pracy w rozwijających się przedsiębiorstwach.
Podsumowanie.
JBPM to platforma do modelowania procesów biznesowych oparta o grafowy język jPDL. Nadaje się świetnie do tworzenia systemów które mają na celu przydzielać zadania do wykonania dla poszczególnych osób w złożonym środowisku procedur i przepisów.










March 12th, 2009 at 09:43
Witam,
całkiem dobrze, gdyby nie literówka poszczegulnych -> poszczególnych. Wiem, czepiam się, no ale.
Pozdrawiam
Dawid