Stałe i Reguły Globalne – Skonfiguruj raz, używaj cały czas!

Facebooktwitterpinterestlinkedinmail
Dotyczy wersji 2019.1; autor: Kamil Nędza

1. Wstęp

Pracując na co dzień w WEBCON BPS warto poświęcić kilka chwil na przygotowanie w konfiguracji systemu WEBCON BPS grupy uniwersalnych stałych i reguł globalnych. Czas poświęcony na ich stworzenie szybko się zwróci wraz z tworzeniem kolejnych procesów. W niniejszym artykule przedstawione zostanie kilka praktycznych przykładów wykorzystania:

  • Stałych globalnych
  • Globalnych reguł biznesowych
  • Globalnych reguł formularza

2. Stałe globalne

Poniżej przedstawiono pomysły na uniwersalne zastosowanie stałych globalnych.

2.1. Mail prefix

W przypadku wysyłania do użytkowników komunikatów mailowych, warto w temacie maila dodać stałą globalną, która będzie informowała użytkownika, że otrzymany mail nie pochodzi ze środowiska produkcyjnego. W tym celu można posłużyć się stałą globalną, którą należy dodać w tytule maila. Przykładowo stała będzie zwracać „[TEST MAIL] ” w dla środowisk DEV i TEST. Dla środowiska PROD, stała nie będzie zwracała nic. Stałą można użyć w globalnym szablonie maila oraz akcji wysyłki konfigurowalnego maila.

 

Przykład konfiguracji stałej zwracającej prefix dla tytułu maila
Przykład konfiguracji stałej zwracającej prefix dla tytułu maila

 

Przykładowa konfiguracja tytułu maila może wyglądać w sposób następujący:

 

Przykład konfiguracji akcji wysyłki konfigurowalnego maila
Przykład konfiguracji akcji wysyłki konfigurowalnego maila

2.2. Rodzaj środowiska

Warto utworzyć stałą globalną, która będzie zwracać rodzaj bieżącej instalacji. Może ona posłużyć do sterowania obiegami oraz do konfiguracji wykonywalności akcji. Nie chcesz wysyłać maili do zarządu ze środowiska testowego podczas testów UAT? Chcesz podczas testów nadać uprawnienia dla dodatkowej grupy testerów? Nic prostszego – wystarczy na wykonalności akcji dodać odpowiedni warunek.

 

Przykład konfiguracji stałej zwracającej rodzaj środowiska
Przykład konfiguracji stałej zwracającej rodzaj środowiska

2.3. ID grup SharePoint

W przypadku grup SharePoint, które wykorzystywane są w wielu procesach (np. grupa administratorów IT, grupa testerów) warto identyfikator takiej grupy przechowywać jako stałą globalną.  W dalszej części artykułu pokazane zostanie w jaki sposób taką stałą można wykorzystać.

 

Przykład konfiguracji stałej zwracającej ID grupy SharePoint BPS_WEBCON_ADMIN
Przykład konfiguracji stałej zwracającej ID grupy SharePoint BPS_WEBCON_ADMIN

2.4. Adres witryny

Kolejną stałą globalną, którą warto przygotować, jest bazowy adres witryny. Może on posłużyć do budowania adresów URL dla linków, konfiguracji akcji lub może być wykorzystany w preinstalowanych funkcjach SQL (np. dbo.isUserInSPGroup).

Przykład konfiguracji stałej zwracającej adres witryny
Przykład konfiguracji stałej zwracającej adres witryny

2.5. Proste funkcje JavaScript – prace serwisowe

W ramach stałej procesowej można zdefiniować również funkcję JavaScript, która następnie będzie wykonywana na formularzu workflow. Przykładowo zdefiniowana została funkcja JavaScript, która po otwarciu formularza, wyświetla użytkownikowi komunikat o prowadzonych pracach, a następnie przekierowuje go do strony głównej.

