Przykład tworzenia procesu zadaniowego w WEBCON BPS

Facebooktwitterpinterestlinkedinmail

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ę:

x1
Schemat graficzny obiegu zadania

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:

x2
Matryca atrybutów lewego panelu obiegu zadania
x3
Matryca atrybutów prawego panelu obiegu zadania

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:

x4
Warunek edytowalności atrybutu „Osoba realizująca”

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

x5
Warunek widoczności ścieżki „Zmień Osobę realizującą”

Testowanie obiegu

W tym momencie nasz prosty obieg zadania jest gotowy:

x6
Formularz rejestracji zadania

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ą”).

x7
Formularz na kroku „Realizacja zadania”, gdy nie zezwolono na delegowanie zadania

 

x8
Formularz na kroku „Realizacja zadania”, gdy zezwolono na delegowanie zadania

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:

x9
Schemat graficzny obiegu projektu

 

x10
Matryca atrybutów lewego panelu obiegu projektu

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”:

x11
Dodanie akcji w pasku 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:

x12
Przykład sprawdzania pola w bazie atrybutu „Powiązany projekt”

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ę:

x13
Zapytanie do raportowania zadań na obiegu projektu

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”:

x14
Widok formularza w kroku „Realizacja projektu”

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:

x15
Widok formularza podczas rejestracji zadania z akcji na obiegu projektu

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

x16
Widok formularza w kroku „Realizacja projektu” po zarejestrowaniu kilku zadań

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:

x17
Matryca atrybutów listy pozycji „Zlecenie zadań” obiegu projektu

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.

x18
Nowy atrybut techniczny „_DET_ID startera” na obiegu zadania

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:

x19
Konfiguracja kolumny „Link do zadania”

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.

x20
Konfiguracja kolumny „Status realizacji”

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.

x21
Zapytanie użyte dla kolumn „Nazwa zadania”, „Opis zadania”, „Osoba realizująca”, „Termin realizacji”

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.

x22
Podgląd akcji na ścieżce przejścia „Dodaj zadania” na kroku „Realizacja projektu”

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:

x23
Podstawowa konfiguracja akcji

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:

x24
Dane do startowania obiegów zadań

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

x25
Konfiguracja „Blokuj edycję”

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

x26
Dodawanie nowych zadań w liście pozycji „Zlecanie zadań”

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.

x27
Widok listy „Zlecenie zadań” po przejściu ścieżką przejścia „Dodaj zadania”

 

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.

One thought to “Przykład tworzenia procesu zadaniowego w WEBCON BPS”

  1. Witam
    A jak zablokowac do edycji tylko wybrane pozycje na liście? Np. mam liste składajaca sie z wielu pozycji , wybieram kilka z nich do dalszej obróbki i chcialbym zeby te wybrane pozycje byly zablokowane do czasu kiedy zakoncze obróbkę. Z powyzszego przykładu jak dobrze orientuje się to jest blokowanie wszystkich bierzacych pozycji na liście oprócz nowo dodanych. Ja bym chciał miec stała liste pozycji i blokowac czasowo wybrane pozycje.
    Czy w wersji 2017 w pole Ograniczenie edytowalności moge uzywac sentencji jak w podanym wyzej przykładzie? Z tego co widze to juz nie jest zapytanie SQL.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *