Przejdź do głównej treści

Workflow

Ready_™ Developer TeamOkoło 4 minut

Procedury workflow

Procedury workflow oparte są o notację BPMN i uwzględniają wszystkie najważniejsze elementy tej notacji. Składają się na nią:

Procedury
Procedury
  1. Początek obiegu
  2. Decyzje (diament powodujący wyświetlenie decyzji dla użytkownika)
  3. Etapy użytkownika (Czynności – bloczki)
  4. Etapy systemowe (Czynności – bloczki)
  5. Akcje
  6. Własności
  7. Przypisania
  8. Dane wejściowe
  9. Koniec
  10. Złączenia (JOIN – w przypadku wymagania spełnienia poprzednich etapów)
  11. Przejścia (strzałki)
  12. Warunki (diament dokonujący ewaluacji warunków SQL)
  13. Pętle multi-instance z podprocesami (etapy ze znakiem +)
  14. Definiowanie czasu na realizację etapu, powiadomienia on opóźnieniach

W elemencie typu etap możemy wyróżnić:

  • Akcje (możliwość wykonywania akcji na początku bądź końcu danego etapu)
  • Dane wejściowe (możliwość pobrania od użytkownika danych różnego typu: znakowe, liczbowe, listy pracowników, listy wyboru pobierane ze słowników kwerendami SQL itp).
  • Właściwości (definiowalne zmienne)
  • Przypisania (możliwość operowania na zmiennych)
Elementy procedury
Elementy procedury

Konfiguracja procedur pozwala tworzyć mapy procesów odnoszące się zarówno do dokumentów jak i spraw. Przykłady wykorzystania dostępne są tutaj: Wykorzystanie procedur

Utworzenie nowej procedury

Aby dodać nową procedurę, klikamy przycisk Nowa w Pasku narzędzi. Następnie, w wyświetlonym formularzu uzupełniamy:

  • Nazwa, gdzie wpisujemy nazwę procesu biznesowego, który modelujemy.
  • Typ procedury wybierając z listy obiekt, dla którego ma być użyta procedura, np. dokument, sprawa
  • Lp (jest wypełniane domyślnie).
  • Właściciel procesu wybierając z listy dział, który ???

Ponadto możemy zaznaczyć opcje:

  • Możliwa do użycia jako podproces – jeśli proces ma być wykorzystany jako podproces w innej procedurze.
  • Zezwalaj na dokonywanie zmian w powiązanym obiekcie – jeśli dopuszczamy modyfikację obiektu, dla którego aktywna jest procedura.
  • Nadaj uprawnienia osobom wykonującym zadanie – jeśli chcemy, aby procedura nadawała uprawnienia do powiązanego obiektu na stałe, a nie tylko na czas trwania etapu.
  • Czy procedura jest aktywna – decydujemy, czy procedura ma być widoczna na liście Procedura na obiekcie.
Definicja procedury
Definicja procedury

Po kliknięciu przycisku OK możemy przejść do rysowania schematu workflow i definiowania procesu.

UWAGA

Ukrycie widoczności procedury na liście jest przydatne zwłaszcza, kiedy wdrażamy nowy proces biznesowy i nie chcemy, żeby procedura kierująca tym procesem była dostępna przed jego uruchomieniem.

UWAGA

panel_sterowania_procedury_01Dane możemy edytować po zaznaczeniu nazwy procedury na liście i kliknięciu przycisku Właściwości w Pasku narzędzi.

Definiowanie procesu

Aby otworzyć graficzny edytor procesu, klikamy dwukrotnie jego nazwę na liście lub zaznaczmy go i klikamy ikonę Edycja w Pasku narzędzi.

W celu dodania elementu na obszar roboczy klikamy go w Pasku narzędzi nad edytorem, po czym klikamy miejsce w obszarze roboczym, w którym element ma się pojawić. Po pojedynczym kliknięciu elementu możemy zmieniać jego wielkość, przesuwać lub usuwać (wciskając klawisz Delete). Po dwukrotnym kliknięciu elementu uruchamiamy edytor definicji elementu.

Do dyspozycji mamy następujące rodzaje bloczków:

Bloczki możemy łączyć za pomocą strzałki, która mówi nam o kierunku przebiegu procesu. Proces zaczynamy od ustawienia bloczku typu start. (W procesie może istnieć tylko jeden taki bloczek.)

Proces może być rozgałęziony, wskutek czego może posiadać wiele bloczków typu Koniec.

Komendy

Komendy mogą być wywoływane na aktywacji lub zakończeniu etapu. Opis komend i lista parametrów

Opis tworzenia własnych komend

Dla zaawansowanych

W workflow biorą udział następujące tabele:

  • procedures_def - tabela procedur - przechowuje informacje o procedurze np. Zatwierdzenie faktury kosztowej
  • stages_def - tabela etapów - przechowuje definicje poszczególnych etapów np. Akceptacja Prezesa
  • stages - instancje etapów - przechowuje informacje o zapisanych etapach konkretnych procesów: spraw, dokumentów
  • proc_actions - akcje powiązane z procedurami lub z etapami, wykonują się przed lub po zapisie np. beforeStageChange
  • action_commands - komendy wykonywane przez system na akcjach - wybierane spośród zawartych w katalogu commands - można dodać parametry, które dodają się do standardowych dwóch Obiektu Akcji oraz obiektu encji powiązanej z wykonywaną akcją np. Dokument albo Sprawa