Przykład konfiguracji stałej zawierającej kod JavaScript
Przykład konfiguracji stałej zawierającej kod JavaScript

 

Stałą należy umieścić w sekcji reguł uruchamianych na otwarcie formularza.

 

Przykład konfiguracji zachowania formularza
Przykład konfiguracji zachowania formularza

 

Działanie formularza widoczne jest na poniższym zrzucie ekranu. Po kliknięciu OK, użytkownik zostanie przekierowany do strony głównej portalu WEBCON BPS.

 

Formularz po otwarciu w przeglądarce
Formularz po otwarciu w przeglądarce

 

3. Reguły biznesowe

Poniżej opisane zostało kilka przykładowych reguł biznesowych, które mogą usprawnić twoją pracę. Gdy używasz reguł pamiętaj, że w przypadku zwracanego typu danych boolean, nie musisz jawnie zwracać true lub false. Wystarczy sam warunek. Dwie poniższe reguły biznesowe są tożsame:

 

Obie reguły zwracają ten sam rezultat

Obie reguły zwracają ten sam rezultat
Obie reguły zwracają ten  sam rezultat

3.1. IsProd

Prosty przykład na regułę, która zwraca informację, czy bieżące środowisko jest środowiskiem produkcyjnym. Regułę można stosować np. do konfiguracji warunków wykonalności akcji (integracja z systemami zewnętrznymi, wysyłka konfigurowalnych maili itp.). W regule posłużono się stałą globalną, która została przedstawiona wcześniej w ramach bieżącego artykułu.

 

Konfiguracja reguły biznesowej IsProd
Konfiguracja reguły biznesowej IsProd

3.2. Przeliczanie kursu walut na PLN

W przypadku potrzeby częstego przeliczania kursów walut w wielu procesach warto przygotować w tym celu dedykowaną globalną regułę biznesową. Przykład konfiguracji takiej akcji znajduje się na poniższych zrzutach ekranu. Pamiętaj, że aby reguła działała w sposób prawidłowy, niezbędne jest uprzednie włączenie i uruchomienie synchronizacji kursów walut w konfiguracji serwisu.

 

Konfiguracja reguły biznesowej służącej do przeliczania walut na PLN
Konfiguracja reguły biznesowej służącej do przeliczania walut na PLN

 

Na powyższym screenie widać po prawej stronie zakładkę z parametrami. W regule użyte zostały trzy parametry. Są one wykorzystywane w zapytaniu SQL. Parametry umożliwiają wywoływanie skonfigurowanej reguły w wielu miejscach z różnymi danymi, zapewniając jej wielokrotne zastosowanie.

 

Zapytanie SQL służące do wyliczenia kwoty w PLN na konkretny dzień
Zapytanie SQL służące do wyliczenia kwoty w PLN na konkretny dzień

 

Poniżej znajduje się przykładowe wywołanie reguły wraz z jej rezultatem. W realnych zastosowaniach jako parametry należy użyć zmienne zwracające wartości z formularza obiegu dokumentów.

 

Rezultat przetestowania utworzonej reguły biznesowej
Rezultat przetestowania utworzonej reguły biznesowej

3.3. Istnienie załącznika na formularzu

Jedną z najczęściej występujących akcji w elektronicznym obiegu dokumentów jest akcja weryfikująca istnienie załącznika w elemencie workflow. Nie dziwi więc fakt, że proces konfiguracji takiej akcji warto zoptymalizować. Poniżej zaprezentowano konfigurację reguły biznesowej, która weryfikuje, czy na bieżącym elemencie workflow znajduje się załączony plik. Przedstawiona reguła jest najbardziej ogólna, jednak autor zachęca do poeksperymentowania i rozszerzenia reguł biznesowych o nowe możliwości, np. wskazania konkretnego rozszerzenia pliku (kolumna ATT_FileType).

 

