Masowe przesuwanie dokumentów

dotyczy wersji: 8.2.x, autor: Kamil Nędza

Czyli jak jednym kliknięciem przesunąć elementy wielu obiegów

Proces bardzo często składa się z wielu wzajemnie ze sobą powiązanych obiegów. Najprostszą relacją są podobiegi, będące obiegiem podrzędnym w stosunku do „rodzica”. Główny obieg reprezentujący jakiś model biznesowy może posiadać wiele podobiegów, a te kolejne podobiegi. W efekcie mogą istnieć dziesiątki zarejestrowanych dokumentów. W przypadku gdy przyjdzie zaprojektować mechanizm do sprawnego zaktualizowania lub zmodyfikowania (np. anulowania wszystkich na raz), z pozycji głównego dokumentu nadrzędnego, może się okazać, że zadanie to nie jest takie trywialne. W niniejszym dokumencie przedstawione zostaną dwa podejścia do tego zagadnienia.

 

Opis przykładowego procesu oraz oczekiwanej funkcjonalności:

W procesie istnieją 3 obiegi. Obieg Projektu, który jest obiegiem głównym. Dla niego startowane są obiegi podrzędne – Obiegi Wykonania. Jeden Obieg projektu może mieć wiele powiązanych obiegów (podobiegów). Dla Obiegów Wykonania startowane są kolejne Obiegi Zadań – analogicznie Obieg Wykonania może mieć wiele Obiegów Zadania. Poniżej przedstawione są schematy graficzne obiegów, które posłużą dla przykładu.

Rys.1. Schemat graficzny Obiegu Projektu

Rys.2. Schemat graficzny Obiegu Wykonania

Rys.3. Schemat graficzny Obiegu Zadania

 

W istniejącym procesie zostanie wdrożone rozwiązanie, które pozwoli za pomocą przejścia ścieżką przejścia na poziomie projektu (na krokach pośrednich projektu) anulować projekt, wraz ze wszystkimi powiązanymi bezpośrednio i pośrednio dokumentami.

Niezależnie od obranej strategii działania, najpierw należy utworzyć ścieżki techniczne, niewidoczne dla użytkowników, służące do anulowania dokumentu. W tym celu, na każdym kroku, z którego ma istnieć możliwość anulowania dokumentu, należy utworzyć ścieżkę prowadzącą do kroku anulowanych dokumentów. W przedstawionym przykładzie należy utworzyć 5 takich ścieżek na krokach: „Rejestracja”, „Pierwszy etap wykonania” i „Drugi etap wykonania” Obiegu Wykonania oraz „Rejestracja” i „Wykonanie zadania” Obiegu Zadania.

Rys.4. Przykład dodania ścieżki przejścia na kroku „Rejestracja” Obiegu Zadania

 

Ścieżki powinny mieć odznaczoną opcję walidacji poprawności i wymagalności. Zabezpieczy to system przed zwróceniem błędu w przypadku gdy na obiegach zależnych nie będą uzupełnione atrybuty wymagane na kroku.

Rys.5. Konfiguracja ścieżki przejścia $_Anuluj_$

 

Nie zapomnij ukryć utworzonych ścieżek przejścia, aby uniemożliwić użytkownikowi ich użycia z poziomu formularza:

Rys.6. Przykład ograniczenia widoczności ścieżki przejścia

 

Gdy ścieżki przejścia zostały dodane i ukryte, a wymagalność atrybutów odznaczona, należy przystąpić do konfiguracji akcji przesuwającej obiegi zależne.

 

Podejście pierwsze – dokładne wskazanie ścieżek:

Jednym ze sposobów może być dokładne wskazanie dokumentów i ścieżek przejścia którymi obieg ma przejść. W kroku, na którym dostępna ma być możliwość anulowania dokumentów tworzymy ścieżkę przejścia:

Rys.7. Dodanie ścieżki anulującej projekt z wszystkimi obiegami zależnymi

 

Na utworzonej ścieżce przejścia należy podpiąć akcję przesuwającą obiegi:

