Nintex Workflow – tworzymy nowy proces

Zgodnie z zapowiedzią, w dzisiejszym artykule zaprezentowane zostanie tworzenie nowego procesu. Za przykład posłuży nam mocno uproszczony obieg wniosku urlopowego.

Rodzaje akceptacji

SharePoint w połączeniu z Nintex Workflow oferuje kilka możliwych podejść do kwestii przepływów akceptacyjnych. Pierwszym z nich jest użycie normalnego dokumentu lub zbioru dokumentów oraz manipulacja uprawnieniami i metadanymi takimi jak status. W przypadku użycia innego produktu Nintex – Nintex Forms, istnieje możliwość dodania dodatkowych przycisków akcji (np. Zaakceptuj) na formularzu edycji pisma. Alternatywnie można po prostu ustawiać taką wartość w trakcie edycji.

Drugim (preferowanym) podejściem do przepływów akceptacji jest użycie mechanizmu zadań. SharePoint oferuje możliwość personalnego przydzielania czynności do wykonania w formie bytu nazywanego zadaniami. W trakcie budowania obiegu możemy przykładowo dodać krok tworzący zadanie oraz zdefiniować jego treść i adresata/adresatów. Zadania w kontekście obiegów w SharePoint są zasadniczo prośbą o weryfikację i akceptację lub odrzucenie danego dokumentu.

Planowanie przepływu

Rozpoczynając pracę nad automatyzacją procesu, powinniśmy już na początku określić, jakie dane będą przetwarzane, jacy aktorzy (uczestnicy procesu) będą w nim występować oraz scenariusz biznesowy w formie schematu lub opisu przepływu. Na potrzeby dzisiejszego wpisu przyjmiemy wersję bardzo podstawową:

Dane: Uzasadnienie, Termin urlopu, Status wniosku

Aktorzy: Wnioskodawca, Przełożony

Scenariusz przepływu:

1. Użytkownik składa wniosek urlopowy do akceptacji Przełożonego.

2a. Przełożony akceptuje wniosek.

3a. Informacja o akceptacji zostaje przekazana Wnioskodawcy – zostaje wysłane powiadomienie email.

2b. Przełożony odrzuca wniosek.

3b. Informacja o odrzuceniu zostaje przekazana Wnioskodawcy – zostaje wysłane powiadomienie email.

4. Zakończenie procesu.

Posiadając wstępne założenia, możemy utworzyć  listę lub bibliotekę dokumentów(w zależności od potrzeb) oraz wyposażyć ją w niezbędne kolumny. Mając przygotowany kontener oraz plan, możemy zabrać się za tworzenie pierwszej wersji naszego procesu w Nintex Workflow.

Akcje jako kroki procesu

Głównym, a właściwie jedynym elementem budowlanym procesu w Nintex Workflow są przedstawione w poprzednim artykule akcje. Stanowią one „szablon” zaprogramowanych działań, które w trakcie przebiegu procesu będą wykonywane zgodnie ze zdefiniowaną kolejnością. Warto zaznaczyć, że owy „szablon” jest w bardzo dużej mierze parametryzowalny, a co za tym idzie, może spełnić znacznie więcej funkcji, bądź być wykorzystany inaczej niż sugerowałby to jego opis. Wszystko zależy od inwencji osoby tworzącej proces.

Aby zrealizować opisany we wcześniejszej sekcji scenariusz, będziemy potrzebowali co najmniej akcji wymienionych tabeli poniżej.

Nazwa	Opis	Ikona
Request approval	Akcja odpowiedzialna za delegowanie zadań na użytkowników systemu. Oprócz samej konfiguracji sposobu i odbiorcy zadania, daje ona również zdefiniowania treści oraz użytkowników, którzy otrzymają związane z nią powiadomienia.
Update list item	Akcja umożliwia aktualizację metadanych na procesowanym elemencie.
Send notification	Akcja służy do wysyłania powiadomień mailowych.
Log in history list	Akcja pozwala na utworzenie spersonalizowanego zapisu w historii przepływu procesowanego elementu.
End workflow	Akcja finalizuje przepływ.
Action set	Kontener służący do grupowania innych akcji. Zgrupowanie akcje można później zapisać jako „Snippet”, możliwy do użycia w innym przepływie. Action set umożliwia również wymuszenie realizacji zawartych w nim akcji jako twórca przepływu (wyższe uprawnienia).

Zestawy akcji

Na początku warto zacząć tworzenie przepływu od dodania elementu Action set.

W głównym oknie konfiguracji mamy możliwość jedynie wyboru nazwy, która przy przepływach bardziej złożonych pomoże nam zlokalizować odpowiedni kawałek przepływu, który wymaga dodatkowych poprawek lub korekt. Dodatkowo, istnieje możliwość włączenia/wyłączenia wyświetlania jego zawartości zwiększając czytelność całego schematu.

