dotyczy wersji 8.3.1.x i wyżej; autor: Kamil Nędza
Uwaga: Opisane w artykule obiegi są obiegami złożonymi i opisanie wszystkich funkcjonalności w jednym artykule nie jest możliwe. Autor w niniejszym artykule przedstawił wyłącznie koncepcję obiegów w celu nakreślenia kontekstu funkcjonalności oraz skupił się na przedstawieniu pewnego wąskiego zakresu, który w głównej mierze dotyczy podobiegów.
Podczas modelowania procesów biznesowych często okazuje się, że jeden obieg dokumentów jest niewystarczający aby w pełni wykorzystać potencjał ludzki i systemowy.
Przyczyn może być wiele:
- Niezbędne zrównoleglenie prac kilku pracowników, gdzie praca na jednym elemencie workflow byłaby kłopotliwa.
- Rozgraniczenie uprawnień do konkretnych informacji dla poszczególnych użytkowników systemu.
- Logiczne podzielenie poszczególnych etapów procesu.
- Utrzymanie hierarchiczności w zaimplementowanym procesie.
- Sprawne zarządzanie i monitorowanie wieloma wątkami procesu.
W poniższym artykule przedstawione zostaną 2 przypadki użycia funkcjonalności WEBCON BPS podobiegów. Po krótkim wprowadzeniu przedstawione zostaną 2 odrębne scenariusze wykorzystania funkcjonalności podobiegów. W pierwszym scenariuszu, od podstaw zbudowane zostanie rozwiązanie, dzięki któremu na formularzu dokumentu będą wylistowane w sposób hierarchiczny i rekurencyjny wszystkie podobiegi oraz ich dalsze obiegi zależne. Drugi scenariusz pokaże wycinek większego systemu, który służy do sprawnego zarządzania akcją marketingową. W scenariuszu omówiony zostanie moduł odpowiedzialny za masowe startowanie podobiegów.
Wprowadzenie:
Domyślnie system wspiera powiązanie dokumentów w relacji dziecko-rodzic. Każdy element workflow może (ale nie musi) posiadać swojego rodzica. Element będący dzieckiem przechowuje identyfikator WFD_ID swojego obiegu nadrzędnego w kolumnie WFD_WFDID.
Rys.1 Zapytanie pokazujące relację dziecko – rodzic
Na formularzu obiegu dokumentów relacja ta również jest pokazana. Można ją odszukać w dolnej części lewego panelu:
Rys. 2. Widok panelu z wylistowanymi obiegami zależnymi i nadrzędnymi
Zależność dziecko-rodzic może mieć także wpływ na logikę workflow. W WEBCON Designer Studio istnieje możliwość dodania specjalnych kroków o typie „Oczekiwanie na podobiegi (systemowy)”, w którym możemy zdefiniować zachowanie elementu będącego rodzicem, w zależności od zachowania podobiegów:
Rys. 3. Okno konfiguracyjne kroku oczekiwania na podobiegi
O zależności tej należy także pamiętać w przypadku tworzenia procesów, gdzie będziemy zezwalać na usuwanie elementów z bazy danych. System nie pozwala na usunięcie elementu jeżeli posiada jakiekolwiek elementy zależne:
Rys. 4. Komunikat w przypadku próby usunięcia obiegu, który posiada podobiegi.
Scenariusz I – Tworzymy hierarchiczny proces zarządzania relacjami z klientem
Opis rozwiązania:
Od podstaw utworzony zostanie proces składający się z trzech obiegów: Klient, Osoba, Kontakt z osobą. Każdy obieg klientów może mieć wiele zarejestrowanych osób. Każda osoba może mieć wiele kontaktów. Z poziomu Klienta widoczna ma być cała struktura w sposób uporządkowany. Efekt końcowy ma być jak na poniższym screenie:
Rys. 5. Widok formularza obiegu Klient
Konfiguracja:
W pierwszej kolejności należy dodać i skonfigurować trzy obiegi o trzech różnych typach dokumentów:
Rys. 6. Widok z WEBCON BPS Studio z typami dokumentów i obiegami dla procesu
Następnie tworzymy startery. Na obiegu Klient utworzono starter obiegu Osoba jako akcja w menu (akcja Odsyłacz):
Rys. 7. Okno konfiguracji akcji startowania nowego obiegu Osoba
Zwróć uwagę na parametr PARENT_WFDID. W parametrze tym przekazywane jest ID, z którego startowany jest obieg. Dzięki temu tworzone jest powiązanie pomiędzy dokumentami. Dokument zostanie zarejestrowany jako element powiązany.
Analogicznie postępujemy tworząc starter obiegu Kontakt na obiegu Osoba:
Rys. 8. Okno konfiguracji akcji startowania nowego obiegu Kontakt
Przykładowy formularz obiegu Osoba, który został wystartowany z nadrzędnego obiegu Klient, który posiada dodatkowo własny podobieg Kontaktu z osobą może wyglądać następująco:
Rys. 9. Formularz obiegu Osoba
Na powyższym zrzucie widać, że element jest dzieckiem elementu C/2016/04/00001 oraz jest rodzicem dla CON/2016/04/00001. Klikając w daną sygnaturę, zostaniemy przekierowani do tego elementu. Należy pamiętać, że dane obiegi mogą mieć niezależnie skonfigurowane uprawnienia, więc pomimo widocznej na formularzu zależności pomiędzy elementami, użytkownik może nie mieć uprawnień do odczytu elementu nadrzędnego. Jeden element może mieć maksymalnie jednego rodzica, ale może posiadać wiele elementów powiązanych (dzieci).
Przechodzimy teraz do dodania atrybutu listującego elementy. W tym celu należy dodać atrybut typu „Tabela danych”. W polu „Zapytanie SQL” wpisujemy zapytanie, które zwróci dane:
Rys. 10. Zapytanie SQL odpowiedzialne za rekurencyjne wyświetlenie danych z systemu workflow
Powyższe zapytanie korzysta z tabeli rekurencyjnej (Common Table Expression). Listuje w formie hierarchicznej wszystkie elementy poczynając od elementu bieżącego oraz rekurencyjnie wszystkie elementy powiązane. Lista składa się z linków. Po kliknięciu, użytkownik zostanie przekierowany do danego elementu. Przy odrobinie finezji i znajomości HTML można dodać własne ikonki dzięki czemu zestawienie może wyglądać następująco:
Rys. 11. Atrybut Tabela SQL listujący elementy
Scenariusz II – Opis startowanie wielu zapytań ofertowych w akcji marketingowej
Opis rozwiązania:
Rozważmy przykładowy proces do prowadzenia akcji marketingowej. Proces składa się z dwóch obiegów. Pierwszy – Obieg Akcji Marketingowej – służący do startowania i monitorowania zapytań marketingowych. Drugi – Obieg Zapytania Marketingowego – jest podobiegiem Obiegu Akcji Marketingowej. Obieg Zapytania Marketingowego służy do wysłania maila z ofertą do klienta w taki sposób, aby odpowiedź od klienta nie była kierowana na wspólną skrzynkę odbiorczą, ale bezpośrednio do opiekuna danego klienta.
Schematy obiegów widoczne są poniżej:
Rys. 12. Schemat graficzny Obiegu Akcji Marketingowej
Rys. 13. Schemat Obiegu Zapytania Marketingowego
Pracownik startuje akcję marketingową. Na liście pozycji wybiera kontrahentów oraz osoby odpowiedzialne. Następnie przechodzi do kroku tworzenia oferty.
Rys. 14. Formularz rejestracji Akcji Marketingowej
Pracownik następnie przechodzi ścieżką przejścia „Oferta utworzona”. System automatycznie, dla każdego zdefiniowanego na liście klienta wystartuje obieg z zadaniem dla osoby odpowiedzialnej. Dodatkowo wysyłany jest na zdefiniowany adres klienta mail wraz z załącznikiem. W polu nadawcy maila wpisywany jest adres osoby odpowiedzialnej, tak aby klient mógł bezpośrednio się skontaktować z odpowiednim pracownikiem.
Rys. 15. Formularz tworzenia oferty
Do podobiegu przekazane zostaną niezbędne informacje, które posłużą do wysyłki maila oraz dla informacji pracownika.
Rys. 16. Formularz Obiegu Zapytania Marketingowego
Po zakończeniu akcji osoba ma możliwość weryfikacji skuteczności akcji marketingowej:
Rys. 17. Przykład zakończonej akcji marketingowej
Konfiguracja:
Na ścieżce przejścia „Oferta utworzona” skonfigurowana jest akcja o rodzaju „Uruchom podobieg (SQL)”. W podstawowej konfiguracji należy wybrać proces i obieg, który ma być startowany. W tym przypadku jest to obieg Zapytania Marketingowego:
Rys. 18. Podstawowa konfiguracja akcji
W przypadku jeżeli okaże się, ze ilość startowanych podobiegów jest na tyle duża (rzędu setek lub dziesiątek), że na formularzu ich ilość wpływa na zmniejszenie czytelności formularza lub ich obecność jest po prostu zbędna, można je ukryć z poziomu globalnego szablonu formularza:
Rys. 19. Możliwe opcje wyboru wyświetlania obiegów powiązanych na formularzu obiegu
Na podstawie zakładki „Podstawowa”, zakładka „Zaawansowana” powinna uzupełnić się automatycznie. Następnie przechodzimy do konfiguracji w zakładce „Dane”. W przypadku, jeżeli nie jest wykorzystywana natywna funkcjonalność zachowania zależności pomiędzy obiegami, warto przekazać identyfikator obiegu nadrzędnego do wybranego atrybutu elementu powiązanego. Na poniższym zrzucie ekranu widać, że identyfikator ten został przekazany do pola WFD_Attchoose3.
Rys. 20. Konfiguracja akcji: Dane przekazywane do podobiegów
Skonfigurowana akcja odpowiada za wystartowanie podobiegu oraz przekazanie do niego zdefiniowanych wartości. Na ścieżce przejścia podobiegu można skorzystać z przekazanych z obiegu startującego danych.
Na ścieżce przejścia „Rejestruj” Obiegu Zapytania Marketingowego skonfigurowana jest akcja „Wyślij konfigurowalny e-mail”. W konfiguracji akcji ustawiono wysyłkę na adres mail przechowywany w atrybucie. Wartość ta przekazywana jest podczas startowania obiegu.
Rys. 21. Konfiguracja akcji wysyłki konfigurowalnego maila
W treści wiadomości wygląda następująco:
Rys. 22. Konfiguracja treści wiadomości
Zwróć uwagę na nadawcę. Dzięki takiej konfiguracji wysłane maile w polu nadawcy będą miały opiekuna danego klienta. Dzięki temu, jeżeli klient będzie zainteresowany kontaktem, będzie mógł bezpośrednio odpisać do pracownika zajmującego się danym klientem.
Ostatnią zakładką jest zakładka „Załączniki”, w której zdefiniowane jest zapytanie SQL, odwołujące się do wszystkich załączników, które zostały dodane w obiegu nadrzędnym (tym który wystartował obiegi Zapytań Marketingowych). Dzięki takiemu podejściu oszczędzana jest powierzchnia dyskowa, ponieważ załącznik fizycznie znajduje się tylko na jednym dokumencie (Akcji Marketingowej) i nie jest wielokrotnie powielany dla każdego z podobiegów.
Rys. 23. Zapytanie zwracające identyfikatory załączników powiązanej akcji marketingowej
Podsumowanie
Podobiegi są funkcjonalnością o bardzo dużym potencjale. Ich poprawna implementacja w procesie biznesowym może zrównoleglić pracę, pomóc w uporządkowaniu procesów, czy zwiększyć czytelność formularza. Zastosowań jest o wiele więcej i nie sposób przedstawić wszystkich. Warto pamiętać, że przedstawione w artykule przykłady to tylko czubek góry lodowej i zastosowania podobiegów są ograniczone w głównej mierze przez pomysłowość administratora systemu.
