dotyczy wersji 2016.1.x; autor: Jacek Język

Wstęp

W wersji 2016 WEBCON BPS wprowadzona została funkcjonalność Reguł Biznesowych pozwalających na tworzenie uniwersalnych wyrażeń i warunków sterujących zachowaniem procesów.

Reguły można tworzyć przy pomocy graficznego edytora reguł, przeciągając metodą drag-and-drop odpowiednie elementy z dostępnego przybornika.

Edytor reguł biznesowych pozwala również na korzystanie ze stałych, atrybutów formularza, wartości wprowadzanych bezpośrednio w edytorze oraz z innych reguł zwracających wartość. W ten sposób można konstruować złożone wyrażenia operujące na wszystkich tych wartościach.

Utworzone reguły można wykorzystywać w warunkach określających widoczność i edytowalność atrybutów formularza, widoczność ścieżki przejścia na kroku, w warunkach decydujących o uruchomieniu akcji, jako warunek wyboru ścieżki na kroku „Sterowanie obiegiem” czy też jako reguła zwracająca wartość domyślną atrybutu.

Wynikiem wykonania reguły jest konkretna wartość zwracana przez regułę. Może być to tekst, liczba, wartość logiczna, data lub lista użytkowników.

W zależności od miejsca użycia reguły oraz wyrażenia zdefiniowanego w regule należy skonfigurować właściwy zwracany typ danych. Jeśli reguła ma wyliczać datę wówczas zwracany typ danych powinien być również ustawiony jako Data.

Silnik reguł biznesowych pozwala na pewną swobodę konfiguracji zwracanego typu danych i automatycznie konwertuje wartości różnych typów pomiędzy sobą. Niemniej konfiguracja poprawnego typu danych ułatwia szybką diagnozę i wykrywanie potencjalnych przypadkowych błędów w konstruowanych regułach. W trakcie wykonywania reguły silnik weryfikuje poprawność formatu zwracanej wartości z ustawionym typem danych i informuje użytkownika w przypadku wykrycia niezgodności. Z tego powodu taki sposób konfiguracji jest mocno zalecany.

W regułach biznesowych dostępny jest tryb edycji SQL, pozwalający na definicję wyrażeń przy pomocy języka SQL lub CAML.

Jest to funkcjonalność analogiczna do funkcjonalności dostępnej w poprzednich wersjach systemu WEBCON BPS, gdzie wyrażenia logiczne można konstruować właśnie przy pomocy tych języków skryptowych. Tryb SQL nie będzie opisywany w poniższym artykule. Podkreślę tu jedynie fakt, że tryb SQL oraz tryb Reguł biznesowych działają niezależnie w stosunku do siebie co oznacza, że zmiana trybu działania z jednego trybu na drugi, nie powoduje konwersji wyrażenia stworzonego w jednym trybie na wyrażenie w trybie drugim.

Przydatne ułatwienia edytora reguł

Użyteczną funkcjonalnością edytora reguł biznesowych jest możliwość przetestowania zdefiniowanego wyrażenia bez konieczności uruchamiania całego procesu. W ten sposób możliwa jest szybka weryfikacja utworzonej reguły i sprawdzenie czy działa ona zgodnie z założeniami.

 

W poniższym przykładzie utworzona została reguła weryfikująca całkowitą wartość zamówienia (ilość zamówionego towaru pomnożona przez wartość jednostkową). Jeśli wartość zamówienia przekracza zdefiniowaną wartość maksymalną (wartość maksymalna zdefiniowana jako stała procesowa) wówczas reguła zwraca wartość logiczną „true”.

Uzupełnienie ID elementu w kontekście którego wykonany będzie test i naciśnięcie przycisku „Pokaż” spowoduje pobranie wartości z elementu o podanym ID i wstawienie ich w wyrażenie.

Naciśnięcie przycisku „Testuj” spowoduje uruchomienie reguły i wyświetlenie zwracanej przez regułę  wartości.

Warto zwrócić również uwagę, że wszystkie funkcje dostępne w przyborniku edytora reguł posiadają pomoc kontekstową zawierająca krótki opis działania funkcji wraz z przykładem użycia. Funkcjonalność na pewno będzie pomocna dla osób rozpoczynających pracę z edytorem reguł.

