Workflow - zaawansowane możliwości

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

2. {$__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

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.

Przykład

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);