Skip to main content

Zdarzenia

Zasady ogólne​

Główne menu metadanych Zdarzenia obejmuje następujące zakładki:

  • Informacje ogólne
  • Przepływ
  • Parametry

Pola metadanych występujących w rozwinięciu zakładki Informacje ogólne obejmują następujące elementy:

  • Nazwa – tekst opisujący zdarzenie, który opcjonalnie może być prezentowany w grafie procesu
  • Numer – numer symbolu w ramach grafu procesu. Numer nie jest prezentowany na grafie jest natomiast dostępny w ramach Definicji (ang. Definition) procesu
  • Opis– może zawierać tylko tekst opisowy występujący jako dokumentacja projektanta. Opis występujący w zdarzeniu rzucającym z zasady nie powinien być powielany w powiązanym z nim zdarzeniu przechwytującym. W tym wypadku to pole występuje wyłącznie w zdarzeniach przechwytujących, które nie mają powiązanych zdarzeń rzucających.

Metadane zakładki Przepływ określają semantyką przepływów wejściowych i wyjściowych zdarzenia

Warunek

Rysunek 1. Metadane zdarzenia

Metadane zakładki Parametry zawierają następujące elementy:

  • Identyfikator typu (eventKind) zdarzenia rzucającego i zdarzenia przechwytującego. Wartość jest przypisywana automatycznie w oparciu w wybrany symbol graficzny zdarzenia.
  • Identyfikator instancji (eventId) zdarzenia rzucającego i zdarzenia przechwytującego. Wartość parametru pozwala na identyfikację par zdarzeń w strukturze modelu procesu.
  • Treść (eventContent) – parametr występuje w takich zdarzeniach jak Komunikat, Eskalacja i Sygnał. Pole służy do przekazania treści. Może to być wartość wskazanej globalnej zmiennej procesu typu String lub zapisana bezpośrednio treść.
  • Identyfikator instancji procesu (toProcessInstId) dostępna jako wartość zmiennej globalnej typu String lub wyrażenia BPQL, która została utworzona przez system w momencie inicjacji instancji procesu/podprocesu.
  • Identyfikator procesu (toProcessId) wartość wybrana jako jednoznaczny identyfikator obiektu obsługiwanego w ramach struktury proces/podprocesy. Wartość jest przekazywana jako parametr wejściowy (in) procesu najwyższego poziomu i jest dostępna w całej strukturze hierarchii procesów/podprocesów jako wartość zmiennej globalnej $name.
  • Identyfikator czynności (toActivityId) wartość typu String jest generowane jako numer czynności w trakcie tworzenia modelu procesu.
  • Identyfikator instancji czynności (toActivityInstId) dostępna jako wartość zmiennej globalnej typu String lub wyrażenia BPQL, która została utworzona przez system w momencie inicjacji instancji czynności.

Konfiguracja parametrów zdarzeń jest tworzona w trakcie modelowania procesu a wszystkie parametry, za wyjątkiem identyfikatora typu, Identyfikatora instancji zdarzenia oraz identyfikatora procesu są opcjonalne.

W przypadku zdarzeń autonomicznych (tj. bez zdarzeń rzucających) Warunek i Stoper parametry przekazują informację semantyczną, taką jak na przykład dla zdarzenia „Stoper” definicja parametrów czasowych a dla zdarzenia „Warunek” wyrażenie warunkowe BPQL.

Parametry zdarzenia implementują wyrażenie definicji zdarzenia (ang. event definition expression) notacji BPMN 2.02. Dla zdarzeń wielokrotnych wyrażenie jest definiowane dla każdego wybranego typu zdarzenia.

Definicja zdarzenia w oparciu o wyrażenie BPQL pozwala na ewaluacje warunków obejmujących różne źródła danych;

  • Globalne zmienne przechowywane jako elementy kontenera
  • Lokalne zmienne definiowane w ramach bloku instrukcji BPQL definiującego semantykę zdarzenia
  • Wartości pól elektronicznego formularza reprezentującego obiekt główny procesu wybierane bezpośrednio lub z pliku XML przez zapytania XPath
  • Wartości atrybutów ontologii Topic Maps dostępne bezpośrednio lub przez zapytania TMSL
  • Wartości elementów relacyjnej struktury danych materializowane poprzez zapytania SQL

Tabela 1 zawiera zestawienie wszystkich typów zdarzeń dostępnych w platformy docuRob®Workflow**.** Grupy zdarzeń są prezentowane w kolejności zgodnie z porządkiem menu głównego narzędzia projektowania procesów

Tabela 1. Zbiorcza tabela typów zdarzeń

Zdarzenia początkowe​

Zdarzenia początkowe powodują utworzenie instancji procesu najwyższego poziomu oraz podprocesów sterowanych zdarzeniem zdefiniowanych w jego zakresie. Stanowią one początkowy punkt przepływów zachodzących w procesie. Zdarzenie początkowe nie może mieć żadnych przepływów wchodzących i jest źródłem tylko jednego przepływu wychodzącego.

W przypadku czynności złożonych (oznaczonych symbolem +) zdarzeniem początkowym Podprocesu jest zdarzenie bez typu. Definicja zdarzenia początkowego jest obowiązkowa jeżeli w ramach procesu zdefiniowano zdarzenie końcowe.

Utworzenie instancji procesu może być również powodowane przez definicję czynności, która nie ma żadnych przepływów wchodzących i jest jedynie źródłem przepływów wychodzących.

Reguły aktywizacji procesu najwyższego poziomu​

  • Pojedyncze zdarzenie początkowe tworzy instancję procesu za każdym razem gdy występuje.
  • Wyjątkiem powyższej reguły jest zadanie Otrzymaj komunikat.
  • Dla Wielokrotnych zdarzeń początkowych obowiązują następujące scenariusze:
    • Wielokrotne powoduje instancjację dokładnie jednego wystąpienia procesu w oparciu o występujące w danym momencie zdarzenie. Nie czeka się na pozostałe zdarzenia.
    • Wielokrotne Równoległe (ang. Parallel Start) może aktywizować proces po wystąpieniu pierwszego zdarzenia. Instancja procesu może zostać zakończona po otrzymaniu i przetworzeniu pozostałych zdefiniowanych zdarzeń, które mogą napływać w dowolnym momencie wykonania instancji procesu.
  • Zakończenie instancji procesu może nastąpić po otrzymaniu przez element końcowy, to jest przez zadanie lub zdarzenie końcowe, wszystkich znaczników wytworzonych w ramach tej instancji procesu.

