docZdarzenia pośrednie
download 
Reklamacja Transkrypt
Zdarzenia pośrednie
Modelowanie procesów biznesowych – BPMN cz. II Plan wykładu • • • • Łączenie przepływów Powtarzanie czynności Zdarzenia pośrednie Podprocesy 2 Literatura* • http://www.omg.org/spec/BPMN/2.0/ – witryna organizacji odpowiedzialnej m.in. za aktualną wersję BPMN • Bruce Silver: BPMN Method and Style • Thomas Allwayer: BPMN 2.0 • Stephen A. White, Derek Miers: BPMN Modeling and Reference Guide • Szymon Drejewicz: Zrozumieć BPMN *w prezentacji wykorzystano przykłady z wyżej wymienionych pozycji 3 • • • • Łączenie przepływów Powtarzanie czynności Zdarzenia pośrednie Podprocesy 4 Koncepcja żetonu – tokena • Żeton jest abstrakcyjną elementem służącym do opisania zachowania procesu • Żeton „krąży” zgodnie z przepływem sekwencji w procesie i „przechodzi” przez elementy modelu • Początek procesu biznesowego generuje żeton, koniec procesu oznacza jego usunięcie • Żetony mogą być kreowane, usuwane, rozszczepiane oraz scalane 5 Bramki łączące (1) • Każdy żeton docierający do bramki XOR jest natychmiastowo i bezwarunkowo przekazywany dalej. Jeśli zdarzy się, że do bramki dotrze dwa lub więcej żetonów, wówczas wszystkie są przekazywane dalej, powodując często wielokrotne uruchomienie czynności występujących po bramce • Bramka równoległa oczekuje aż dotrą do niej żetony z wszystkich dochodzących gałęzi. Po dotarciu wszystkich żetonów są one łączone w jeden i ten żeton jest przekazywany dalej 6 Bramki łączące (2) • Bramka OR po dotarciu pierwszego żetonu sprawdza, czy w dochodzących gałęziach są jakieś inne żetony. Jeśli są, wówczas czeka na kolejny żeton i po jego nadejściu sprawdza ponownie. Jeśli żetonów w dochodzących gałęziach już nie ma, wówczas wszystkie żetony które dotarły są łączone w jeden i ten nowy żeton jest przekazywany dalej • Bramka złożona po dotarciu żetonu sprawdza warunek. Jeśli warunek nie jest spełniony, nic się nie dzieje. Jeśli warunek okaże się prawdziwy, wówczas żeton jest natychmiast przekazywany dalej, a bramka czeka nadal. Od tego momentu wszystkie żetony, które dotrą do bramki są usuwane. 7 Łączenie przepływów alternatywnych (1) • Klasyczne połączenie przebiegów alternatywnych przy pomocy bramki XOR (zalecane) • Połączenie przebiegów alternatywnych przy pomocy bramki równoległej spowoduje zatrzymanie procesu 8 Łączenie przepływów alternatywnych (2) • Połączenie przebiegów alternatywnych jest możliwe przy pomocy bramki OR (niezalecane ) • Połączenie przebiegów alternatywnych jest również możliwe przy pomocy bramki złożonej po odpowiednim sformułowaniu warunku (niezalecane ) 9 Łączenie przepływów równoległych – bramka równoległa Oczekiwanie aż obydwa zadania zostaną ukończone Rozwidlenie na dwa równoległe przepływy Zadanie wykona się jeden raz po ukończeniu wszystkich poprzednich zadań 10 Łączenie przepływów równoległych – bramka OR Oczekiwanie aż wszystkie rozpoczęte zadania zostaną ukończone (w tym przypadku bramka OR zachowa się identycznie jak bramka równoległa) Rozwidlenie na dwa równoległe przepływy Zadanie wykona się jeden raz po ukończeniu wszystkich poprzednich zadań 11 Łączenie przepływów równoległych – bramka XOR Po zakończeniu każdego z zadań wyszukiwania natychmiast uruchomione zostanie zadanie weryfikacji Rozwidlenie na dwa równoległe przepływy Zadanie weryfikacji wykona się dwa razy: po zakończeniu zadania wyszukiwania w Internecie oraz po zakończeniu zadania wyszukiwania w bibliotece 12 Łączenie przepływów równoległych – bramka Złożona Bramka będzie oczekiwać na zakończenie jednego z zadań wyszukiwania. Po zakończeniu jednego z tych zadań natychmiast uruchomione zostanie zadanie weryfikacji. Rozwidlenie na dwa równoległe przepływy Zakończenie drugiego z zadań wyszukiwania pozostanie bez wpływu na zachowanie procesu. Zadanie wykona się jeden raz po ukończeniu pierwszego z zadań wyszukiwania 13 • • • • Łączenie przepływów Powtarzanie czynności Zdarzenia pośrednie Podprocesy 14 Powtarzanie czynności (1) • Powtarzanie czynności (pętle) można zrealizować w oparciu o bramki XOR i odpowiednie warunki • Warunek prawdziwy oznacza powtarzanie czynności • Warunek fałszywy oznacza zaprzestanie powtarzania i przejście dalej • Warunek może być sprawdzany na początku lub na końcu 15 Powtarzanie czynności (2) • Zadania oraz podprocesy mogą być powtarzane • Liczba powtórzeń nie jest z góry ustalona – Do-While – warunek pętli sprawdzany jest po wykonaniu czynności; pętla przestaje się wykonywać, gdy warunek stanie się fałszywy – While-Do – warunek pętli jest sprawdzany przed wykonaniem czynności; pętla przestaje się wykonywać, gdy warunek stanie się fałszywy • Istnieje możliwość zdefiniowania maksymalnej liczby iteracji. Przekroczenie tej liczby oznacza zakończenie pętli niezależnie od wartości logicznej warunku pętli 16 Czynności wielo-instancyjne • Wiele instancji tej samej czynności jest uruchamiane sekwencyjnie lub równolegle • Czynności wielo-instancyjne operują na kolekcji (liście) danych, np. dla każdej pozycji zamówienia dokonaj sprawdzenia dostępności towaru • Liczba instancji czynności wielo-instancyjnej jest stała; ustalana jest przed rozpoczęciem wykonywania • Realizacji czynności wielo-instancyjnej odpowiada programistycznej konstrukcji For-Each 17 Szeregowe czynności wieloinstancyjne • Szeregowa czynność wielo-instancyjna polega na sekwencyjnym uruchamianiu kolejnych instancji czynności • Szeregowa czynność wielo-instancyjna może być zastąpiona sekwencją identycznych czynności, pod warunkiem jednak, że liczba instancji czynności jest znana na etapie projektowania • Czynności wielo-instancyjna szeregowa vs. pętla (w pętli liczba iteracji nie jest ustalona, w czynności wieloinstancyjnej szeregowej liczba iteracji jest ustalona przed rozpoczęciem) = 18 Równoległe czynności wielo-instancyjne • Równoległa czynność wielo-instancyjna polega na uruchamianiu jednocześnie wszystkich instancji czynności • Równoległa czynność wielo-instancyjna może być zastąpiona bramką równoległą, pod warunkiem jednak, że liczba instancji czynności jest znana w momencie projektowania = 19 Pozostałe elementy wieloinstancyjne • Pula wieloinstancyjna oznacza, że może istnieć wiele jednostek wykonujących identyczny proces, np. Petent(wielo-instancyjny uczestnik), Urząd (uczestnik jedno-instancyjny) • Wielo-instancyjny obiekt danych oznacza kolekcję / listę obiektów tego samego rodzaju, np. Zamówienie jest kolekcją pozycji zamówienia 20 Przykład (1) • Proces zaopatrywania sieci hurtowni samochodowych w części od różnych producentów • Proces składa się z następujących czynności: – Zebranie zapotrzebowania na części ze wszystkich oddziałów hurtowni – Przekazanie zamówień do poszczególnych producentów – Dostawa części do wszystkich oddziałów hurtowni przy wykorzystaniu floty samochodów dostawczych 21 Przykład (2) Dopóki nie zostaną zebrane zamówienia ze wszystkich hurtowni Niezależnie dla każdego kierowcy zaopatrzeniowego oddzielnie Kolejno dla każdego producenta części oddzielnie 22 • • • • Łączenie przepływów Powtarzanie czynności Zdarzenia pośrednie Podprocesy 23 Zdarzenia w BPMN 2.0 24 Zdarzenia pośrednie • Zdarzenie pośrednie oznacza, że coś wydarzyło się po starcie procesu i przed jego zakończeniem • Zdarzenia pośrednie mogą być typu wychwytującego (catch) oraz wysyłającego (throw) • Zdarzenia pośrednie mają jeden wejściowy oraz jeden wyjściowy przepływ sekwencji 25 Wzorzec kamienia milowego Kiedy koncepcja książki jest gotowa, wysyłany jest sygnał Dwa podprocesy rozpoczynają działanie (równolegle) Sygnały pełnią role kamieni milowych – informują otoczenie, że pewien etap właśnie się zakończył Oczekuje na sygnał oznaczający, że koncepcja książki jest gotowa. Kiedy sygnał dotrze uruchamiane jest zadanie przygotowania projektu oprawy 26 Kamień milowy – a dlaczego nie tak? • Usunięcie podprocesów wyraźnie upraszcza model (możliwe jest np. użycie przepływów sekwencji) • Usuniecie podprocesów nie zawsze jest jednak możliwe, bo podprocesy mogą być używane w innych miejscach lub też do podprocesów mogą być przypięte pewne zdarzenia • Zastosowanie sygnałów w tym konkretnym przypadku skutkuje większą złożonością modelu, ale oznacza też słabsze powiązanie pomiędzy niektórymi czynnościami (loosely coupling) 27 Zdarzenia pośrednie krawędziowe (1) • Zdarzenia krawędziowe są rodzajem zdarzeń pośrednich • Nazwę zawdzięczają temu, że są przypięte (do krawędzi) czynności • Wszystkie zdarzenia krawędziowe są typu wychwytującego (catch) • Po uruchomieniu czynności do której przypięte jest zdarzenie krawędziowe następuje oczekiwanie na to zdarzenie 28 Zdarzenia pośrednie krawędziowe (2) • Zdarzenia krawędziowe muszą mieć określony typ, tj. nie można użyć zdarzenia nieokreślonego • Zdarzenia krawędziowe służą przede wszystkim do obsługi sytuacji wyjątkowych • Z czynności posiadającej zdarzenie krawędziowe wychodzą co najmniej dwa przepływy: przepływ normalny oraz przepływ wyjątku 29 Zdarzenia krawędziowe przerywające • Jeśli do zakończenia czynności nie nadejdzie zdarzenie, wówczas proces kontynuuje działanie po ścieżce normalnej • Jeśli przed zakończeniem czynności pojawi się zdarzenie krawędziowe, wówczas przerywana jest czynność oraz następuje przejście do ścieżki wyjątku 30 Zdarzenie krawędziowe nieprzerywające • Jeśli do zakończenia czynności nie nadejdzie zdarzenie, wówczas proces kontynuuje działanie po ścieżce normalnej • Jeśli przed zakończeniem czynności pojawi się zdarzenie, wówczas tworzona jest równoległa ścieżka wyjątku (czynność jest nadal wykonywana) 31 Zdarzenia krawędziowe przerywające – przykład Jeśli w trakcie przetwarzania zamówienia nie zostanie odebrany komunikat anulowania zamówienia, wówczas proces przejdzie do dostawy zamówienia Jeśli w trakcie przetwarzania zamówienia zostanie odebrany komunikat anulowania zamówienia, wówczas przerwana zostanie czynność przetwarzania zamówienia i proces przejdzie do zdarzenia końcowego 32 Zdarzenie krawędziowe nieprzerywające – przykład Jeśli w trakcie przetwarzania zamówienia nie zostanie odebrany komunikat aktualizacji zamówienia, wówczas proces przejdzie do dostawy zamówienia Jeśli w trakcie przetwarzania zamówienia zostanie odebrany komunikat aktualizacji zamówienia, wówczas uruchomiona zostanie dodatkowa (równoległa) ścieżka procesu prowadząca do czynności „Aktualizuj zamówienie”. Czynność „Przetwarzaj zamówienie” będzie nadal wykonywana, a po jej zakończeniu proces przejdzie do czynności „Dostawa zamówienia” 33 Wiele zdarzeń krawędziowych Do czynność można przypisać wiele zdarzeń krawędziowych Jeśli zdarzenia te są obsługiwane identycznie, wówczas można wykorzystać tzw. wielozdarzenia 34 Nasłuchiwanie vs. oczekiwanie • Czynność zaczyna być wykonywana, jednocześnie prowadzony jest nasłuch na określone zdarzenie • Proces przejdzie dalej po zakończeniu czynności (jedną lub obydwiema ścieżkami) Proces zatrzymuje się i czeka na określone zdarzenie Proces przejdzie dalej tylko wtedy, gdy określone zdarzenie nadejdzie 35 Zgłaszanie błędu • BPMN umożliwia zgłaszanie błędu przy pomocy zdarzenia końcowego Błąd Zdarzenie końcowe Błąd oznacza sytuację, kiedy dana ścieżka procesu kończy się błędem Zdarzenie błąd może być zgłaszane explicite (w definicji procesu) lub implicite przez systemy informatyczne Rodzaje błędów: Techniczne (np. automat nie może odczytać karty, usługa sieciowa niedostępna) Biznesowe (np. brak środków na koncie, odrzucenie podania) 36 Zachowanie procesu po zgłoszeniu błędu Zdarzenie końcowe Błąd powoduje zakończenie wszystkich aktywnych ścieżek bieżącego procesu oraz wszystkich jego podprocesów, nie kończy jednak procesu nadrzędnego Zdarzenie końcowe błąd przekazuje rezultat błędu do procesu nadrzędnego (przekazywanie błędów może odbywać się tylko w ramach tej samej puli) 37 Obsługa błędów • Możliwości przechwytywania i obsługi błędów: – zdarzenie krawędziowe – podprocesy zdarzeniowe • Przechwytywane są tylko te zgłoszenia błędów, które mają taką samą nawę jak zdarzenie zgłaszające • Jeśli zdarzenie przechwytujące nie posiada nazwy, wówczas przechwytywane są wszystkie zgłoszenia błędów • Zgłoszenia błędów mogą przemieszczać się tylko w górę w hierarchii procesów 38 Mechanizm throw-catch dla błędów Proces znajdzie się na ścieżce normalnej tylko wtedy, gdy w trakcie wykonywania podprocesu nie zostanie zgłoszony żaden błąd Zdarzenie końcowe błąd służy do zgłoszenia błędu Każdy błąd zgłoszony w okresie aktywności podprocesu „Weryfikacji zdolności kredytowej” jest przechwytywany przez zdarzenie krawędziowe Proces znajdzie się na ścieżce wyjątku tylko wtedy, gdy w trakcie wykonywania podprocesu zostanie zgłoszony błąd 39 Eskalacja • Procedurę eskalację można interpretować jako konieczność wykonania pewnych dodatkowych działań, najczęściej bez naruszania bieżącej ścieżki procesu • BPMN dopuszcza dwa sposoby na zgłoszenie potrzeby eskalacji: zdarzenie końcowe oraz zdarzenie pośrednie Zgłoszenie eskalacji nie oznacza zakończenia procesu Zdarzenia zgłaszające eskalację przekazują rezultat eskalacji do procesu nadrzędnego (przekazywanie rezultatu eskalacji może odbywać się tylko w ramach tej samej puli) 40 Obsługa eskalacji • Możliwości przechwytywania i obsługi eskalacji: – zdarzenie krawędziowe (przerywające i nieprzerywające) – podprocesy zdarzeniowe (przerywające i nieprzerywające) • Przechwytywane są tylko te zgłoszenia eskalacji, które mają taką sama nawę jak zdarzenie zgłaszające • Jeśli zdarzenie przechwytujące nie posiada nazwy, wówczas przechwytywane są wszystkie zgłoszenia eskalacji • Zgłoszenia eskalacji mogą przemieszczać się tylko w górę w hierarchii procesów 41 Mechanizm throw-catch dla eskalacji Zdarzenie końcowe eskalacji służy do zgłoszenia potrzeby eskalacji Proces znajdzie się na ścieżce normalnej zawsze po skończeniu wykonywania podprocesu „Przyjęcie zamówienia” Każde zgłoszenie eskalacji w okresie aktywności podprocesu „Przyjęcie zamówienia” jest przechwytywane przez zdarzenie krawędziowe Ścieżka prowadząca do aktualizacji danych zostanie uaktywniona jako równoległa do ścieżki normalnej wówczas, gdy odebrane zostanie zgłoszenie eskalacji 42 Eskalacja vs. Błąd Eskalacja Błąd • Eskalacja służy do wykonania pewnych dodatkowych działań, najczęściej bez naruszania bieżącej ścieżki procesu • Błędy służą do poinformowania, że proces nie zachowuje się zgodnie z oczekiwaniami • Zgłoszenie eskalacji nie kończy bieżącego procesu • Zgłoszenie błędu kończy bieżący proces • Istnieją dwa zdarzenia zgłaszające potrzebę eskalacji: zdarzenia pośrednie i końcowe • Istnieje jedno zdarzenie zgłaszające błąd: zdarzenie końcowe • Procedura obsługi eskalacji może być wykonywana równolegle do czynności w której nastąpiło zgłoszenie • Procedura obsługi błędu przerywa wykonywanie czynności, w której nastąpiło zgłoszenie błędu 43 • • • • Łączenie przepływów Powtarzanie czynności Zdarzenia pośrednie Podprocesy 44 Rodzaje czynności • Zadanie Czynność atomowa • Podproces Czynności nie atomowe • Czynność wywołania Reprezentuje wywołanie innej czynności 45 Podprocesy • Podproces to rodzaj czynności na którą składają się inne czynności, bramki, zdarzenia oraz przepływy • Podproces określa zakres / zasięg widoczności atrybutów, transakcji, obsługi wyjątków kompensacji • Istnieją 4 rodzaje podprocesów: 46 Podproces osadzony • Podproces osadzony to rodzaj czynności, która została rozłożona na „mniejsze” czynności, bramki, zdarzenia i przepływy Podprocesy osadzony funkcjonuje tylko w kontekście procesu nadrzędnego Jeśli podproces posiada zdarzenia początkowe, to musi to być zdarzenie niekreślonego typu Podproces osadzony jest uruchamiany poprzez przepływ sekwencji Podproces osadzony posiada bezpośredni dostęp do danych procesu nadrzędnego (bo jest częścią procesu nadrzędnego) 47 Podprocesy zwinięte i rozwinięte Podproces osadzony w formie zwiniętej Podproces osadzony w formie rozwiniętej 48 Podprocesy Ad-Hoc Grupa czynności realizowanych bez narzuconej kolejności Czynności mogą być wykonywane Sekwencyjnie – w danym momencie może być wykonywana tylko jedna czynność (ordering=parallel) Równolegle – w danym momencie może być wykonywane kilka czynności (ordering=sequential) Każda czynność może być wykonywana wielokrotnie 49 Rozpoczynanie i kończenie podprocesu Ad-Hoc O sposobie rozpoczęcia procesu decydują wykonawcy poszczególnych zadań Do zakończenia procesu Ad-Hoc nie jest wymagane zakończenie wszystkich czynności Zakończenie procesu jest uzależnione od pewnych warunków (CompletionCondition) Parametr cancelRemainingInstances określa, co należy zrobić z instancjami zadań po spełnieniu warunku zakończenia (wartość true w trybie parallel anuluje wszystkie czynności w trakcie wykonywania ) 50 Przykład podprocesu AdHoc 51 Szczególne przypadki podprocesu Ad-hoc • W podprocesie Ad-Hoc mogą pojawić się czynności połączone w sekwencję. W takim przypadku czynności te muszą być wykonane sekwencyjne • Może się zdarzyć sytuacja, że nie jest możliwe zdefiniowanie kolejności wykonania czynności, ale jest możliwość zdefiniowania przepływu obiektów/dokumentów. Wówczas na diagramie należy ten przepływ dokumentów zaznaczyć 52 Podprocesy zdarzeniowe • Podproces zdarzeniowy może być utworzony wewnątrz podprocesu • Jego zadanie polega na nasłuchiwaniu określonych zdarzeń Nasłuchiwanie rozpoczyna się w momencie rozpoczęcia podprocesu i kończy się w chwili jego zakończenia Jest rodzajem wbudowanej (inline) procedury obsługi zdarzeń Wykonuje się w kontekście podprocesu w ramach którego jest zdefiniowany Jest uruchamiany zdarzeniem a nie przepływem sekwencji Może być uruchomiony wielokrotnie, może też w ogóle nie zostać uruchomiony 53 Przerywający podproces zdarzeniowy Przejście do przygotowywania listy kandydatów nastąpi, gdy do 7 dni uda się znaleźć kandydata wewnątrz firmy. Jeśli się nie uda, wówczas zakończy się dopiero po ukończeniu poszukiwań przez agencję (podproces zdarzeniowy) Po rozpoczęciu podprocesu „Poszukiwanie kandydata do pracy” uruchamiane jest poszukiwanie kandydata wewnątrz firmy oraz mierzony jest czas Jeśli po upływie 7 dni poszukiwanie wewnętrzne nie zostało zakończone, wówczas jest przerywane i rozpoczyna się poszukiwania przez agencję (podproces zdarzeniowy ) 54 Nieprzerywający podproces zdarzeniowy Przejście do dostawy zamówienia nastąpi wtedy, gdy zakończy się kompletowanie zamówienia i podproces zdarzeniowy aktualizacji zamówienia, (jeśli został uruchomiony), Jeśli podproces zdarzeniowy nie został uruchomiony, wówczas przejście do dostawy zamówienia nastąpi zaraz po zakończeniu kompletowania Po rozpoczęciu podprocesu przetwarzania zamówienie podproces zdarzeniowy rozpoczyna nasłuch. Interesuje go zdarzenie „Aktualizuj zamówienie”, które może przysłać np. klient 55 W chwili gdy zdarzenie „Aktualizuj zamówienie” nadejdzie rozpoczyna się podproces zdarzeniowy aktualizacji zamówienia. Podproces „Przetwarzaj zamówienie nadal jest jednak wykonywany Podproces Zdarzeniowy vs. Podproces osadzony Podproces zdarzeniowy Podproces osadzony Jest wykonywany poza normalnym przepływem Jest wykonywany w ramach normalnego przepływu Rozpoczyna się zdarzeniem początkowym konkretnego typu Rozpoczyna się zdarzeniem początkowym bez ustalonego typu Nie może posiadać wejściowych i Posiada wejściowe i wyjściowe wyjściowych przepływów sekwencji przepływy sekwencji 56 Podproces zdarzeniowy vs. Zdarzenia krawędziowe Podproces zdarzeniowy Zdarzenia krawędziowe Może być zdefiniowany tylko wewnątrz podprocesu Może być zdefiniowane dla podprocesu i zadań Jest traktowany jako wbudowana (inline) procedura obsługi zdarzenia Jest traktowany jako zewnętrzna procedura obsługi zdarzenia Ma dostęp do danych podprocesu Wszelkie dane wymagane przez wewnątrz którego jest zdefiniowany obsługę zdarzenia muszą być przekazywane Po zakończenie działania proces kontynuuje ścieżkę normalną Po zakończeniu działania proces może kontynuować ścieżkę normalną albo ścieżkę wyjątku albo też obydwie te ścieżki 57 Procesy i zadania globalne • W BPMN można definiować procesy i zadania, które mogą być wielokrotnie używane • Procesy wielokrotnie używane noszą nazwę procesów globalnych • Zadanie wielokrotnie używane noszą nazwę zadań globalnych • Dopuszcza się 4 rodzaje zadań globalnych: manualne, użytkownika, skryptowe, reguły biznesowej 58 Czynność wywołania • Do wywoływania procesów i zadań globalnych służą tzw. czynności wywołania Wywoływany proces nie posiada dostępu do danych procesu wywołującego Czynność wywołania musi zadbać by do wywołanego procesu trafiły wszystkie niezbędne dane Czynność wywołania musi też odebrać wyniki z procesu wywoływanego 59 Transakcje w systemach IT • Transakcja – zbiór operacji, które stanowią pewna całość i powinny być wykonane wszystkie lub żadna z nich • ACID – własności transakcji gwarantujące poprawne jej przetwarzanie – – – – Atomicity – wszystko albo nic Consistence – po wykonaniu transakcji system będzie spójny Isolated – transakcje nie wpływają na siebie Durable – operacje wykonane w trakcie transakcji są trwałe • Przykład transakcji: Przelew bankowy 60 Transakcje w procesach biznesowych • W procesach biznesowych zwykle trudno spełnić wymagania ACID (problemem jest izolacja transakcji) • Czynności mogą trwać zbyt długo, by możliwe i sensowne było blokowanie zasobów realizujących czynności, np. zakup towaru w sklepie internetowym przy pomocy karty, gdzie po zakupie okazuje się, że producent towaru nie może go dostarczyć do sklepu 61 Podproces transakcji • Transakcja w procesach biznesowych jest rodzajem umowy pomiędzy dwoma lub więcej uczestnikami Aby transakcja zakończyła się sukcesem wszystkie strony umowy muszą zrealizować swoje czynności i zgodzić się na zakończenie transakcji Jeśli jedna ze stron wycofa się z umowy lub pojawi się nieoczekiwany błąd, wówczas transakcja jest anulowana i wszystkie strony podejmują działania zmierzające do cofnięcia / kompensacji wszystkich ukończonych czynności Przebieg transakcji jest kontrolowany przez tzw. protokół transakcyjny (np. WS-Transaction, BTP) 62 Zdarzenia występujące w transakcji Zgłoszenie anulowania transakcji Odbiera zgłoszenie o kompensacji Podproces transakcji Czynność wykonywana podczas obsługi kompensacji Odbiera zgłoszenie o błędzie Odbiera zgłoszenie o błędzie Odbiera zgłoszenie anulowania 63 Anulowanie transakcji – zgłoszenie • Anulowanie transakcji ma na celu przerwanie czynności wykonywanych w ramach podprocesu transakcyjnego i doprowadzenie do stanu sprzed wykonania tych czynności (kompensacja) • Istnieją dwa sposoby anulowania transakcji: – wewnątrz podprocesu transakcji istnieje ścieżka która prowadzi do zdarzenia końcowego Anuluj – protokół transakcyjny w pewnych sytuacjach sam zgłasza Anuluj • Zdarzenie końcowe Anuluj może być użyte tylko wewnątrz podprocesu transakcji 64 Anulowanie transakcji – obsługa • Anulowanie transakcji odbywa się według schematu try-catch • Zgłoszenie anulowania transakcji może być odebrane tylko przez zdarzenie krawędziowe anulowania, przypięte do podprocesu transakcyjnego • Po zgłoszeniu anulowania podproces transakcyjny jest przerywany • Zanim jednak proces podąży ścieżką anulowania zgłaszane jest zdarzenie kompensacji 65 Kompensacja – zgłaszanie • Kompensacja oznacza przywrócenie czynności do stanu sprzed jej wykonania • Niektóre czynności takie jak odebranie wiadomości nie mogą być cofnięte, inne takie jak np. zapis w bazie danych mogą być kompensowane • W podprocesie transakcji zgłoszenie konieczności kompensacji jest robione automatycznie po zgłoszeniu zdarzenia anulowania • Istnieje również możliwość zgłoszenia konieczności kompensacji poprzez zdarzenia kompensacji (pośrednie lub końcowe) 66 Kompensacja – obsługa • Zgłoszenie o konieczności kompensacji może być odebrane przez zdarzenie krawędziowe kompensacji lub przez podproces zdarzeniowy • Obsługą kompensacji zajmuje się specjalizowana czynność • Protokół transakcyjny pamięta kolejność w jakiej zostały wykonane czynności wewnątrz podprocesu transakcyjnego • Po odebraniu zgłoszenia o konieczności kompensacji dla każdej ukończonej czynności w kolejności odwrotnej do ich uruchomienia wykonuje procedurę kompensacji 67 Zakończenie transakcji Zakończenie prawidłowe (OK): Wszystkie czynności wewnątrz podprocesu transakcji zakończyły się poprawnie. Następnie pod kontrolą protokołu transakcyjnego wszyscy uczestnicy potwierdzili zamiar zakończenia transakcji (gdyby nie potwierdzili, to wygenerowano by zdarzenie anulowania transakcji) Zakończenie nieprawidłowe (Anulowanie transakcji): Zakończenie ryzykowne (Wystąpił nieodwracalny błąd): Transakcja anulowana przez zdarzenie anulowania z wewnątrz podprocesu transakcji lub przez protokół transakcyjny. Pod kontrolą protokołu transakcyjnego zdarzenie anulowania jest rozsyłane wszystkim uczestnikom. Następnie przerywane są wszystkie czynności i podjęta zostaje próba cofnięcia i kompensacji zakończonych czynności Wystąpił poważny błąd uniemożliwiający cofnięcie/ kompensację transakcji. Pod kontrolą protokołu transakcyjnego błąd jest przekazywany pozostałym uczestnikom. Wszystkie czynności są automatycznie przerywane. 68 KONIEC 69