Konfiguracja reguły biznesowej służącej do weryfikacji istnienia załącznika
Konfiguracja reguły biznesowej służącej do weryfikacji istnienia załącznika
Zapytanie SQL służące do weryfikacji istnienia załącznika
Zapytanie SQL służące do weryfikacji istnienia załącznika

3.4. Pobranie wszystkich użytkowników grupy SharePoint

Czasami niezbędne jest pobranie wszystkich użytkowników z konkretnej grupy SharePoint. W tym przypadku również można posłużyć się regułą biznesową. Poniżej znajduje się przykład konfiguracji reguły biznesowej, która zwraca listę wszystkich użytkowników wybranej grupy SharePoint.

Konfiguracja reguły biznesowej służącej do pobrania użytkowników grupy SharePoint
Konfiguracja reguły biznesowej służącej do pobrania użytkowników grupy SharePoint

 

Zapytanie SQL służące do pobrania użytkowników grupy SharePoint
  Zapytanie SQL służące do pobrania użytkowników grupy SharePoint

 

Rezultat przetestowania utworzonej reguły biznesowej
Rezultat przetestowania utworzonej reguły biznesowej

3.5. Wykorzystanie kalendarza dni roboczych

Po uprzednim skonfigurowaniu kalendarza dni roboczych (o którym więcej poczytać można tutaj: https://kb.webcon.pl/kalendarz-dni-roboczych-w-webcon-bps/) warto przygotować reguły, które będą zwracały interesujące nas informacje. Dla przykładu mogą to być reguły zwracające informację czy dana data jest dniem roboczym, lub ile dni roboczych występuje pomiędzy wskazanym zakresem dat.

Na pierwszy ogień idzie reguła zwracająca informację, czy wskazany dzień jest dniem roboczym:

 

Konfiguracja reguły biznesowej służącej do weryfikacji czy wskazana data jest dniem roboczym
Konfiguracja reguły biznesowej służącej do weryfikacji czy wskazana data jest dniem roboczym

 

Zapytanie SQL służące weryfikujące czy dany dzień jest dniem roboczym
Zapytanie SQL służące weryfikujące czy dany dzień jest dniem roboczym

 

Rezultat przetestowania utworzonej reguły biznesowej
 Rezultat przetestowania utworzonej reguły biznesowej

 

W przypadku obiegów gdzie wyliczana jest liczba dni roboczych (np. proces urlopowy), niezastąpiona okazuje się przygotowana do tego celu reguła. Poniżej znajduje się przykład reguły, która zwróci liczbę dni roboczych we wskazanym zakresie dat. W przypadku gdy data początku i końca są takie same, reguła zwróci 1 lub 0, w zależności czy dany dzień jest dniem roboczym.

Konfiguracja reguły biznesowej służącej do wyliczenia ilości dni roboczych
Konfiguracja reguły biznesowej służącej do wyliczenia liczby dni roboczych

 

Zapytanie SQL zliczające dni robocze w podanym zakresie dat
Zapytanie SQL zliczające dni robocze w podanym zakresie dat

 

Poniżej znajdują się dwa przykładowe rezultaty testowania reguły biznesowej. W Polsce nowy rok jest dniem wolnym od pracy, więc w podanym zakresie dat, występuje wyłącznie jeden dzień roboczy – 2 stycznia 2019.

 

Rezultat przetestowania utworzonej reguły biznesowej
Rezultat przetestowania utworzonej reguły biznesowej

 

Oczywiście nic nie stoi na przeszkodzie, aby używać innych reguł biznesowych jako parametrów utworzonej reguły globalnej. Poniżej przykład przetestowania reguły, zwracana jest liczba dni roboczych w nadchodzącym miesiącu od dnia dzisiejszego. Test odbył się 2. kwietnia 2019, a dni 22. kwietnia i 1. maja są dniami wolnymi.

 

Rezultat przetestowania utworzonej reguły biznesowej
Rezultat przetestowania utworzonej reguły biznesowej

 

Autor sugeruje, że można utworzyć dodatkowo więcej reguł związanych z kalendarzem dni roboczych. Pomocna może okazać się np. reguła zwracająca najbliższy dzień roboczy po X dniach roboczych od wskazanej daty.

 

4. Reguły formularza

WEBCON BPS pozwala także na definiowanie globalnych reguł formularza. Poniżej autor przedstawia proste przykłady, które mogą usprawnić codzienną pracę osoby tworzącej procesy.

4.1. Warunkowa weryfikacja wpisania komentarza

Za pomocą jednego checkboxa w konfiguracji ścieżki przejścia można wymusić wymagalność komentarza. A co w przypadku, jeżeli wymagalność uzupełnienia komentarza chcemy uzależnić od wartości na formularzu? Do tego celu można stworzyć globalną regułę formularza, która zwróci informacje czy komentarz jest uzupełniony.

Uwaga: Opisana funkcjonalność jest wspierana wyłącznie na formularzu classic.

 

Konfiguracja reguły formularza do weryfikacji uzupełnienia komentarza
Konfiguracja reguły formularza do weryfikacji uzupełnienia komentarza

 

Tak przygotowaną regułę można używać np. na ścieżce przejścia. Przykład wywołania znajduje się poniżej.

W tym konkretnym przypadku, jeżeli wniosek jest odrzucony i nie jest wpisany komentarz, wyświetlony zostanie alert, oraz formularz pozostanie w bieżącym kroku. W przeciwnym wypadku, element przejdzie ścieżką przejścia do kolejnego kroku.

 

Przykład użycia reguły formularza IsCommented
Przykład użycia reguły formularza IsCommented

 

Zachowanie formularza przy przejściu ścieżką przejścia odrzuconego wniosku bez uzupełnionego komentarza
Zachowanie formularza przy przejściu ścieżką przejścia odrzuconego wniosku bez uzupełnionego komentarza

4.2. Wyróżnienie atrybutu w określony sposób

W ramach reguł formularza można zdefiniować formatowania atrybutów, które będą używane we wszystkich procesach. Dzięki temu w ustandaryzowany sposób można zwrócić uwagę użytkownika na kluczowe na formularzu dane. Poniżej znajduje się przykład uniwersalnych reguł formularza, które dla przekazanego w parametrze atrybutu zastosują odpowiedni styl.

 

Konfiguracja reguły formularza dla pozytywnego wariantu
Konfiguracja reguły formularza dla pozytywnego wariantu

 

Konfiguracja reguły formularza dla negatywnego wariantu
Konfiguracja reguły formularza dla negatywnego wariantu

 

Powyżej zostały zdefiniowane dwie reguły formularza – dla pozytywnego i negatywnego wariantu. Zmiana koloru tła atrybutu sygnalizuje z jakim wariantem mamy do czynienia.

Poniżej znajduje się przykład użycia tak przygotowanej reguły formularza. W przypadku jeżeli wniosek został zaakceptowany, to tło atrybutu z kwotą będzie zielone. Jeżeli wniosek zostanie odrzucony, to tło będzie czerwone.

 

Przykład użycia reguły formularza
Przykład użycia reguły formularza

 

Efekt gdy nie dokonano akceptacji
Efekt gdy nie dokonano akceptacji

 

Efekt dla akceptacji pozytywnej
Efekt dla akceptacji pozytywnej

 

Efekt dla braku akceptacji
Efekt dla braku akceptacji

 

5. Podsumowanie

Stałe globalne oraz globalne reguły są potężnym narzędziem w codziennej pracy z WEBCON BPS. Opisane przykłady są jedynie wierzchołkiem góry lodowej. Chętnie usłyszymy od was, jakie są wasze pomysły na codzienną optymalizację pracy w WEBCON Designer Studio. Podzielcie się nimi z nami w komentarzach!