Reguły aktywizacji podprocesu sterowanego zdarzeniem​

  • Podproces sterowany zdarzeniem jest zawsze aktywizowany w momencie wystąpienia zdarzenia początkowego obejmującego go procesu i oczekuje na otrzymanie wyzwalacza swojego zdarzenia początkowego.
  • Podproces może być aktywizowany jedynie gdy obejmujący go Proces/Podproces jest aktywny. Możliwe jest aktywizowanie wielu instancji nieprzerywających podprocesów sterowanych zdarzeniem w trakcie wykonywanie obejmującego je procesu. W przypadku przerywających podprocesów wykonanie może odbyć się tylko jeden raz.
  • Jeżeli Podproces sterowany zdarzeniem startuje dla zdarzenia Błąd to obejmujący go Proces/Podproces oczekuje na przerwanie awaryjne do jego zakończenia .
  • Jeżeli Podproces sterowany zdarzeniem startuje dla przerywającego zdarzenia innego niż Błąd (np. Eskalacja) to obejmujący go Proces/Podproces wchodzi w stan Kończenia i oczekuje do jego zakończenia.
  • Procesy/podprocesy sterowane zdarzeniem nie mogą mieć zdarzeń krawędziowych.
  • Podproces przerywa lub nie przerywa obejmującą go instancję Procesu/Podprocesu ale zawsze jest wykonywany w jej kontekście. To oznacza również pełny dostęp do zawartości zmiennych globalnych.
  • Podproces sterowany zdarzeniem może ponownie uruchomić zdarzenie którym był wywołany poprzez powtórzenie go w formie zdarzenia końcowego, aby umożliwić jego dalsze przetwarzanie w oparciu o krawędziowe zdarzenie wywołującego go Procesu/Podprocesu.

Zdarzenia pośrednie​

Zdarzenia pośrednie są umieszczane w dowolnym miejscu struktury przepływów procesu za wyjątkiem jej początków oraz końców. Mogą one również dotyczyć czynności procesu, zarówno elementarnych jak i złożonych, występując w modelu jako przechwytujące zdarzenia pośrednie krawędziowe.

Zdarzenia pośrednie przechwytujące są wykorzystywane w ramach struktury normalnych przepływów (ang. normal flow). Po otrzymanie znacznika następuje aktywizacja zdarzenia przechwytującego, które następnie oczekuje na otrzymanie wyzwalacza. Po wykonaniu obsługi zdarzenia znacznik jest przeniesiony zgodnie z przepływem do następnej czynności.

Zdarzenia rzucające, których celem jest Podproces sterowany zdarzeniem nieprzerywającym (ang. Event Sub-process), przekazują znacznik dalej po wszystkich wychodzących przepływach.

Zdarzenia pośrednie krawędziowe są aktywizowane w momencie otrzymania znacznika przez czynność elementarną lub złożoną, na której krawędzi zostały one umieszczone. Wyzwalacz uruchamiający zdarzenie krawędziowe jest rzucany przez odpowiadające mu zdarzenie rzucające lub, tak jak w przypadku zdarzeń Stoper i Warunek, jest wykonywane gdy zachodzi spełnienie opowiadającego mu warunku czasowego albo logicznego.

Wyzwalacz jest propagowany od zdarzenia rzucającego do odpowiedniego zdarzenia krawędziowego przywiązanego do najbliższej czynności obejmującej to zdarzenie rzucające (np. procesu lub podprocesu) . Jeżeli nie zostanie znalezione zdarzenie przechwytujące oczekujące na utworzony wyzwalacz to zdarzenie rzucające pozostanie nieobsłużone. Zdarzenia umieszczane na krawędzi czynności mogą być przerywające (ang. interrupting) lub nieprzerywające (ang. non-interrupting).

Reguły wykonania zdarzeń pośrednich​

  • Zdarzenie pośrednie rzucające po otrzymaniu aktywizującego go znacznika tworzy i wysyła wyzwalacz zgodnie z zawartym w jego definicji opisem zdarzenia. Bezpośrednio po wykonaniu powyższej operacji znacznik jest przekazywany do następnej czynności.
  • Zdarzenie pośrednie przechwytujące otrzymuje aktywizujący je znacznik i oczekuje na otrzymania wyzwalacza od powiązanego zdarzenia rzucającego. Po otrzymaniu wyzwalacza zdarzenie przechwytujące przekazuje znacznik do następnej czynności wskazanej przez jego przepływ wychodzący.

Reguły wykonania zdarzeń pośrednich krawędziowych​

  • Zdarzenia krawędziowe przerywające powodują kontynuację obiegu znacznika po przepływie, lub przepływach, wyjątku (ang. exception flow). W przypadku wielu przepływów wychodzących, które dotyczą różnych zdarzeń krawędziowych występujących w ramach czynności, wszystkie otrzymują znacznik.
  • Zdarzenia krawędziowe nieprzerywające otrzymują sklonowany znacznik i jednocześnie realizacja powiązanej czynności jest kontynuowana. Po zakończeniu wykonania każdego z tych elementów znaczniki są przesyłane po odpowiednich przejściach wychodzących.

Zdarzenia końcowe​

Zdarzenia końcowe zamykają bieg procesu i nie mogą mieć żadnych przepływów wychodzących. Jeżeli w Procesie/Podprocesie występuje zdarzenie końcowe to obowiązkowe jest wystąpienie przynajmniej jednego zdarzenia początkowego na tym samym poziomie. Za wyjątkiem zdarzenia Zakończenie pozostałe zdarzenia końcowe mogą być wykonane jedynie gdy w Procesie/Podprocesie nie ma już żadnych aktywnych czynności, to jest w jego strukturze nie występują już żadne znaczniki. Zdarzenie końcowe „konsumuje” kolejne przybywające do niego znaczniki aż bieg wszystkich znaczników wygenerowanych w ramach tego poziomu zostanie zakończony. Wyjątkiem są znaczniki, które są konsumowane w ramach czynności przerywanych przez krawędziowe zdarzenia pośrednie. Dotyczy to również początkowych zdarzeń przerywających w podprocesach sterowanych zdarzeniem.

Reguły kończenia Procesu/Podprocesu​

  • W przypadku zdarzenia końcowego Zakończenie instancja obejmującego go Procesu/Podprocesu jest przerwana. Inne instancje tego procesu nie są kończone. Przerywane są wszystkie czynności występujące w tej instancji procesu również takie jak Kompensacja czy Podproces sterowany zdarzeniem.
  • Dla wszystkich pozostałych zdarzeń końcowych działanie jest określone przez typ wyzwalacza, natomiast instancja procesu jest kończona tylko gdy dwa następujące warunki są prawdziwe:
  • Wszystkie zdarzenia wchodzące w skład początkowego Wielokrotnego zdarzenie równoległego były uruchomione.
  • Nie ma żadnego znacznika w tej instancji procesu.

Reguły kończenia Podprocesu sterowanego zdarzeniem​

W przypadku zdarzenia końcowego Zakończenie jego instancja podprocesu jest przerywana. W przypadku wieloinstancyjnego podprocesu inne instancje tego podprocesu, jak również instancje podprocesów na wyższym poziomie hierarchii oraz instancja procesu najwyższego poziomu nie są kończone.

Dla wszystkich pozostałych zdarzeń końcowych zachodzi działanie określone przez typ wyzwalacza, natomiast instancja podprocesu jest kończona tylko gdy dwa następujące warunki są prawdziwe:

  • Wszystkie zdarzenia początkowe podprocesu były uruchomione (Wielokrotne zdarzenie równoległe).
  • Nie ma żadnego znacznika w tej instancji podprocesu.

Typy zdarzeń​

Zdarzenie bez typu wyzwalacza​

Tabela 2. Zdarzenie bez typu wyzwalacza

Startowe przechwytujące​

Zdarzenie jest inicjowane przez operację createProcessInstance dostępną w API platformy docuRob®WorkFlow. Wynikiem jest utworzenie nowej instancji procesu najwyższego poziomu na podstawie wskazanej definicji Procesu/Podprocesu, na rzecz wskazanego Użytkownika, uwzględniając parametry wejściowe oraz opcjonalną referencję do zewnętrznego kontenera danych