Naciśnięcie przycisku Common przenosi nas do okna „konfiguracji zaawansowanej”, umożliwiającej m.in. zdefiniowanie komunikatu logowanego po zakończeniu wykonywania Action setu, czy też wspomniane wcześniej ustawienie wykonania Action setu z użyciem uwierzytelnień użytkownika tworzącego przepływ.

Statusowanie

Realizowany scenariusz zakłada 3 możliwe do uzyskania stany procesu oraz stan początkowy „Utworzony”, który jest ustawiany domyślnie przy tworzeniu elementu na liście. Stany (statusy) ustawiane będą za pomocą akcji Update list item, której konfiguracja przedstawiona jest na poniższym zrzucie ekranu.

Akcja posiada bardzo prostą konfigurację. Jedynymi wartościami, które musimy ustawić są:

– element który będzie podlegał modyfikacji (list item, document, itp.),

– modyfikowana kolumna (może zostać wskazana więcej niż jedna).

Nasze akcje zmiany statusu umieszczone zostaną:

– Przekazany do akceptacji –  od razu przed akcją Akceptacji przełożonego,

– Odrzucony – od razu po akcji Akceptacji przełożonego (w razie negatywnego rozpatrzenia),

– Zaakceptowany – od razu po akcji Akceptacji przełożonego (w razie pozytywnego rozpatrzenia).

Logowanie

Akcja Log in history list pozwala na tworzenie wpisów w historii danego przepływu, powiązanej z procesowanym elementem. Jest to główny mechanizm, które przy odpowiednim użyciu pozwoli użytkownikowi zachować pełną świadomość, na jakim etapie jest aktualnie proces.

Konfigurując akcję mamy możliwość wpisania własnego tekstu, jak również dodania referencji do metadanych, skonfigurowanych referencji lub utworzonych w trakcie przepływu zmiennych tymczasowych.

Dobrą praktyką jest logowanie każdego istotnego dla procesu kroku, a w fazie developmentu –  dosłownie każdego miejsca, którego nie jesteśmy pewni na 100%. Może to później oszczędzić nam wielu zbędnych poszukiwań „na oślep”.

Akceptacja

Kolejnym krokiem, który bezwarunkowo musi pojawić się w naszym procesie, jest wysłanie prośby o akceptację osoby decyzyjnej. Po przeciągnięciu akcji na diagram, pierwszym, co rzuca się w oczy jest fakt, że diagram został rozdzielony na dwie części – Approved i Rejected. W zależności od wyniku akcji proces będzie podążał dalej tylko jedną ścieżką. Poniższy zrzut przedstawia okno konfiguracji akcji Request approval.

Akceptacja w Nintex Workflow posiada szerokie możliwości konfiguracyjne. Możemy ustawić tylko jednego/wielu odbiorców, grupę AD lub SP, tryb „głosowania”, itp. Zarówno pole dotyczące opisu zadania, jak też lista decydentów zawiera możliwość odwołania się do referencji, takiej jak Manager ustawiony w Active Directory czy Autor wniosku (zrzut ekranu). Dodatkowo określamy nazwę zadania, które pojawi się na liście zadań osoby akceptującej oraz termin, do którego powinna zostać podjęta decyzja.

Oprócz konfiguracji podstawowej, użytkownik tworzący przepływ może również sformułować własne notyfikację w dwóch kategoriach na:

– Task Notification – dotyczące przydzielonego zadania,

– Not Required Notification – informujące o tym, że akceptacja nie jest już konieczna (np. w przypadku, gdy zaakceptować wniosek musi tylko jedna osoba).

Użytkownik może w tym miejscu określić nadawcę, zdefiniować ewentualne kopie wiadomości, utworzyć dynamicznie generowany temat wiadomości (również przy użyciu relacji) oraz jej treść.

Odpowiednio skonfigurowany Nintex pozwala również na akceptację wniosku poprzez tzw. LazyApproval, czyli akceptację poprzez naciśnięcie przycisku zamieszczonego w mailu, lecz nie jest to już temat na dzisiejszy artykuł.

Powiadomienia mailowe

Akcja Send notification, w przeciwieństwie do notyfikacji wysyłanych w akcji Request approval, może być bezwarunkowo dodana w każdym miejscu procesu. Możemy w niej skonfigurować w większości takie same parametry jak przy prośbie o akceptację, czyli Adresata, Adresata kopii, Nadawcę, Treść wraz z referencjami do zmiennych.

Składamy i publikujemy

Grupując i ustawiając opisane powyżej akcje w odpowiedniej kolejności, otrzymamy schemat procesu podobny do zamieszczonego na zrzucie ekranu obok.