Jeśli w trakcie edycji wyrażenia, z jakiegoś powodu zajdzie konieczność zmiany operatora na inny (np. operatora porównania), taka zmiana może być szybko wykonana bez konieczności przebudowywania całego wyrażenia. Wystarczy z menu kontekstowego wybrać nowy operator by został on wstawiony do wyrażenia.

 

Definiowanie podstawowych typów danych

Przy pomocy edytora reguł biznesowych w prosty sposób można definiować wartości wykorzystywane np. w konfiguracji atrybutu jako jego wartość domyślna. Zasady według których należy definiować wartości określonych typów, dotyczą generalnie edytora reguł biznesowych i odnoszą się do wszystkich wyrażeń tworzonych przy pomocy edytora reguł.

Od wersji 2016.1.1.104 edytor rozpoznaje składnie i formatuje wartości w następujący 
sposób:

L.ba zmiennoprzecinkowa (kolor niebieski)

Data (kolor żółty)

Tekst (kursywa, nie wymaga apostrof)

Liczba

By zdefiniować liczbę wystarczy w edytorze reguł wprowadzić wymaganą wartość, bez podawania separatorów tysięcy oraz jakichkolwiek innych znaków. Definicja liczby zmiennoprzecinkowej wymaga użycia kropki jako separatora ułamkowego, jako separatora nie można używać przecinka.

Tekst

Definicja wartości tekstowej wewnątrz reguły wymaga użycia apostrofu na początku oraz na końcu definiowanego tekstu.

Od wersji 2016.1.1.104 edytor rozpoznaje składnie i nie wymaga apostrof

Data

Reguły biznesowe pozwalają na zdefiniowanie daty w formacie ISO 8601, niemniej możliwe jest również wprowadzenie daty w następujących formatach: YYYY-MM-DD, MM/DD/YYYY. Definiując wartość daty w jednym ze wspieranych formatów nie ma konieczności używania apostrofu na początku oraz na końcu definiowanego tekstu

Jeśli data w regule biznesowej przekazywana ma być w innym formacie, należy skorzystać z operatora konwersji TEXT TO DATE, który pozwala swobodnie przekształcać tekst na datę w dowolnym formacie. Należy zwrócić uwagę, że w tym przypadku zarówno datę jak i format według której data będzie konwertowana, należy wprowadzić jako tekst a więc używając apostrofu.

Wartość Tak / Nie

Wartości typu prawda / fałsz można definiować w dwojaki sposób. Jedną z możliwości jest wprowadzenie wartości true lub false bezpośrednio w oknie edycji reguły. Inną możliwością jest użycie predefiniowanej stałej POSITIVE (prawda) lub NEGATIVE (fałsz) dostępnej w drzewie podpowiedzi edytora reguł. Obie notacje są prawidłowe i ostatecznie dają ten sam efekt jeśli chodzi o działanie reguły, dlatego mogą być stosowane zamiennie.

 

Poprawne używanie zmiennych reprezentujących Daty oraz Liczby zmiennoprzecinkowej

Reguły biznesowe, o czym była już mowa wcześniej, jednoznacznie interpretują wartości dat oraz liczb zmiennoprzecinkowych. Z tego też powodu wartości dat oraz liczb zmiennoprzecinkowych muszą być definiowane w określony sposób i być przekazywane w konkretnym formacie.

W przypadku daty (mimo że dopuszczalne są też inne formaty) zalecanym formatem definiowania wartości jest ISO 8601. Przykład daty w tym formacie to „2017-07-30T14:50”.

W przypadku liczby zmiennoprzecinkowej jedynym możliwym formatem jest liczba bez separatorów tysięcy, z kropką jako separatorem ułamkowym. Przykładem takiej liczby jest „12500.89”.

Oczywiście reguły biznesowe mogą korzystać z wartości dostępnych na formularzu skąd muszą być one również odczytane w poprawnym formacie. By było to możliwe atrybut daty posiada zmienną „ISO (Data Czas)” reprezentującą format ISO

 

natomiast atrybut liczby zmiennoprzecinkowej posiada zmienną „(liczba)” reprezentującą liczbę we właściwym formacie

 