Zdarzenie jest opcjonalne na poziomie Procesu najwyższego poziomu lub Podprocesu definiowanego w ramach struktury przepływów obejmującego go Procesu. Zdarzenie Początek i odpowiadające mu zdarzenie Koniec są niezależne od innych poziomów hierarchii procesów.

Wszystkie obiekty struktury przepływów procesu (ang. Flow Objects), które nie mają przepływów wchodzących są aktywizowane w ramach instancjacji obejmującego je procesu.

Zdarzenie jest wykorzystywane do instancjacji podprocesów otrzymujących znacznik w ramach zdefiniowanej struktury przepływów obejmującego go Procesu/Podprocesu. Podproces stanowi element hierarchii podprocesów zdefiniowanych w ramach procesu najwyższego poziomu i jest uruchamiany w ramach czynności złożonej, która jest wyróżniona j wskaźnikiem +.

Pośrednie rzucające​

Zdarzenie rzucające bez typu może wystąpić jedynie w ramach struktury normalnych przepływów Procesu/Podprocesu. Zdarzenie nie uruchamia żadnego wyzwalacza i może być wykorzystane (np. w logu) do sygnalizowania bieżącego stanu procesu.

Końcowe rzucające​

Zdarzenie kończące przerywa wykonanie ścieżki instancji procesu zgodnie z przyjętym algorytmem kończenia Procesu/Podprocesu i nie rzuca żadnego wyzwalacza.

Komunikat​

Tabela 3. Komunikat

Komunikat może być nadany przez inny, zewnętrzny Proces/Podproces, który nie jest hierarchicznie związany z tym samym Procesem najwyższego poziomu, to znaczy, że powiązane zdarzenie rzucające może być umieszczone w ramach struktury przepływów innego Procesu najwyższego poziomu i/lub jego powiązanych hierarchicznie Podprocesów.

Startowe – proces najwyższego poziomu​

Po otrzymaniu komunikatu platforma docuRob®WorkFlow inicjuje nową instancję Procesu zawierającego zadanie startowe typu Komunikat.

Startowe przerywające – podproces sterowany zdarzeniem​

Po otrzymaniu oczekiwanego Komunikatu zdarzenie startowe powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem jednocześnie inicjując zakończenie wykonania Procesu/Podprocesu w ramach którego jest zdefiniowany dany podproces. Środowisko obejmującego Procesu/Podprocesu jest dostępne aż do momentu zakończenia zainicjowanego Podprocesu sterowanego zdarzeniem.

Startowe nieprzerywające – podproces sterowany zdarzeniem​

Po otrzymaniu oczekiwanego Komunikatu zdarzenie startowe powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem. Jednocześnie Podproces zawierający zdarzenie rzucające kontynuuje wykonanie.

Pośrednie przechwytujące​

Po otrzymaniu Komunikatu proces jest kontynuowany. W przypadku przerywającego zdarzenia krawędziowego znacznik jest przesyłany dalej przez przepływ wyjątku (ang. exception flow) a w przypadku zdarzenia nieprzerywającego również przez przepływ normalny, po zakończeniu powiązanej z nim czynności.

Pośrednie rzucające​

Wysłanie Komunikatu do innego Procesu/Podprocesu, który nie jest powiązany w ramach hierarchii bieżącego (wysyłającego) Procesu/Podprocesu. Po wysłaniu Komunikatu bieg procesu jest kontynuowany zgodnie z definicją normalnych przepływów.

Końcowe rzucające​

Wysłanie Komunikatu do zewnętrznego nasłuchującego procesu, podprocesu lub systemu informatycznego, które zainicjowały kończony proces. Żaden z powyższych elementów nie może należeć do tej samej hierarchii Procesu najwyższego poziomu.

Stoper​

Tabela 4. Stoper

Po otrzymaniu znacznika w ramach wykonania obejmującego go instancji Procesu/Podprocesu Zdarzenie przechwytujące Stoper oczekuje na spełnienie zdefiniowanego warunku czasowego.

Zdarzenie oczekuje aż upłynie zadany okres czasu. Można go zdefiniować na trzy sposoby:

  • bezwzględnie: określona liczba dni, godzin, minut i sekund
  • względnie: określona data i/lub godzina która musi minąć (np. piątek godz. 15:50:59 lub 25-ty dzień miesiąca godz. 07:59:59 )
  • dynamicznie: za pomocą wyrażenia BPQL. Wyrażenie musi zwrócić czas oczekiwania w milisekundach. Jest ono ewaluowane od nowa podczas każdego uruchomienia Zdarzenia Stoper (np. w pętlach).

Startowe – proces najwyższego poziomu​

Po spełnieniu warunku czasowego określonego w definicji zdarzenia platforma docuRob®WorkFlow inicjuje nową instancję typu Procesu zawierającego zdarzenie startowe typu „Stoper”.

Startowe przerywające – podproces sterowany zdarzeniem​

Po spełnieniu warunku czasowego określonego w jego definicji Zdarzenie startowe powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem jednocześnie inicjując zakończenie wykonania Procesu/Podprocesu w ramach którego jest zdefiniowany dany podproces.

Startowe nieprzerywające – podproces sterowany zdarzeniem​

Po spełnieniu warunku czasowego określonego w jego definicji Zdarzenie startowe powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem. Jednocześnie Proces/Podproces kontynuuje wykonanie.

Pośrednie​

Zdarzenie przechwytujące Stoper jest inicjowane po otrzymanie znacznika w ramach normalnych przepływów lub w przypadku zdarzenia krawędziowego razem z powiązaną z nim czynnością. Po spełnieniu warunku czasowego określonego w jego definicji Zdarzenie pośrednie przekazuje znacznik normalnym przejściem. W przypadku Zdarzenia krawędziowego przerywającego zakańczana jest powiązana z nim czynność a znacznik jest przekazywany przejściem wyjątku. Zdarzenie krawędziowe nieprzerywające pozwala na kontynuacje powiązanej czynności a znaczniki będą przekazywane dalej odpowiednio przez przejścia normalne czynności i przejścia wyjątku zdarzenia krawędziowego.

Błąd​

Tabela 5. Błąd

Zdarzenie typu Błąd jest zawsze zdarzeniem przerywającym ponieważ jest inicjowane po wystąpieniu błędu, który spowodował przerwanie wykonania. Znacznik jest przekazywany przejściem wyjątku.

Startowe przerywające – podproces sterowany zdarzeniem​

Uruchamia Podproces obsługi błędu oczekujący na wyzwalacz generowany przez odpowiadające mu zdarzenie rzucające zdefiniowane w obejmującym go Procesie/Podprocesie. Ze względu na charakter zdarzenia dotyczącego błędu skutkuje ono zawsze przerwaniem działania obejmującego Procesu/Podprocesu.

Pośrednie krawędziowe​

Zdarzenie otrzymuje wyzwalacz związany z konkretnym rodzajem błędu lub, jeżeli taki nie został określony, wyzwalacze związane z błędami dowolnego rodzaju. Zdarzenie przechwytujące występuje wyłącznie w formie przerywającej. Zdarzenie po otrzymania wyzwalacza przerywa wykonanie powiązanej czynności.