Rzućmy okiem, w jaki sposób przekłada nam się to na zakładany proces:

Posiadając potencjalnie gotowy proces, ostatnim krokiem dzielącym użytkowników SharePoint ze skorzystania z naszego dzieła jest jego zapis i publikacja. W Nintex Workflows funkcjonują wersje minor (0.1, 0.2, etc.) oraz major (1.0, 2.0). Po standardowym zapisie tworzona jest wersja minor, natomiast przy publikacji – major.

Aby opublikować przepływ, należy nacisnąć przycisk Publish oraz uzupełnić wyświetlony formularz zapisu zawierający pola przeznaczone na Tytuł, Opis procesu oraz opis zmian wprowadzonych w wersji. Warty zaznaczenia jest fakt, że dzięki wersjonowaniu możemy nie tylko cofnąć się do dowolnej kopii archiwalnej, ale również dokończyć aktywne przepływy nawet wtedy, gdy nowy został już opublikowany i jest w użyciu.

Jazda próbna

Po opublikowaniu, przepływ dostępny będzie do użytku uprawnionych użytkowników. W zależności od ustawień mogą to być użytkownicy z pełną kontrolą na liście lub z uprawnieniami Contribute. Temat uprawnień zostanie dokładniej poruszony w jednej z kolejnych części – na razie przejdźmy jednak do wypróbowania przepływu.

Nasz proces rozpoczynany jest utworzeniem wniosku. Jak widać na zrzucie załączonym powyżej, pismo przyjmuje zaraz po utworzeniu status „Utworzony” – wynika to z konfiguracji listy. Aby uruchomić opublikowany wcześniej przepływ, możemy – o ile zostało to skonfigurowane wcześniej – użyć przycisku w menu kontekstowym elementu lub posłużyć się akcjami z ribbona. Jako że menu kontekstowego w tym przypadku nie konfigurowaliśmy, zaznaczamy interesujący nas wniosek, przechodzimy do zakładki Items oraz naciskamy przycisk Workflows.

Naciśnięcie przycisku powoduje wyświetlenie strony zawierającej listę przepływów workflow możliwych do uruchomienia na elemencie oraz historię tych uruchamianych wcześniej.

Aby uruchomić przepływ, należy nacisnąć jego nazwę oraz potwierdzić, naciskając przycisk Start.

Pierwsze efekty przepływu możemy zaobserwować od razu na liście.

Zgodnie ze zdefiniowanym przez nas procesem, wniosek zostaje przekazany do akceptacji oraz uzyskuje status „Przekazany do akceptacji”, natomiast do użytkownika akceptującego zostaje wysłana wiadomość z prośbą o akceptację, której treść zaprezentowana jest na poniższym zrzucie ekranu.

Ustawione w treści akcji referencje zostają uzupełnione wartościami skonfigurowanymi w systemie.

Po naciśnięciu linka użytkownik zostaje przeniesiony na stronę akceptacji wniosku.

Użytkownik akceptujący może w tym miejscu zapoznać się z informacjami na temat wniosku, odczytać załącznik (o ile takowy istnieje), oddelegować zadanie na innego użytkownika decyzyjnego oraz uzupełnić komentarz i zaakceptować/odrzucić wniosek. Przyjmijmy, że użytkownik akceptuje wniosek (wybiera Approved i naciska przycisk OK).

Rezultat tej czynności jest niezwłocznie przekazywany do wiadomości wnioskodawcy za pomocą zdefiniowanej wcześniej wiadomości email, czyli w tym przypadku:

Efekt działania manifestuje się również na liście wniosków urlopowych, gdzie możemy zaobserwować zmianę statusu wniosku na „Zaakceptowany”. Proces jest zakończony.

Podsumowanie

Przedstawiony proces jest bardzo uproszczony i można go udoskonalić o wiele mechanizmów, takich jak przesłanie do ponownej akceptacji, maszyna stanów, która byłaby bardziej podatna na rozwój przepływu czy chociażby konfiguracja odpalania workflow z menu kontekstowego – możliwości jest mnóstwo.

Tworzenie własnych przepływów przy użyciu Nintex Workflows nie jest aż tak skomplikowane, jak mogłoby się to wydawać. Oczywiście, stan pożądany rzadko kiedy udaje się uzyskać przy pierwszej publikacji przepływu i konieczne jest prześledzenie, co i gdzie mogło się nie udać, czyli co należy zmienić. W dużej ilości przypadków sprawnie rozlokowane treściwych logów jest w stanie bardzo pomóc w analizie problemów z przepływami. Jeżeli jednak i to zawiedzie – polecam Sii 😉

Na następną część planowany jest temat logów, uprawnień i kwestii konfiguracyjnych przepływu.

Do następnego!