Dotyczy wersji: 8.1.x; Autor: Kamil Nędza

Wstęp

Procesy zadaniowe są jednymi z najpowszechniejszych i najczęściej stosowanych obiegów typu WorkFlow. Dobrze zaprojektowany obieg zadania jest w stanie pełnić nieocenioną rolę w procesach biznesowych – od zwykłego zlecenia danemu pracownikowi zadania, poprzez konsultacje, a na użyciu w zaawansowanych obiegach projektowych kończąc. W niniejszym dokumencie przedstawione zostanie jak utworzyć prosty obieg zadania. Następnie utworzony zostanie obieg projektu, w którym zostanie wykorzystany obieg zadania, w taki sposób, aby stworzyć sprawnie działający proces.

Obieg zadania

Założona funkcjonalność obiegu

Tworzymy prosty cztero-krokowy obieg zadania. Zakładamy, że obieg nie ma być skomplikowany i wykonany w sposób intuicyjny dla użytkownika. Pracownik otrzymuje zadanie. Jeżeli nie jest w stanie go wykonać, zwraca je do osoby rejestrującej. Jeżeli osoba rejestrująca na to zezwoli, osoba realizująca zadanie będzie mogła sama przydzielić inną osobę do otrzymanego zadania. Po wykonaniu zadania obieg przejdzie do archiwum. Jeżeli osoba realizująca zadanie wie, że dane zadanie jest niemożliwe do zrealizowania (np. zostało już wykonane, lub po prostu nie jest w stanie go wykonać), może anulować taki dokument. W taki przypadku niezbędne jest podanie przyczyny w komentarzu.

 Tworzenie obiegu

Tworzymy nowy proces. Następnie dodajemy nowy obieg oraz uzupełniamy w nim kroki. Nasz obieg ma następującą strukturę:

W kolejnym etapie tworzymy typ dokumentu, z którym powiążemy nasz obieg, dodajemy atrybuty i ustawiamy ich widoczność na matrycy atrybutów. W obiegu użyte zostało tylko kilka atrybutów, które wydają się być niezbędnym minimum. Każdy obieg może mieć ich więcej w zależności od potrzeb. W naszym przypadku matryca wygląda następująco:

Nasz obieg zadania jest prawie gotowy. Należy jeszcze tylko uzależnić możliwość zmiany osoby realizującej zadanie na kroku „Realizacja zadania” od atrybutu „Zezwalaj na delegowanie zadania”. Realizujemy to w 2 miejscach. Najpierw w zakładce „Uprawnienia” atrybutu „Osoba realizująca” dodajemy zapytanie ograniczające edytowalność. Tworzymy zapytanie, aby na kroku „Realizacja zadania” w przypadku, gdy zaznaczony został checkbox „Zezwalaj na delegowanie zadania” niemożliwa będzie edycja tego atrybutu:

Teraz przechodzimy do konfiguracji widoczności ścieżki „Zmień Osobę realizującą”:

Testowanie obiegu

W tym momencie nasz prosty obieg zadania jest gotowy:

Jak widać na poniższym zrzucie ekranu w momencie, gdy checkbox nie został zaznaczony osoba, która została wyznaczona do realizacji zadania nie ma możliwości samemu zmiany osoby realizującej (atrybut niemożliwy do edycji oraz brak ścieżki „Zmień osobę realizującą”).

 

Obieg Projektu

 Założona funkcjonalność obiegu

Nasz obieg zadania jest gotowy. Chcemy rozbudować system o obieg projektu, w ramach którego będziemy mogli przydzielać zadania do poszczególnych użytkowników. Pokazane zostaną dwa różne podejścia, które w finalnym rozwiązaniu będą mogły działać równolegle, tworząc kompleksowe rozwiązanie. Założenia odnośnie obiegu projektu są następujące – chcemy utworzyć trzy-krokowy obieg składający się wyłącznie z rejestracji, realizacji projektu i archiwum. Na kroku „Realizacja projektu” możliwe będzie przydzielanie zadań do pracowników. Na kroku będzie możliwość monitorowania wszystkich przydzielonych zadań.

 Tworzenie obiegu

Analogicznie jak miało to miejsce dla obiegu zadania zaczynamy od „wyklikania” kroków, ścieżek i niezbędnych atrybutów dla obiegu. Następnie tworzymy nowy typ dokumentu i powiązujemy go z obiegiem i ustawiamy widoczność atrybutów na matrycy. W naszym przypadku obieg wygląda następująco:

 

Prosty obieg projektu jest gotowy. Na razie nie spełnia jeszcze naszych wymagań, ale w dalszej części będziemy dodawać do niego kolejne funkcjonalności.

I etap zmian: Dodawanie zadań AD-HOC – starter zadania w górnej belce