Końcowe rzucające​

Taki typ zdarzenia końcowego powoduje wygenerowanie nazwanego komunikatu błędu, który wystąpił w zamykanym Podprocesie. Wszystkie bieżąco wykonywane ścieżki podprocesu są zakańczane.

Eskalacja​

Tabela 6. Eskalacja

Startowe przerywające – podproces sterowany zdarzeniem​

Po otrzymaniu znacznika zdarzenie startowe powoduje rozpoczęcie wykonania Podproces sterowanego zdarzeniem jednocześnie inicjując zakończenie wykonania Procesu/Podprocesu w ramach którego jest zdefiniowany dany Podproces.

Startowe nieprzerywające – podproces sterowany zdarzeniem​

Po otrzymaniu znacznika zdarzenie startowe powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem. Jednocześnie Podproces zawierający zdarzenie rzucające kontynuuje wykonanie.

Pośrednie krawędziowe​

Wersja przerywająca zdarzenia Eskalacja przerywa wykonania powiązanej czynności a znacznik jest przekazywany dalej zgodnie z przepływem wyjątku.

Wersja nieprzerywająca zdarzenia Eskalacja nie przerywa wykonania powiązanej czynności i jest generowany dodatkowy znacznik, który jest przekazywany dalej zgodnie z przepływem wyjątku.

Pośrednie rzucające​

Występuje w ramach normalnej struktury przepływów Procesu/Podprocesu i uruchamia po otrzymaniu znacznika nasłuchujące zdarzenie Eskalacja. Docelowe zdarzenie może być przerywającym lub nieprzerywającym zdarzeniem krawędziowym lub zdarzeniem początkowym Podprocesu sterowanego zdarzeniem

Końcowe rzucające​

Końcowe rzucające zdarzenie Eskalacja kończy instancję zawierającego je Procesu/Podprocesu i uruchamia powiązane zdarzenie przechwytujące umieszczone w Procesie/Podprocesie wyższego poziomu wywołującym dany Podproces.

Kompensacja​

Tabela 7. Kompensacja

Czynność kompensująca ma za zadanie odwrócenie skutków czynności wykonywanych automatycznie lub zadań wykonywanych przez Użytkownika oraz Podprocesów powiązanych z nimi poprzez nasłuchujące zdarzenie Kompensacja. Powiązanie pomiędzy czynnością a jej czynnością kompensującą jest definiowane przez związek (ang. association) reprezentowany w grafie procesu jako linia przerywana. Kompensacja dotyczy wyłącznie czynności wykonanych i zakończonych prawidłowo. Zdarzenia Kompensacja powiązane z czynnością zakończoną błędem lub nie wykonaną są ignorowane. Przechwytujące zdarzenia Kompensacja są modelowane wyłącznie jako zdarzenia przerywające ponieważ powiązane z nimi Czynności muszą być już zakończone.

Czynność Kompensacja (ang. Compensation handler) może być implementowana jako czynność automatyczna albo Podproces nie powiązane ze strukturą przepływów obejmującego je Procesu/Podprocesu lub jako Podproces sterowany zdarzeniem uruchomiany przez startowe przechwytujące zdarzenie Kompensacja.

W pierwszym przypadku czynność lub Podproces Kompensacja są oznaczone wskaźnikiem i powiązane z kompensowaną czynnością poprzez krawędziowe przechwytujące zdarzenie przerywające, którego wyzwalacz jest generowany przez odpowiednie zdarzenie rzucające zarówno pośrednie jak i końcowe. Natomiast uruchomienie Podprocesu sterowania zdarzeniem odbywa się bezpośrednio poprzez jego zdarzenie startowe typu Kompensacja.

Obsługa wyzwalacza Kompensacja odbywa się synchronicznie co znaczy, że zdarzenie rzucające oczekuje na zakończenie działania wywoływanej czynności Kompensacja. Oczekiwanie na zakończenie obejmuje zarówno kompensujące czynności jak i podprocesy, w tym Podprocesy sterowane zdarzeniem.

Pośrednie krawędziowe​

Zdarzenie jest aktywizowane w momencie otrzymania znacznika przez powiązaną z nim czynność i oczekują po jej zakończeniu na ewentualne otrzymanie wyzwalacza rzuconego przez odpowiednie zdarzenie rzucające. Jeżeli warunki rozpoczęcia kompensacji są spełnione to zostanie uruchomiona powiązana z nim czynność typu Kompensacja.

Dla Wielokrotnych czynności każda z współbieżnych instancji jest kompensowana przez dedykowaną dla niej instancję czynności Kompensacja. Wywołanie kompensującego Podprocesu sterowanego zadaniem obejmuje jednoczesną kompensację wszystkich instancji Wielokrotnej czynności.

Startowe zdarzenie przerywające podprocesu​

Zdarzenie jest aktywizowane w momencie rozpoczęcia obejmującego go Procesu/Podprocesu i oczekuje na otrzymanie wyzwalacza wygenerowanego przez pośrednie lub końcowe zdarzenie rzucające. Uruchomienie zdarzenia powoduje utworzenie instancji Podprocesu sterowanego zdarzeniem Kompensacja odwracającego skutki czynności wykonanych w ramach obejmującego ją Procesu/Podprocesu.

Pośrednie rzucające​

Rzucające zdarzenie Kompensacja występujące w normalnym przepływie grafu procesu powoduje uruchomienie czynności kompensacyjnych poprzez dowolne nasłuchujące zdarzenie Kompensacja jeżeli nie zostało zaadresowane konkretne nasłuchujące zdarzenie tego typu. W każdym z obu przypadków kompensacja zostanie wykonana dla czynności spełniających następujące warunki:

  • Pośrednie zdarzenie rzucające jest zawarte w normalnym przepływie tego samego poziomu Procesu/Podprocesu
  • Pośrednie zdarzenie rzucające jest zawarte w Podprocesie sterowanym zdarzeniem Kompensacja, który jest zawarty w tym samym poziomie Procesu/Podprocesu.

Końcowe rzucające​

Zakończenie instancji procesu przez końcowe zdarzenia rzucające Kompensacja powoduje uruchomienie czynności kompensacyjnych poprzez dowolne nasłuchujące zdarzenie tego typu, jeżeli nie zostało ono zaadresowane przez konkretne rzucające zdarzenie Kompensacja. W każdym z obu przypadków kompensacja zostanie wykonana dla czynności spełniających następujące warunki:

  • Końcowe zdarzenie rzucające jest zawarte w normalnym przepływie tego samego poziomu Procesu/Podprocesu
  • Końcowe zdarzenie rzucające jest zawarte w Podprocesie Sterowanym Zdarzeniem „Kompensacja”, który jest zawarty w tym samym poziomie Procesu/Podprocesu.

Warunek​

Tabela 8. Warunek

Po otrzymaniu znacznika zdarzenie Warunek, występujące w ramach obejmującej je instancji Procesu/Podprocesu, oczekuje na spełnienie zdefiniowanego warunku logicznego. Warunek, którego ewaluacja zwraca wartość logiczną „prawda” lub „fałsz”, jest definiowany jako wyrażenie BPQL.

Startowe – proces najwyższego poziomu​

