Potrzeba, która wymaga zaprojektowania przepływu, który równolegle przydziela wiele zadań, wielu grupom użytkowników jest skomplikowana.

W zasadzie w Nintex istnieją dwa podejścia: albo przydzielić zadanie do grupy i czekać aż pierwsza osoba któreś zakończy, albo czekać na wszystkie. Jednak co wówczas, gdy musimy przypisać kilka zadań w tym samym czasie i każde innej grupie użytkowników?

Podejście

Realizując wymóg wielu równoległych zatwierdzań wymaga zatem albo użycia akcji „Parallel Block”, albo… odznaczenia opcji czekania, aż wszystkie zadania zostaną zakończone.

Pierwsze podejście wymusza edycję przepływu każdorazowo, gdy nastąpi zmiana w liczbie grup – poprzez dodawanie lub usuwanie gałęzi. Powoduje to zatem, że funkcjonalność jest dość „sztywna”, zaś przepływ pracochłonny w utrzymaniu.

Drugie podejście jest dużo lepsze. Należy je zbudować korzystając z pętli i w każdym jej obrocie przydzielać zadania innej grupie. Jednak co potem? Co jeśli jednak trzeba zatrzymać przepływ i czekać, aż zadania zostaną zakończone, nim workflow przejdzie do wykonywania kolejnych akcji?

Wymóg ten można zrealizować poprzez zapisywanie wartości ID zadań wygenerowanych w pętli i następnie w kolejnej sprawdzanie, czy zostały zrealizowane.

Jeśli jakieś zadanie zostało zrealizowane, należy je usunąć z kolekcji. Zaś gdy kolekcja będzie pusta, workflow będzie mógł pójść naprzód. Oczywiście, należy także dodać akcję „pauza”, aby pętla nie kręciła się w nieskończoność.

Wyzwania

W obu podejściach obecne są wyzwania, dość trudne do pokonania. W pierwszym wyzwaniem jest budowa przepływu w dość sztywnym modelu. Każda zmiana liczby grup zatwierdzających wymaga zmiany przepływu.

W drugim jest jeszcze gorzej – ponieważ przy każdym obrocie workflow musi sprawdzić dużą liczbę elementów na liście Workflow Tasks i czynność tę powtarzać co 5 minut (lub rzadziej, co jednak nie robi bardzo dużej różnicy). W efekcie tego, bardzo szybko można spotkać się z ograniczeniem (Daily email limit has exceeded and your workflow has been suspended) 5 tysięcy zapytań do SharePoint i workflow się zatrzyma. Wówczas trzeba go ręcznie wznowić kolejnego dnia. No chyba, że…

Wzorzec

Stworzyłem wzorzec, który bierze co najlepsze z drugiego podejścia i umożliwia przepływowi gładką pracę w zgodzie z ograniczeniami. Jak?

Po prostu przeniosłem pracę sprawdzania, czy task został wykonany, na stronę listy z zadaniami przepływu pracy. I maszyny stanów w głównym przepływie.

• Główny workflow przydziela zadania
• Po tym, jak zadania w danej grupie są przydzielone, uruchamia przepływ pracy dla nich, na liście Workflow Tasks. Workflow ten monitoruje stan zakończenia zadania.
• Gdy zadanie zostaje zakończone, workflow zmienia wartość pola elementu, na którym operuje główny workflow, co z kolei powoduje wznowienie działania tego przepływu.
• Gdy główny workflow zostaje wznowiony, sprawdza stan zakończenia zadań z listy. Jeśli jakieś zadania wciąć pozostają niezakończone, workflow ponownie zatrzymuje się i czeka na sygnał z listy zadań.

1. Główny workflow sam musi uruchomić przepływ monitorujący na liście Workflow Tasks. Jest tak, ponieważ zadanie jest tworzone przez system, co nie spowoduje uruchomienia przepływu na zdarzenie „utworzenie elementu”.
2. Główny przepływ musi czekać na zmianę wartości pola sterującego. To się zdarzy, gdy zadanie zostanie zakończone.
3. Po wznowieniu, główny workflow ustawia pierwotną wartość pola sterującego, zatem w sytuacji, gdy na liście zadań nadal będą obecne niezakończone, przepływ ponownie się zatrzyma,
4. Jeśli zadanie zostanie zakończone, powinno zostać usunięte z listy zadań do moniorowania, zatem workflow nie sprawdzi go po raz kolejny.

Przepływ listy workflow tasks

Przepływ jest uruchamiany przez główny workflow. Działa dla każdego zadania, które nie jest jeszcze zakończone (1). Następnie pauzuje (2) do czasu, aż Task Status zadania zostanie zmienione na „Completed”. Po wznowieniu pobiera ID (3) powiązanego elementu (wartość atrybutu „Related Item” jest trzymana w postaci JSON), używając poniższego wyrażenia:

(?<=Id\"\:)(.*)(?=\,"Web)

Następnie pobiera element o indeksie 0 z kolekcji (4) i aktualizuje wartość pola sterującego (5) elementu, na któym działa główny workflow, dzięki czemu ten zostanie wznowiony.

Krótkie podsumowanie

Używając tego podejścia można budować rozwiązania, które równolegle przydzielają zadania do wielu grup zatwierdzających, dzięki czemu można mieć np. 10 równoległych zadań, każde przydzielone do 10 zatwierdzających. Dodatkowo, każde zadanie może mieć ustawione inne warunki ukończenia (czekać na wszystkie, czy tylko pierwszą odpowiedź?).

Bardzo użyteczne i stabline. Sam spróbuj!