Takie podejście uniezależnia działanie reguł biznesowych od ustawień regionalnych witryny Share Pointa w kontekście której działa system, a tym samym od zmienności formatu dat i liczb dla różnych regionów świata.

Oczywiście jeśli z jakiegoś powodu wymagane jest przekształcenie wartości na tekst w innych formatach można tego dokonać. W tym celu należy skorzystać z dedykowanej funkcji konwersji daty do dowolnego formatu tekstowego

 

lub funkcji przekształcającej wartość liczbową na tekst. Konwersja odbywa się wówczas do formatu zgodnego z ustawieniami regionalnymi witryny SharePoint.

 

Operacje na wartościach różnych typów

Edytor reguł biznesowych pozwala na tworzenie złożonych wyrażeń przy wykorzystaniu operatorów arytmetycznych, logicznych oraz dedykowanych funkcji. Na przykładzie operacji sumowania wyjaśnione zostaną zasady działania silnika reguł biznesowych, sposób konwersji różnych typów danych oraz sposób interpretacji wartości atrybutów.

 

Wszystkie operatory oraz funkcje edytora reguł biznesowych wymagają podania wartości określonego typu (tekst, liczba), również wartość zwracana przez te funkcje jest konkretnego typu. W pewnych przypadkach (przykład operacji sumowania) funkcja pozwala na podanie wartości w dowolnym formacie ale wówczas jej działanie zależy od użytego typu danych. Zobaczmy na przykładach w czym tkwi różnica w działaniu silnika reguł biznesowych.

Sumowanie dwóch liczb da w efekcie ich sumę arytmetyczną.

 

Niemniej podanie tych samych liczb w formacie tekstu (użycie apostrofów) spowoduje, że operator sumy połączy ze sobą dwa teksty.

 

Głębszego wyjaśnienia wymaga sytuacja w której jeden z argumentów jest podany w formie tekstu, natomiast drugi z nich jest liczbą. W takim przypadku efekt sumowania zależał będzie od wartości podanych argumentów.

Jak już wcześniej wspomniano, silnik reguł biznesowych dokonuje automatycznej konwersji wartości jednego typu na inny typ danych jeśli taka konwersja jest konieczna i możliwa. W poniższym przykładzie tekst zawierający liczbę zostanie przekształcony na liczbę a ostatecznie w wyniku dodawania zwrócona zostanie suma dwóch liczb.

Opisane zachowanie silnika ma szczególne znaczenie w przypadku korzystania w regułach biznesowych ze zmiennych reprezentujących wartości atrybutu formularza, zwłaszcza w przypadku liczb. Atrybut typu liczba zmiennoprzecinkowa posiada kilka zmiennych reprezentujących jego wartość.

 

W zależności od użytego typu zmiennej (tekst lub liczba) wynik działania operacji będzie różny. By to zademonstrować posłużę się atrybutem Wartość, który jest liczbą i zawiera wartość zamówienia. Użycie zmiennej typu (liczba) spowoduje, że w efekcie sumowania dwóch wartości otrzymam wynik 12000.

Używając dla tego samego atrybutu zmiennej typu wg ustawień SharePoint (tekst), która zwraca wartość w postaci tekstowej, wynikiem sumowania jest połączony tekst.

 

Jak widać, w obu przypadkach efekt działania operatora sumy jest diametralnie różny. Dzieje się tak dlatego, że w pierwszym przypadku silnik reguł biznesowych jako parametry do obliczeń otrzymał format liczbowy wartości a w drugim reprezentację tekstową tej samej wartości. W efekcie czego zachowanie silnika było inne (suma arytmetyczna lub połączenie tekstu).

Na powyższym przykładzie widać jak ważne jest zrozumienie zasad rządzących sposobem interpretacji i konwersji typów przez silnik reguł biznesowych.

Tworzenie warunków

Konstruowanie warunków przy pomocy edytora reguł biznesowych wymaga użycia operatora IF THEN dostępnego w przyborniku edytora w grupie Funkcje / Wybór warunkowy. Operator IF THEN pozwala na tworzenie warunków zawierających wiele poziomów decyzji. Aby dodać kolejny poziom warunku wystarczy kliknąć w ikonę „plus”.