Po spełnieniu warunku logicznego określonego w definicji zdarzenia platforma docuRob®WorkFlow inicjuje nową instancję Procesu najwyższego poziomu zawierającego zdarzenie startowe Warunek. Wyrażenie BPQL może sięgać do źródeł danych istniejących poza inicjowanym Procesem najwyższego poziomu oraz do zmiennych statycznych związanych z jego definicją.

Startowe przerywające – podproces sterowany zdarzeniem​

W przypadku spełnienia warunku logicznego zdarzenie startowe Warunek powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem jednocześnie inicjując zakańczanie wykonania Procesu/Podprocesu w ramach którego jest zdefiniowany dany Podproces. Dla zachowania możliwości dostępu do kontekstu obejmującego Procesu/Podprocesu faza zakańczania instancji jest synchroniczna z wywołanym Podprocesem sterowanym zdarzeniem.

Startowe nieprzerywające – podproces sterowany zdarzeniem​

W przypadku spełnienia warunku logicznego Zdarzenie startowe powoduje rozpoczęcie wykonania Podprocesu sterowanego zdarzeniem. Jednocześnie obejmujący Proces/Podproces kontynuuje wykonanie.

Pośrednie przechwytujące​

Po otrzymanie znacznika zdarzenie Warunek oczekuje na spełnienie warunku logicznego podanego w jego definicji. Po spełnieniu warunku zdarzenie przesyła znacznik po właściwym przejściu wychodzącym.

Pośrednie​

Zdarzenie Warunek jest inicjowane po otrzymanie znacznika w ramach normalnych przepływów lub w przypadku zdarzenia krawędziowego razem z powiązaną z nim czynnością. Po spełnieniu warunku logicznego zdarzenie pośrednie przekazuje znacznik normalnym przejściem. W przypadku zdarzenia krawędziowego przerywającego zakańczana jest powiązana z nim czynność a znacznik jest przekazywany przejściem wyjątku. Zdarzenie krawędziowe nieprzerywające pozwala na kontynuacje powiązanej czynności a znaczniki będą przekazywane dalej odpowiednio przez przejścia normalne i przejścia wyjątku.

Łącze​

Tabela 9. Łącze

Pośrednie zdarzenia Łącze mogą być wykorzystywana w ramach struktury normalnych przepływów jednego Procesu/Podprocesu do łączenia fragmentów grafu procesu. Zdarzenie pozwala na unikanie długich linii przepływów, które mogą przebiegać pomiędzy czynnościami umieszczonymi w odległych sekcjach grafu. Typowym wykorzystaniem może być definiowanie cykli procesu obejmujących wiele różnych elementów notacji BPMN 2.02.

Pośrednie przechwytujące​

Wiele różnych rzucających zdarzeń typu „Łącze” może wskazywać na jedno przechwytujące zdarzenie Łącze.

Pośrednie rzucające​

To samo rzucające zdarzenie „Łącze może wskazywać na jedno przechwytujące zdarzenie Łącze.

Sygnał​

Tabela 10. Sygnał

Przechwytujące​

Zdarzenie startowe procesu najwyższego poziomu Sygnał może inicjować instancję Procesu jeżeli odbierze wyzwalacz wygenerowany przez instancję innego procesu lub zewnętrznego systemu informatycznego. Takie zewnętrzne zdarzenie może być nasłuchiwane przez wiele różnych zdarzeń startowych różnych procesów. Zdarzenie przechwytujące Sygnał może otrzymać treść komunikatu generowaną przez powiązanie z nim zdarzenie rzucające.

Przerywające zdarzenie startowe Sygnał inicjuje instancję Podprocesu sterowanego zdarzeniem i jednocześnie przerywa wykonanie instancji otaczającego go Procesu/Podprocesu. Podobnie działa Nieprzerywające zdarzenie startowe Sygnał pozwalając jednak na kontynuację instancji otaczającego go Podprocesu.

Pośrednie zdarzenia Sygnał po aktywizacji przechwytują wyzwalacze generowane przez rzucające zdarzenia występujące zarówno wewnątrz zakresu widoczności jak i te generowane przez zewnętrzne procesy i/lub niezależne systemy informatyczne. Po otrzymaniu wyzwalacza zdarzenia przechwytujące, poza obsługą związaną z przerwaniem lub nie zawierającej je czynności, przekazują znacznik przez wychodzące z nich przepływy wyjątku.

Krawędziowe zdarzenia Sygnał działają analogicznie do zdarzeń inicjujących Podprocesy sterowane zdarzeniem, przy czym przerywają lub nie instancję swojej macierzystej czynności. W przypadku opcji przerwania wykonania instancji znacznik jest przekazywany tylko przepływami wyjątku wychodzącym ze zdarzenia natomiast w przypadku jej kontynuacji znacznik jest również przekazywany normalnym przepływem.

Pośrednie rzucające​

Po otrzymaniu znacznika pośrednie zdarzenia rzucające Sygnał generują odpowiedni wyzwalacz, który może być odbierany przez dowolne zdarzenia przechwytujące znajdujące się w stanie aktywnym, to jest posiadające znacznik.

Końcowe rzucające​

Końcowe rzucające zdarzenia Sygnał działają analogicznie do poprzedniego a dodatkowo kończą instancję Procesu/Podprocesu zgodnie z przyjętymi ograniczeniami operacji zamykających przetwarzanie.

Zakończenie​

Tabela 11. Zakończenie

Zdarzenie Zakończenie powoduje natychmiastowe zamknięcie procesu. Oznacza to, że wszystkie czynności, w tym wszystkie instancje Wielokrotnych czynności, zostaną bezwarunkowo zamknięte. Proces jest zamykany bez wykonania kompensacji ani obsługi zdarzeń.

Wielokrotne​

Tabela 12. Wielokrotne

Wielokrotne zdarzenia zawierają więcej niż jedną definicję zdarzenia i odpowiednio rzucają lub przechwytują odpowiadające im typy wyzwalaczy. W przypadku Zdarzeń startowych efektem ich działania jest uruchomienie instancji Procesu/Podprocesu, natomiast w przypadku pośrednich zdarzeń krawędziowych wyjście z nich odbywa się z wykorzystaniem przepływów wyjątku w przypadku zdarzeń przerywających lub, dla zdarzeń nieprzerywających przez przepływy wyjątku i przepływy normalne.

Startowe przechwytujące​

Wielokrotne zdarzenie startowe pozwala na inicjowanie instancji Procesu/Podprocesu zgodnie z definicjami wymienionych w nim pojedynczych zdarzeń. Wystarczy wystąpienie jednego z nich aby utworzyć instancję Procesu/Podprocesu.

Przechwytujące wielokrotne zdarzenia startowe są obsługiwana w analogiczny sposób dla Procesu najwyższego poziomu jak i dla Podprocesu sterowanego zdarzeniem. W tym drugim przypadku mogą wystąpić dwa warianty zdarzeń startowych, to jest wariant przerywający, który powoduje przerwanie wykonania instancji Procesu obejmującego ten Podproces, oraz wariant nieprzerywający pozwalający na jego kontynuację.

Pośrednie przechwytujące​

Wielokrotne zdarzenia pośrednie występujące w ramach struktury normalnych przepływów po otrzymaniu znacznika nasłuchują na zdarzenia rzucające zgodnie ze zdefiniowaną dla nich listą definicji zdarzeń. Po wystąpieniu przynajmniej jednego z takich zdarzeń znacznik jest przesyłany dalej przez odpowiednie wychodzące przepływy.