Rys.8. Dodanie akcji przesuwającej obiegi

 

W konfiguracji akcji przesuwającej obiegi tworzymy zapytanie SQL, które wprost zdefiniuje w zależności od kroku w jakim się znajduje dany dokument, jaką ścieżką przejścia ma przejść dany dokument:

Rys.9. Zapytanie zwracające dane w konfiguracji akcji przesuwającej obiegi

 

Należy pamiętać o tym, że każda ścieżka przejścia na każdym kroku ma inny identyfikator. Podczas konfigurowania należy zwrócić szczególną uwagę, żeby przypadkiem nie użyć kilkukrotnie tej samej ścieżki przejścia:

Rys.10. Widok konfiguracji w trybie zaawansowany

Powyższe rozwiązanie jest skuteczne wyłącznie przy małej ilości obiegów.  Jednak może okazać się bardzo czasochłonne, gdy zamiast 2 obiegów zależnych jest ich 10, a każdy z nich ma wiele kroków. Skonfigurowanie odpowiedniego zapytania może być bardzo czasochłonne, a dodatkowo bardzo łatwo o pomyłkę.

 

Podejście drugie – rekursywne wskazanie wszystkich dokumentów:

W drugim podejściu zmienione zostanie zapytanie SQL, wykorzystywane w  konfiguracji akcji przesuwającej obiegi. Zamiast wprost wskazywać kroki i ścieżki przejścia, wykorzystana zostanie rekursywna tabela SQL, która będzie zawierała wszystkie dokumenty powiązane (pośrednio i bezpośrednio) z Obiegiem Projektu. Zapytanie zwracające rekursywną tabelę wygląda następująco:

Rys.11. Zapytanie zwracające dane w konfiguracji akcji przesuwającej obiegi z wykorzystaniem tabeli rekursywnej

 

W użytym przykładzie niezbędne jest aby ścieżki przejścia, którymi będą przechodziły anulowane obiegi zależne, miały tę samą nazwę, oraz, żeby na każdym z kroków z wyłączeniem kroków końcowych, istniała dokładnie jedna ścieżka o danej nazwie. W tym przypadku są to ścieżki „$_Anuluj_$”.  Powyższe wymagania podyktowane są tym, że zapytanie opiera się na odnalezieniu ID ścieżki na podstawie jej nazwy.

 

Weryfikacja funkcjonalności:

Niezależnie od obranego podejścia, efekt działania będzie ten sam – obieg projektu, wraz z obiegami powiązanymi zostaną anulowane. Przykładowy zarejestrowany obieg projektu wraz z powiązanymi dokumentami wygląda następująco:

Rys.12. Widok formularza Obiegu Projektu przed przejściem ścieżką przejścia „Anuluj cały projekt”

Rys.13. Widok formularza Obiegu Projektu po przejściu ścieżką przejścia „Anuluj cały projekt”

 

Podsumowanie:

Oba przedstawione podejścia są skuteczne, jednak należy pamiętać o ich ograniczeniach. W przypadku gdy wprost definiowane jest którą ścieżką przejścia należy przejść dla danego kroku, należy mieć na uwadze, że w przypadku rozbudowanych procesów, konfiguracja akcji przesuwania obiegów może być bardzo czasochłonna. W przypadku drugiej metody, należy zadbać z kolei o unikalność nazwy ścieżki na każdym z kroków, oraz aby nazwa ta była identyczna na wszystkich krokach.

Przedstawiony mechanizm może mieć szereg innych zastosowań. Za jego pomocą można np. zmieniać wartości atrybutów na obiegach powiązanych lub na żądanie w każdym z obiegów z zadaniem wysłać maila z przypomnieniem do osób które mają zadania. Należy tylko mieć na uwadze, że nie można przesuwać bardzo dużych ilości dokumentów na raz. W przypadku gdy ilość powiązanych dokumentów liczona nie jest w dziesiątkach, a setkach należy zadbać o dodatkowe zabezpieczenie w postaci ograniczenia ilości jednocześnie przesuwanych dokumentów.