W przypadku wielu poziomów warunki sprawdzane są kolejno, jeden po drugim, do momentu spełnienia któregoś z warunków. Jeśli żaden z warunków nie będzie spełniony wówczas reguła zwróci wartość zdefiniowaną jako ELSE.

Kolejność warunków można zmieniać, przesuwając je w górę lub w dół drzewa, klikając ikony strzałek.

Należy pamiętać, że zarówno operator IF THEN jak i operatory porównania (<, >, <=, >=, =, <>) czy logiczne (AND, OR, NOT) wymagają by ich parametrem wejściowym była wartość logiczna (POSITIVE, NEGATIVE).

Silnik reguł biznesowych automatycznie konwertuje wartości jednego typu na inny, jeśli taka konwersja jest możliwa. W przypadku gdy wymagane jest podanie wartości logicznych (POSITIVE, NEGATIVE) również przeprowadzana jest taka konwersja. Konwersja taka odbywa się według zasad opisanych poniżej.

 

Tekst – wartość logiczna

Jako wartość POSITIVE (prawda) traktowany jest tekst ‘true’ (nie ma znaczenia wielkość znaków) oraz tekst ‘1’.

Jako wartość NEGATIVE (fałsz) traktowany jest tekst ‘false’ (nie ma znaczenia wielkość znaków) oraz tekst ‘0’.

Każdy inny tekst (np. ‘Kategoria’) zawsze jest interpretowany jako NEGATIVE (fałsz).

 

Liczby – wartość logiczna

Jako wartość POSITIVE (prawda) traktowana jest wartość 1.

Jako wartość NEGATIVE (fałsz) traktowana jest wartość 0.

Każda inna liczba poza 0 lub 1 (np. 100), wprowadzona w miejscu, w którym wymagana jest wartość logiczna spowoduje błąd wykonania reguły.

Data – wartość logiczna

Data nigdy nie jest przekształcana na wartość logiczną. Wprowadzenie daty w miejscu, w którym wymagana jest wartość logiczna spowoduje błąd wykonania reguły.

 

Reguły z parametrami oraz reguły zagnieżdżone

Korzystając z reguł biznesowych istnieje możliwość wielokrotnego używania tej samej definicji reguły w wielu miejscach projektowanego procesu. Zbiór już zdefiniowanych reguł dostępny jest w przyborniku edytora reguł skąd można je wybrać i użyć wprost jako np. warunek widoczności atrybutu lub też skorzystać z istniejącej reguły tworząc nową, rozbudowaną regułę. W ten sposób tworzyć można bardzo złożone wielopoziomowe wyrażenia oparte na istniejących regułach.

 

Pomocną cechą przy tworzeniu uniwersalnych, reużywalnych reguł biznesowych jest możliwość zdefiniowania parametrów, które pozwalają na przekazywanie do reguły konkretnych wartości.

 

Zobaczmy jak w praktyce skorzystać z opisanych możliwości na przykładzie procesu zapotrzebowania w którym przy pomocy reguły biznesowej weryfikowana jest kwota zamówienia.

Tworzenie reguły rozpoczynamy od zdefiniowania parametru „Kwota do akceptacji”

Następnie w edytorze reguł tworzymy wyrażenie weryfikujące czy wartość przekazana w parametrze jest mniejsza od progu decydującego o tym, czy kwota wymaga czy tez nie wymaga akceptacji zarządu. Należy zwrócić uwagę, że próg akceptacji nie jest podany na stałe lecz jest wyliczany przez inną regułę o nazwie „Kwota wymagająca akceptacji”.

Z tak stworzonej i zapisanej reguły można skorzystać wielu miejscach procesu. Reguła będzie między innymi określać wymagalność atrybutu „Opinia przełożonego”, który musi zostać uzupełnione jeśli wymagana jest akceptacja zarządu. W tym celu reguła jest osadzana w konfiguracji widoczności atrybutu na kroku. Jako parametr reguły przekazany jest atrybut formularza o nazwie „Wartość” przechowujący całkowita wartość zamówienia.

W efekcie działania opisanego przykładu, przełożony będzie zmuszony uzupełnić „Opinię przełożonego” jeśli wartość zamówienia zapisana w atrybucie „Wartość” przekroczy próg wyliczany przez regułę „Kwota wymagająca akceptacji”.