Pośrednie rzucające​

Pośrednie wielokrotne zdarzenie rzucające po otrzymaniu znacznika generuje Wyzwalacze dla wszystkich definicji zdarzeń umieszczonych na jego liście.

Końcowe rzucające​

Jeżeli Proces/Podproces jest kończony Wielokrotnym zdarzeniem rzucającym to wyzwalacze są generowane dla wszystkich definicji zdarzeń umieszczonych na jego liście.

Wielokrotne równoległe​

Tabela 13. Wielokrotne równoległe

Wielokrotne równoległe zdarzenia zawierają więcej niż jedną definicję zdarzenia i przechwytują odpowiadające im typy wyzwalaczy. W przypadku zdarzeń startowych efektem ich działania jest uruchomienie instancji Procesu/Podprocesu, natomiast w przypadku pośrednich zdarzeń krawędziowych wyjście z nich odbywa się przez przepływy wyjątku lub dla zdarzeń nieprzerywających również przez przepływy normalne.

Przechwytujące startowe​

Wielokrotne równoległe zdarzenie startowe pozwala na inicjowanie instancji Procesu/Podprocesu zgodnie z definicją zdarzenia wymienionych w nim pojedynczych zdarzeń. Aby nastąpiło utworzenie instancji Procesu/Podprocesu muszą wystąpić wszystkie zdarzenia zaznaczone na liście.

Przechwytujące wielokrotne zdarzenia startowe są obsługiwana w analogiczny sposób dla Procesu najwyższego poziomu jak i dla Podprocesu sterowanego zadaniami. W tym drugim przypadku mogą wystąpić dwa warianty zdarzeń startowych, to jest wariant przerywający, który powoduje przerwanie wykonania instancji Procesu obejmującego ten Podproces, oraz wariant nieprzerywający pozwalający na jego kontynuację.

Przechwytujące pośrednie​

Wielokrotne zdarzenia pośrednie występujące w ramach struktury normalnych przepływów po otrzymaniu znacznika nasłuchują na zdarzenia rzucające zgodnie ze zdefiniowaną dla nich listą definicji zdarzeń. Po wystąpieniu wszystkich zdarzeń umieszczonych na liście znacznik jest przesyłany dalej przez odpowiednie wychodzące przepływy zdarzenia.

Przykłady zdarzeń w modelowaniu procesów​

Wprowadzenie rozbudowanego modelu zdarzeń w modelu graficznym BPMN2 pozwala na tworzenie bogatych semantycznie opisów procesów, które nie tylko ułatwiają porozumienie z ich potencjalnymi użytkownikami (ludzie biznesu) ale także na budowanie wykonywalnych odwzorowań przebiegu rzeczywistych procesów istniejących w organizacji z uwzględnieniem przypadków odstępstw of oczekiwanego biegu procesu (ang. ‘lucky path’) reprezentujących sytuacje życiowe.

Wykorzystanie możliwości modelowania zdarzeń na etapie wykonywalnych grafów procesów pracy omówiono szczegółowo w tym rozdziale. Poniżej przedstawiamy szereg użytecznych wzorców projektowych, które pozwolą na lepsze zrozumienie możliwości w zakresie projektowania i implementacji aplikacji procesowych.

Każdy z przykładów jest prezentowany na dwóch współzależnych poziomach, to jest na poziomie modelu analitycznego opracowanego w narzędziu projektowania procesów pracy oraz jako graf wykonania procesu. Jeżeli warto pokazać różne warianty wykonania przyjętego modelu procesu (fragmentu procesu) to wykorzystujemy grafy historii poszczególnych omawianych wariantów wykonania.

Wsparciem dla interpretacji stanów czynności widocznych w grafie historii wykonania procesu jest Rysunek 2. Legenda jest umieszczana w prawym górnym rogu ekranu i została obcięta ze względu na konieczność zachowania widoczności prezentowanych zrzutów ekranów.

Rysunek 2. Legenda stanów wykonania czynności procesu w grafie historii wykonania

Przykład 1 – Bramka sterowana zdarzeniami​

W przykładzie pokazujemy model Bramki sterowanej zdarzeniami będącej w istocie klasyczną bramką XOR typu split z tą różnicą, że jej działanie jest uzależnione od zdarzeń, które są elementem konfiguracji bramki. W naszym przypadku mamy do czynienia z dwoma warunkami (Warunek1 i Warunek2) oraz z ograniczeniem czasowym reprezentowanym przez Stoper. Wszystkie zdarzenia stosowane w tej bramce muszą należeć do kategorii Pośrednie przechwytujące.

Model procesu przedstawia Rysunek 3 a grafy historii wykonania instancji procesu odpowiednio Rysunek 4 i Rysunek 5.

Model procesu (Rysunek 3) odpowiada sytuacji w której po otrzymaniu znacznika bramka przekazuje znaczniki do wszystkich zdefiniowanych w jej konfiguracji zdarzeń, a te z kolei oczekują na spełnienie swojego warunku (wartość logiczna lub upływ czasu dla Stopera).

Po wystąpieniu któregokolwiek ze opisanych zdarzeń zostanie wybrana odpowiednia ścieżka procesu a wykonanie pozostałych warunków zostanie przerwane. Widać to na grafach historii wykonania procesów odpowiadających poszczególnym wariantom ich wykonania.

W pierwszym wariancie wykonania procesu zdarzenie Warunek1 zostało wykonane a pozostałe zdarzenia przerwane (Rysunek 4). W drugim wariancie żaden warunek nie został spełniony i po odpowiednim czasie Stoper przekazał znacznik do czynności D a oba zdarzenia (Warunek1 i 2) zostały Przerwane.

Rysunek 3. Definicja Bramki sterowanej zdarzeniami

Rysunek 4. Graf historii wykonania Bramki sterowanej zdarzeniami wariant 1

Bramki sterowanej zdarzeniami mogą być umieszczane w dowolnym miejscu grafu procesu/podprocesu w tym również bezpośrednio po zdarzeniu początkowym. W przypadku gdy jako zdarzenia występują czynności Odbiór możemy modelować przebieg komunikacji pomiędzy różnymi procesami pracy zdefiniowanych także na różnych platformach narzędziowych.

Rysunek 5. Graf historii wykonania Bramki sterowanej zdarzeniami wariant2

Przykład 2 Kompensacja​

Kompensacja pośrednich wyników procesów jest typowym działaniem koniecznym dla właściwej obsługi sytuacji wyjątkowych, które z różnych powodów mogą mieć miejsce w trakcie przebiegu procedury wspomaganej w ramach instancji procesu pracy. Obsługa takich sytuacji musi zostać uwzględniona na poziomie modelu poprzez wprowadzania do grafu procesu odpowiednich typów czynności.

W używanej w systemie docuRob®WorkFlow notacji BPMN 2.02 przewidziano odpowiednie typy zdarzeń oraz czynności pozwalające na modelowanie idempotentnych procesów, to jest procesów działających zgodnie w wymaganiem aby pośrednio uzyskane wyniki wykonywanych w ramach procesu działań (np. rezerwacja biletów lotniczych) mogły być odwracane w przypadku wystąpienia sytuacji wyjątkowej.

