Masowe przesuwanie dokumentów

Facebooktwitterpinterestlinkedinmail

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.

1

Rys.1. Schemat graficzny Obiegu Projektu

2

Rys.2. Schemat graficzny Obiegu Wykonania

3

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.

4

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.

5

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:

6

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:

7

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:

8

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:

9Rys.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:

10

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:

11

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:

12

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

13

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.

3 thoughts to “Masowe przesuwanie dokumentów”

  1. Proszę jeszcze o informację co należy uzupełnić w polu ‚ID ścieżki’ na zakładce ‚Parametry’ dla akcji ‚Przesuń obieg (SQL)’.
    Nie da się zapisać akcji bez uzupełnienia tego pola.
    Używam BPS 8.3.1.235

  2. Czy mógłbym prosić o przykład polecenia sql wymuszającego administracyjne zakończenie zadań?

Komentarze są zamknięte.