Wykorzystanie własności, danych wejściowych i przypisań

Potężne możliwości silnika workflow systemu eDokumenty możliwe są między innymi dzięki wykorzystaniu parametrów i zmiennych, które mogą być dynamicznie przetwarzane podczas wykonywania procedury. Dane mogą być pobierane od użytkownika, ale również przetwarzane przez sam workflow.

Do danej wejściowej i własności odwołujemy się (w warunkach lub przypisaniach) poprzez nazwę poprzedzoną znakiem "$" oraz całość zamykamy w nawiasy "{}" (np. {$Akceptant}).

Dane wejściowe

Więcej na te temat możesz przeczytać tutaj

Przypisania

Więcej na te temat możesz przeczytać tutaj

Własności

Własności służą do zdefiniowania dodatkowych atrybutów procedury — można je traktować jako zmienne procedury dostępne we wszystkich etapach, jak również w parametrach akcji (komend).

Najczęściej zdefiniujemy własność, kiedy chcemy, aby nadać jej określoną wartość a później wykorzystywać np. w warunkach do sterowania przebiegiem workflow. Np. Zdefiniujmy własność "Czy jest przedpłata", którą napełnimy wartością zależną od wyniku zapytania SQL. Następnie wykorzystamy tą własność w warunku.

Kilka słów o zmiennych

W zapytaniach SQL można używać następujących wyrażeń, które zostaną zastąpione odpowiednimi wartościami:

  • {PRC_ID} - prc_id sprawy, której dotyczy procedura
  • {DOC_ID} - doc_id dokumentu, którego dotyczy procedura
  • {SOP_ID} - id etapu/czynnności
  • {STAGES.PTSTID} - id definicji etapu

Również zawartości obiektów podlegających workflow sprawy i dokumentu np.:

  • {processes.rspuid} - id osoby odpowiedzialnej za sprawę
  • {documents.adduid} - id osoby tworzącej dokument

W dalszej części umieszczone zostały użyteczne konstrukcje przy budowaniu workflow: Przykłady workflow.

"Magiczne" własności dla procedury

Własności należy najpierw zadeklarować (np. we właściwościach procedury).

  1. {$__orgarrVisible} - (bool) Wartość FALSE spowoduje ukrycie informacji (na panelu workflow) "Do wykonania przez:".

UWAGA

Ustawienie to odnosi się do każdego aktywnego etapu/czynności w procedurze (po wykonaniu danej czynności najpewniej będziemy chcieli przywrócić domyślne ustawienie, czyli pokazać informację o osobach wykonujących).

Przykład: Na START czynności ukrywamy informację o osobach, definiując wartość przypisania tak, aby zwróciło FALSE::boolean.

SELECT array_upper({stages.orgarr}::int[], 1) > 1

Na zakończenie czynności przywracamy widoczność poprzez przypisanie TRUE do {$__orgarrVisible}:

SELECT TRUE
  1. {$__panelColor} - (string) kolor panelu/szarfy workflow (np. #ff0000)

Przykład: Na start przypisujemy np:

SELECT '#e74c3c';

i na koniec etapu

SELECT ''
Kolorowe przyciski

Definiując opcje wyświetlające się na szarfie procedury dla decyzji, możemy skorzystać z kodu kolorów, które wizualnie wspomagają ich interpretację, np. jeśli jakaś decyzja ma charakter negatywny, przycisk będzie czerwony, pozytywne akcje będą zielone. Kolor możemy nadać każdemu przyciskowi po wyborze z listy opcji:

  • Neutralna — przycisk niebieski
  • Pozytywna — przycisk zielony
  • Negatywna — przycisk czerwony
decyzja
decyzja

Optymalizacja i czyszczenie tabeli stages i stages_edges

Jeżeli tabela stages zawiera pokaźną ilość rekordów (np. powyżej 1M) to można usunąć niepotrzebne rekordy z bazy. Poniższe zapytanie usunie wszystkie nieaktywne oraz niezałatwione elementy (czynności, decyzje itp.), dla których cały proces (lub podproces) został już zakończony. W podglądzie procedury zostaną same bloczki zielone (tam gdzie procedura przeszła).

DELETE FROM stages
USING procedures p
WHERE p.procid = stages.procid AND NOT (stages.is_act OR stages.is_fix) AND (p.comple OR p.cancel);

UWAGA!

Na dużych bazach zaleca się najpierw wykonanie count(*) dla podanego zakresu a następnie DELETE z LIMIT 100, aby dokonać estymacji czasu trwania zapytania. Jeśli ma być długie - rozsądnie byłoby go wykonać w screen.

Info

Zapytanie z limitem 10000

DELETE FROM stages where stages.sop_id IN (SELECT stages.sop_id FROM stages
left join procedures p ON (p.procid = stages.procid)
WHERE NOT (stages.is_act OR stages.is_fix) AND (p.comple OR p.cancel) LIMIT 10000)

Procedury z odpiętych dokumentów

DELETE FROM procedures p
WHERE p.ctxcls = 'DOCUMENT' AND p.rootpr = p.procid AND p.procid NOT IN (SELECT procid FROM documents WHERE procid IS NOT NULL AND gostof IS NULL);

Procedury z odpiętych spraw

DELETE FROM procedures p
WHERE p.ctxcls = 'PROCESS' AND p.rootpr = p.procid AND p.procid NOT IN (SELECT procid FROM processes WHERE procid IS NOT NULL);
Copyright © 2024 Ready_™ Developer Team