W naszym przykładzie przedstawiamy jeden w wielu możliwych wzorców obsługi kompensacji wyników zadań wykonanych w ramach instancji procesu dla różnych konfiguracji dwóch instancji procesów pracy, z których jedna jest procesem wyższego poziomu a druga jest wywoływanym podprocesem. Modele takich współdziałających procesów przedstawiają odpowiednie Rysunek 6 i Rysunek 7.

Model współpracujących procesów przewiduje prawidłowe zakończenie procesów w ramach oczekiwanej ścieżki oraz wybór jednej z dwóch różnych możliwości kompensacji występujących w podprocesie zadań Użytkownik modelowanych przez czynności C i D.

Historię wykonania trzech wariantów 1, 2 lub 3, które przedstawiają odpowiednio pary Rysunek 10 i Rysunek 11, Rysunek 12 i Rysunek 13 oraz Rysunek12 i Rysunek 13. Oba warianty przewidują automatyczną kompensację (Skrypt) skutków wykonania zadań przez użytkowników.

Pierwsza para grafów historii wykonania prezentuje oczekiwane ścieżki przebiegów obu instancji procesów bez konieczności odwoływania się do czynności Kompensacja.

Rysunek 6. Definicja procesu wyższego poziomu

Rysunek 7. Definicja podprocesu obejmującego kompensowane zadania

W drugim przypadku (Rysunek 10 i Rysunek 11) obsługa wyjątku polega na zakwalifikowaniu wyniku zadania D jako błąd i obsługę powrotu do nadrzędnego procesu przez zdarzenie końcowe Błąd przechwytywane w nadrzędnym procesie przez krawędziowe zdarzenie Błąd o odpowiadających parametrach. Przerywające zdarzenia krawędziowe zatrzymuje realizację zadania (podproces) i poprzez przepływ wyjątku przekazuje znacznik do pośredniego zdarzenia rzucającego „Sygnał” którego docelowym zdarzeniem jest zdarzenie początkowe nieprzerywające ”Sygnał” Podprocesu sterowanego zdarzeniem Obsługa kompensacji. Zostają wykonane dwa pośrednie zdarzenia rzucające Kompensacja uruchamiające czynności kompensujące w podprocesie oraz przekazanie znacznika normalnym przejściem do następnego zadania (nr 25). Ostatecznie instancja procesu wyższego poziomu jest kończona wykonaniem końcowego zdarzenia „Błąd”.

Rysunek 8. Oczekiwana ścieżka procesu najwyższego poziomu (wariant1)

Rysunek 9. Oczekiwana ścieżka podprocesu (wariant 1)

Rysunek 10. Historia wykonania proces wyższego poziomu (wariant2)

Rysunek 11. Historia wykonania podprocesu obejmującego kompensowane zadania (wariant 2)

W trzecim przypadku, pozwalającym na zachowanie idempotencji podprocesu, następuje uruchomienie kompensacji zawartych w nim zadań C i D analogicznym podprocesem sterowanym zadaniem Obsługa Kompensacji umieszczonym w podprocesie a instancja podprocesu kończy się zdarzeniem Koniec bez żadnego komunikatu. W tym wariancie wykonanie procesu wyższego poziomu kończy się normalnie a krawędziowe zdarzenie Błąd jest przerywane.

Rysunek 12. Historia wykonania procesu wyższego poziomu (wariant 3)

Rysunek 13. Historia wykonania podprocesu (wariant 3)

Przykład 3 Zdarzenia krawędziowe​

Zarządzanie czasem wykonania zadania pozwala zarówno na wykrywanie występujących opóźnień realizacji zadań jak i daje możliwość reakcji z wyprzedzeniem na zagrożenie opóźnienia. Ten drugi przypadek, który zachodzi wielokrotnie tam gdzie czas wykonania jest krytyczny, jest użytecznym rozwiązaniem.

Rysunek 14. P3-Zdarzenie krawędziowe „Stoper”

Rysunek 14 jest przykładem właśnie takiego modelu w którym wykorzystujemy zadanie Użytkownik o krytycznym czasie wykonania. Przekroczenie tego czasu jest równoznaczne z niepowodzeniem wykonania instancji zadania prowadzącym do natychmiastowej jej zakończenia z sygnalizacją Błąd.

Możemy rozważyć kilka prawdopodobnych wariantów wykonania tego procesu, które pokazują Rysunek 15 do 17. W pierwszym wariancie wykonania wystąpiła sytuacja, w której mimo podjętej interwencji (Zadanie C) nadzorowane zadanie nie zostało rozpoczęte. Stało się to mimo ostrzeżenia przekazanego do zadania C przez nieprzerywające zadania krawędziowe Stoper.

Rysunek 15. Historia wykonania zdarzeń krawędziowych Stoper wariant 1

Upływ czasu spowodował, że przekroczono czas krytyczny zadania B czego efektem było przekazanie znacznika poprzez przepływ wyjątku do zdarzenia końcowego Błąd kończącego proces.

Rysunek 16. Historia wykonania zdarzeń krawędziowych Stoper wariant 2

Drugim wariantem wykonania procesu (Rysunek 16) było przekazanie ostrzeżenia o potencjalnym złamaniu ograniczeń czasowych przez nieprzerywające zdarzenie krawędziowe Stoper do zadania C w którym podjęto zakończone sukcesem działania zapobiegawcze. W rezultacie zadanie B było kontynuowane i uniknęło opóźnienia krytycznego a proces zakończył się normalnie.

Również w trzecim wariancie wykonania (Rysunek 17) proces zakończył się normalnie przechodząc oczekiwaną ścieżkę ponieważ nie przekroczono czasu żadnego z krawędziowych zdarzeń „Stoper” nadzorujących wykonanie zadania B.

Rysunek 17. Historia wykonania zdarzeń krawędziowych Stoper wariant 3

Przykład 4 Podproces sterowany zdarzeniem​

Przykład modelu procesu obejmującego Podproces sterowany zdarzeniem przedstawia Rysunek 18. Proces wykonuje zadania Użytkownik A i B oraz, jeżeli spełnienie warunku pozwoli na przekazanie znacznika, kończy oczekiwaną ścieżkę zdarzeniem Koniec (End). Wprowadzenie do grafu procesu zdarzeń Warunek o nazwie Warunek1 i Warunek2 pozwoliło na ręczne sterowanie przebiegiem procesu.

Zdarzenie Warunek1 jest nieprzerywającym zdarzenie początkowym Podprocesu Ewaluacja eskalacji i jest ustawiany na wartość true wyrażeniem BPQL dostępnym w ramach mechanizmu monitorowania procesów. Zdarzenie Warunek2 jest ustawiane w trakcie uruchamiania instancji procesu jako parametr wchodzący. Aby pozwolić na przejście do końca ścieżki po wykonaniu zadania B wartość zdarzenia Warunek2 ustawiono na true.

Wykonano proces w dwóch krokach; krok1 (Rysunek 19) jest wykonaniem oczekiwanej ścieżki procesu. Proces został zakończony prawidłowo a dane wykonania, istotne dla pokazania zależności czasowe czynności procesu, pokazano dla zdarzenie Koniec (Stop). W tym kroku proces przeszedł oczekiwaną ścieżką, która została zakończona końcowym zdarzeniem Koniec.