Przechodzimy do konfiguracji kroku „Realizacja projektu”. Dodajemy nową akcję typu „Odsyłacz” na kroku w sekcji „Przycisk w menu”:

Klikamy w przycisk konfiguracji akcji. Tworzymy link, w którym przekażemy odpowiednie parametry do formularza. Jeżeli chcemy przekazać jakąś wartość do atrybutu startowanego obiegu należy, w jakim polu w bazie się znajdują. Można to zrobić np. w BPS Studio:

Parametry w linku przekazuje się po pytajniku oddzielone znakiem ampersanda (&). W naszym przypadku link wygląda następująco:

http://ut08/BPS-81/Zadaniowanie/_layouts/15/webcon/WFDynamic.aspx?WF_ID={WF:4}&DTYPE_ID={DT:4}&PARENT_WFDID={WFD_ID}&AttChoose1={WFD_ID}

Starter obiegu zadania

Przekazanie ID obiegu projektu, jako ID obiegu nadrzędnego

Przekazanie ID obiegu projektu, do atrybutu „Powiązany projekt”

 I etap zmian: Dodanie Tabeli SQL wyświetlającej zlecone zadania

Dodajemy kolejny atrybut typu Tabela SQL. Tabela ma za zadanie pokazywać, kto komu zlecił zadanie, kiedy zostało zlecone, status zadania, nazwę zadania oraz link do danego obiegu zadania. W źródle danych wybieramy „<Domyślne>” i układamy zapytanie SQL. Przykładowe zapytanie może mieć podobną formę:

I etap zmian: Weryfikacja funkcjonalności

Tworzymy obieg projektu i przechodzimy ścieżką „Rejestruj”. Na kroku „Realizacja projektu” w pasku menu dostępna jest utworzona akcja „Dodaj zadanie AD-HOC”:

Po kliknięciu akcji otworzy się formularz rejestracji obiegu zadania. Widać, że automatycznie uzupełniony został atrybut „Powiązany projekt” (przekazanie parametru w linku) oraz „Osoba zlecająca” (wartość domyślna atrybutu). Resztę atrybutów uzupełniono ręcznie:

Po zarejestrowaniu kilku zadań nasz formularz obiegu projektu może wyglądać następująco:

II etap zmian: Masowe startowanie zadań z listy pozycji

Przy złożonych projektach zadań do przydzielenia może być bardzo dużo. Ręczne startowanie i przydzielanie dziesiątek zadań do pojedynczego projektu może być czasochłonne i nieefektywne. Do tego celu można wykorzystać listę pozycji, na której będziemy w stanie jednocześnie zlecać i monitorować zlecone zadania. Najpierw tworzymy taką listę pozycji – „Zlecanie zadań”. Lista będzie składać się z następujących kolumn:

• Osoba zlecająca – pole osoby (automatycznie uzupełniana bieżącym użytkownikiem)
• Osoba realizująca – pole osoby
• Termin realizacji – data
• Nazwa zadania – pole tekstowe
• Opis zadania – wiele wierszy tekstu
• Zezwalaj na delegowanie zadania – checkbox (domyślnie odznaczony)
• Link do zadania – link do obiegu utworzonego zadania
• Status realizacji – lamka przyjmująca 3 kolory informująca o wykonaniu zadania
• Blokuj edycję – kolumna techniczna wykorzystywana do zablokowania danej linii

Taka lista może być automatycznie inicjalizowana predefiniowanym zapytaniem SQL (np. jak wykonywany jest projekt budowy budynku, automatycznie podpowiadały by się zadania związane z uzyskaniem zgody na budowę, wyceną dokumentacji technicznej, wykonaniem zamówień itp). W naszym przypadku pominiemy ten etap.

Po utworzeniu i uzupełnieniu matrycy atrybutów, widoczność poszczególnych kolumn wygląda następująco:

Przed rozpoczęciem konfiguracji kolumn listy pozycji musimy w odpowiedni sposób dodatkowo przygotować obieg zadania. Na podstawie wpisów w liście pozycji będą startowane obiegi zadania i niezbędne jest późniejsze powiązanie danego wpisu z listy pozycji z utworzonym dokumentem. Do tego celu posłużę się unikalnym identyfikatorem bazodanowym list pozycji – kolumną DET_ID tabeli WFElementDetails, w której przechowywane są wszystkie element list pozycji. Dlatego na obiegu zadania należy utworzyć dodatkowy atrybut techniczny „_DET_ID startera”, do którego podczas startowania obiegu przekazywana będzie wartość DET_ID.

Przyjrzyjmy się teraz konfiguracji kolumn „Link do zadania” oraz „Status realizacji”. W konfiguracji obu kolumn użyty został TAG {S:ID} (Subelement ID), który zwraca wartość ID bieżącego wiersza i wykonywany jest w kontekście bieżącej linii formularza. Konfiguracja linku wygląda następująco:

Na powyższym zrzucie widać, że link ma budowę „link:adres_http;displayname:nazwa_wuświetlana”. Dzięki temu możemy zamiast linku możemy wyświetlić np. sygnaturę danego dokumentu zadania. W konfiguracji kolumny „Status realizacji” tryb wyświetlania został ustawiony jako „Lampka”. Tryb ten wyświetla ikonkę w jednym z trzech kolorów w zależności od zwracanej wartości. Dla wartości mniejszych lub równych 0 będzie to czerwona lampka, dla wartości równych 1 będzie to żółta lampka, dla wartości większych od 1 będzie to zielona lampka.

Konfiguracja listy pozycji prawie gotowa. Potrzebujemy jeszcze w zakładce „Uprawnienia” kolumn dodać zapytanie ograniczające edytowalność w zależności od atrybutu „_Blokuj edycję”. Na ścieżce przejścia po utworzeniu zadań, atrybut ten zostanie oznaczony. Dzięki temu po wystartowaniu zadania nie będzie już możliwości edycji tej linii oraz dzięki tej kolumnie będziemy w stanie odróżnić te zadania, które zostały już wystartowane, a które nie.

Na sam koniec niezbędne jest dodanie ścieżki przejścia oraz skonfigurowanie na niej dwóch akcji. Pierwsza będzie odpowiedzialna za wystartowanie zadań dla wszystkich elementów listy pozycji „Zlecanie zadań”, dla których checkbox „_Blokuj edycję” jest odznaczony. Druga z akcji, po wykonaniu się akcji startowania obiegów zadań, zaznaczy wszystkie checkboxy, aby uniemożliwić edycję elementów listy pozycji, które zostały wystartowane. Dodatkowo zabezpieczy przed utworzeniem zdublowanych zadań, w przypadku, gdyby dodano kolejne zadania na liście pozycji.

Przyjrzyjmy się najpierw konfiguracji akcji typu „Startowanie wielu obiegów” o nazwie „Startuj zadania”. W pierwszej kolejności należy uzupełnić podstawowe dane dotyczące, jaki obieg ma być wystartowany:

Następnie przechodzimy do zakładki „Dane”, gdzie należy wprowadzić zapytanie SQL zwracające dane do startowanych obiegów. Dla każdego zwróconego wiersza, wystartowany zostanie osobny obieg. Niezbędne jest, aby kolumny w zwróconym wyniku miały takie same nazwy jak pola tabeli WFElements w bazie SQL. Dobrą praktyką może okazać się komentowanie nazw kolumn, pozwoli to w łatwy sposób znalezienie ewentualnych pomyłek, lub na szybką weryfikację, w przypadku późniejszej chęci rozbudowy funkcjonalności:

Konfiguracja akcji typu „Zmiana wartości listy pozycji” o nazwie „Blokuj edycję” wygląda następująco:

Na powyższym zrzucie widać, że najpierw należy zdefiniować jaką listę pozycji akcja będzie modyfikowała. Następnie rodzaj zmiany – „Aktualizuj wartości” oznacza, że dla zwróconych danych zostaną zmodyfikowane wpisy o danym identyfikatorze. W zapytaniu zwracamy wszystkie DET_ID listy pozycji „Zlecenie zadań” oraz dla każdego DET_ID wartość „1” (kolumna „_Blokuj edycję”).

 II etap zmian: Weryfikacja funkcjonalności

Na kroku „Realizacja projektu” dodano kilka zadań do różnych osób. Po przejściu ścieżką przejścia „Dodaj zadania” zostaną wystartowane zadania dla każdego elementu listy pozycji (w tym wypadku 3).

Jak widać na poniższym zrzucie, po przejściu ścieżką przejścia „Dodaj zadania” dodane zostały zadania. Zadanie nr. 1 zostało wykonane, zadanie nr.2 odrzucone, a zadanie nr. 3 jest wciąż w realizacji. Wszystkie z tych zadań są niemożliwe do modyfikacji. Możliwe za to jest dodanie kolejnych zadań z pozycji listy pozycji.

 

Podsumowanie

WEBCON BPS niewielkim wysiłkiem pozwala stworzyć dobrze działający proces zadaniowy. Dzięki przedstawionemu podejściu dodawanie i wypełnianie zadań jest proste i intuicyjne dla użytkownika. Dodatkowo w przedstawionym procesie można zastosować zaawansowane raportowanie danych. Każdy z użytkowników dostaje konkretne zadanie, dzięki czemu można wyświetlać czas realizacji zadania przez pracownika, porównać wydajność działów oraz w łatwy sposób pozwala na monitorowanie i zarządzanie zadaniami przez koordynatorów projektów.