Po zakończeniu oczekiwanej ścieżki procesu uznano wynik procesu za błędny i wykonano krok2 poprzez uruchomienie Podprocesu sterowanego warunkiem (Warunek1). Podproces zawiera poza zadaniem D pośrednie zdarzenie rzucające Kompensacja uruchamiające czynność kompensującą C odwracającą wyniki zadania B. Instancja procesu została zakończona przez końcowe zdarzenie rzucające Błąd.

Rysunek 18. Definicja procesu z podprocesem sterowanym warunkiem i kompensacją

Rysunek 19. Wykonanie procesu (Rysunek 18) – krok 1

Rysunek 20. Wykonanie procesu (Rysunek 18) – krok 2

Podprocesy sterowane zdarzeniami (ang. Event subprocess) są pośrednio powiązane ze strukturą przepływów procesu i są modelowane jako niezależny podgraf procesu rozpoczynający się jednym z dopuszczalnych zdarzeń początkowych. Zdarzenia początkowe mogą inicjować wykonanie kolejnych zadań współbieżnie do grafu głównego procesu, z którego nastąpiło odwołanie. Innym rodzajem zdarzeń początkowych podprocesu są zdarzenia przerywające, których wystąpienie powoduje przerwanie przetwarzania we wszystkich innych ścieżkach procesu.

Po zakończeniu przetwarzania Podprocesu sterowanego zdarzeniem nie jest możliwy powrót do struktury przepływów okalającego go procesu. Podproces jest zamykany zdarzeniem końcowym rzucającym do pośredniego zdarzenia krawędziowego otaczającego go Procesu/Podprocesu. Przykład modelu, który przedstawia Rysunek 21, zawiera oczekiwaną ścieżkę procesu jako szereg zadań A,B lub A,B,E w przypadku wystąpienia wyjątku (ang. exception), przy czym wynik zadania B może być odwrócone przez czynność kompensująca C.

Nieprzerywający Podproces sterowany zdarzeniem Eskalacja zawiera jedno zadanie (D) i może się zakończyć albo zdarzeniem końcowym „Błąd” albo zdarzeniem końcowym „Koniec”.

Rysunek 21. Proces obejmujący podproces sterowany zdarzeniem

Historia graficzna wykonania procesu pokazuje przetworzenie ścieżki A B E oraz zadania D w podprocesie Ewaluacja eskalacji, który zakończył się odwróceniem wyniku zadania B i rzuceniem błędu.

Rysunek 22. Obsługa zdarzenia Eskalacja

Przykład 5 - Iteracje​

Przypadek iteracyjnego sterowania wykonaniem ścieżki procesu nawiązuje do Bramki sterowanej zdarzeniami prezentując możliwość iteracyjnego wykorzystania takiego elementu modelu procesu. W definiowaniu bramki można wykorzystać wszystkie rodzaje zdarzeń typu pośrednie rzucające oraz odpowiadające im zdarzenia typu pośrednie przechwytujące. Rysunek 23 prezentuje model procesu zawierającego bramkę sterowaną zdarzeniami wykonywaną iteracyjnie (w tym przypadku występują dwie iteracje) a Rysunek 24 obrazuje historię wykonania tego fragmentu procesu.

Rysunek 23. Model procesu iteracyjnego sterowania ścieżką grafu procesu

W modelu procesu zaproponowano w ramach iteracji dwa alternatywne wykonania fragmentu grafu procesu zawierające odpowiednio zadania C i D uruchamiane przez pary zdarzeń Sygnał. Przebieg iteracji zależy od kolejno uruchamianych zdarzeń rzucających a wybór zdarzenia zależy od ustawienia wartości globalnej zmiennej procesu $iteracja. Łatwo zauważyć podział modelu na dwa podgrafy, jeden stanowiący oczekiwaną ścieżkę procesu obejmującą zadania <Start, A, C|B> i drugi sterujący wykonaniem iteracji poprzez zdarzenia.

Taki wzorzec projektowy, dzięki możliwością wykorzystania reguł wykonania procesu tworzonych w oparciu o BPQL i sieciowy model wiedzy procesu dostępny w ramach ontologii procesu (model Topic Maps), może na przykład służyć do sterowania wykonaniem planu projektu dowolnego typu poprzez odpowiednie mapowania jego harmonogramu (wykres Gantt) na graf procesu.

Rysunek 24. Historia wykonania iteracyjnego procesu wyboru ścieżki

Przykład 6 - Praca grupowa​

Przykładem pracy grupowej może być typowa dla zarządzania procesami badawczymi procedura tworzenia i publikacji wyników prac naukowych. Utrzymanie wymaganej jakości prac naukowych zależy nie tylko od autorów opracowań ponieważ w kolejnych etapach procesu wydawniczego angażuje się inne osoby występujące w różnych wyspecjalizowanych rolach.

Model procesu wydawniczego, który przedstawia Rysunek 25, jest modelem procesu pracy, w notacji BPMN 2.02, który automatyzuje koordynację i nadzór nad współpracą autorów publikacji z jej recenzentami, redaktorami technicznymi oraz osobami podejmującymi ostateczną decyzję o publikacji dzieła.

Rysunek 25. Model procesu sterującego pracą grupową – procedura „Wydania publikacji”

Publikacja prac naukowych, choć rządzi się ścisłymi prawami w zakresie procedury, wynikającej z ogólnych zasad współpracy specjalistów występujących w różnych rolach, przebiega zawsze według przyjętej metodyki narzucającej między innymi kolejność wykonywania poszczególnych jej etapów.

Dodatkowym wymiarem koordynacji jest konieczność dobierania do poszczególnych ról, takich jak na przykład recenzent czy akceptujący, osób reprezentujących odpowiednią wiedzę dziedzinową. Tutaj istotnym wsparciem dla platformy docuRob®WorkFow jest sieć powiązań pomiędzy osobami współpracującymi w projektach badawczych. Taki model powiązań jest elementem ontologii procesu wydawniczego modelowanego w oparciu o notację Topic Maps w module docuRob®OntologyManager.

Utrzymanie kolejności realizacji poszczególnych etapów jest automatyczne i przebiega zgodnie z przyjętym procesem. Można to zauważyć w obu grafach historii wykonania procesu (Rysunek 26 i Rysunek 27). Pod symbolami zdarzeń typu Warunek na tle zielonym mamy liczby wskazujące na kolejność wystąpienia poszczególnych zdarzeń. Grafy historii wykonania pokazują odpowiednio pełny i częściowy przebieg procesu.

Rysunek 26. Graf historii procesu pracy grupowej – wariant 1

Przewidziano również wprowadzenie dodatkowego wymiaru automatyzacji przez integrację procesu z systemem LLM (ang. Large Language Model) wspierające prace na etapie ich tworzenia i oceny. Możliwość sterowania dostępnością wsparcia modelem LLM wynika z decyzji modelowanej przez odpowiedni warunek (zdarzenie typu Warunek) poprzedzający automatyczną czynność integrującą system LLM z procesem wydawniczym.

Rysunek 27 pokazuje wariant wykonania dla którego dopuszczono korzystanie z pomocy Korekta LLM wyłącznie na etapie Recenzji poprzez odpowiednie ustawienie zdarzenia Dostępny LLM.

Rysunek 27. Graf historii procesu pracy grupowej – wariant 2