Decyzje w procesie BPM - tworzenie reguł biznesowych

Reguły biznesowe w BPM to zbiory zasad określających, jak działa proces biznesowy. Definiują warunki, akcje i decyzje, które automatyzują logikę procesów, np. zatwierdzenie wniosku czy obliczenie rabatu. Są one odseparowane od procesu, co ułatwia ich zarządzanie i modyfikację bez zmiany całego modelu.

jBPM oferuje szereg narzędzie do zbudowania reguł biznesowych użytych w procesach - najpopularniejsze z nich to 'Guided Decision Table' oraz 'DMN Decision'.

Data Objects

Data Objects w jBPM to logiczne obiekty danych, które służą do przechowywania i przekazywania danych w procesie. W przeciwieństwie do zmiennych procesowych, Data Objects pozwalają na lepszą organizację danych i ich powiązanie z logiką biznesową na wyższym poziomie abstrakcji. Choć nie są widoczne na diagramie BPMN, ułatwiają modelowanie i analizę przepływu danych w procesie.

Pierwszy ze sposobów na utworzenie decyzji biznesowych wymaga wcześniejszego utworzenia Data Object. Pola (zmienne) które umieścimy w tym obiekcie będą atuomatycznie przeniesione do do formularza procesu. Będąc w oknie procesu kliknij na 'Add Asset' i wybierz 'Data Object (model)'. Nazwij model (uwaga: unikaj zastrzeżonych nazw jak np. 'DataObject'), przypisz Data Object do pakietu projektu i w następnych krokach dodaj pola poprzez wybranie przycisku '+ add field'. Pomiń etykiety dla zmiennych, wprowadź tylko nazwy pol i typy tych zmiennych. Szczegóły Data Object mogą wyglądać jak poniżej:

Formularze

By pola z formularzy trafiały do pol obiektu danych, musisz utworzyć formularz który jest powiązany z Data Object. Wykonaj dwa kroki by utworzyć taki formularz. W pierwszym kroku utwórz zmienną procesu w 'Process Data' => 'Process Variables' wpisując jako name 'ObiektDanychOne' a w Data Type wybierz obiekt ktory utworzyliśmy wyżej (ObiektDanychOne - pakiet projektu). Jeśli klikniesz teraz w oknie diagramu procesu na 'Generate process form' utworzone zostaną automatycznie dwa formularze. Pierwszy formularz bedzie zawierać zestaw pól pobranych z obiektu 'ObiektDanychOne'. To jest formularz źródłowy dla drugiego formularza, formularza który jest formularzem startowym procesu. Formularz startowy procesu będzie wskazywac na 'Nested Form' (formularz z polami powiązanymi z Obiektem Danych). Do takiego typu formularza, Sub Form, możesz oczywiście dodać pola które nie są obecne w Data Object (wystarczy zdefiniować je w zmiennych procesu).

A - Guided Decision Table

Guided Decision Table w jBPM to narzędzie do definiowania reguł biznesowych w formie tabel decyzyjnych. Umożliwia określanie warunków i działań w przyjazny, interaktywny sposób. Reguły mogą być wykonywane przez silnik reguł Drools, a logika opiera się na hit policy. Naszym celem jest stworzenie reguł które pokierują przepływem w procesie akceptacji faktur w zależności od wybranego działu i kwoty faktury.

W oknie projektu kliknij na 'Add asset' i wybierz 'Guided Decision Table'. W pierwszym oknie dialogowym nadaj nazwę obiektowi, przypisz reguły do odpowiedniego pakietu projektu oraz określ 'Hit policy'.

Hit policy w Guided Decision Table w jBPM określa, jak traktowane są reguły, gdy spełnionych jest więcej niż jeden warunek w tabeli decyzyjnej. Najczęściej spotykane polityki to:

Unique – tylko jedna reguła może być spełniona (brak konfliktów).
First Hit – wykonywana jest pierwsza pasująca reguła, pozostałe są ignorowane.
Any – dowolna z reguł może być spełniona, ale wszystkie muszą dawać ten sam wynik.
Rule Order – wszystkie pasujące reguły są wykonywane w kolejności ich wystąpienia.
Collect – wykonuje wszystkie pasujące reguły i zwraca zbiorczy wynik (np. suma, średnia).

Wybór hit policy zależy od logiki decyzyjnej i oczekiwanego wyniku. Wybieramy 'First Hit'. Nie wybieramy opcji 'Wizard' i po kliknięciu na OK pojawi się okno edytora:

Umieszczanie kolumn

W Guided Decision Table w jBPM kolumny służą do definiowania reguł decyzyjnych. Mamy następujące rodzaje kolumn:

Kolumny atrybutów (Attribute Columns):
- Służą do ustawiania właściwości reguły, takich jak:
  - salience (priorytet reguły),
  - no-loop (zapobieganie zapętleniom),
  - duration (czas trwania reguły).
- Przykład: salience = 10.
Kolumny metadanych (Metadata Columns):
- Zawierają dodatkowe informacje o regule, które nie wpływają na jej działanie, ale mogą być użyteczne np. w analizie.
- Przykład: @Author, @Version.
Kolumny warunkowe (Condition Columns):
- Definiują warunki, które muszą być spełnione, aby reguła została uruchomiona.
- Przykład: wiek > 18.
Kolumny akcji (Action Columns):
- Określają akcje do wykonania, gdy warunki są spełnione.
- Przykład: status = 'zatwierdzony'.

1. Atrybuty

Rozpoczynamy od umieszczenia kolumny atrybutów. Kolumna atrybut w Guided Decision Table dla Ruleflow Group pozwala przypisać regułę do konkretnej grupy przepływu reguł. Dzięki temu można kontrolować, które reguły będą wykonane w określonym momencie przepływu procesu (wstawiając obiekt 'Business Rule' wskazujemy która Guided Decision Table będzie źródłem reguł i które reguły określone właśnie atrybutami będą wykonywane) .

Kliknij na 'Insert Column', wybierz opcję 'Include advanced options' a następnie z listy wybierz 'Add an Attribute column'. Kliknij 'Next'. W następnym oknie wybierz atrybut 'Ruleflow-group' i kliknij na 'Finish'. Ruleflow-group to sposób grupowania reguł, które są oceniane w kontekście procesu BPMN. Reguły przypisane do danej grupy zawsze będą oceniane, ale to, czy ich warunki zostaną spełnione, zależy od danych wejściowych i logiki w samej regule. Nazywamy naszą kolumnę-etykietę 'poziom_akceptacji' i ukrywamy ją:

2. Warunki

Dodajemy kolumny z warunkami. Naszym celem jest utworzenie dwóch kolumn z warunkami. Pierwsza kolumna będzie określać który dział a druga definiować poziom wydatków (kwota faktury).

Kolumna dział

Dodajemy warunki. Klikamy na 'Insert Column' => 'Add a Condition'. Klikamy 'Next'. W następnym oknie klikamy na 'Create a new Fact Pattern'. Możemy miec wiele 'Fact Patterns'. Fact Pattern to wzorzec, który określa, który obiekt (fakt) i jego pola będą sprawdzane w regule. Na przykład: "Sprawdź obiekt Person, gdzie age > 18".

Jak widzisz w polu 'Fact type' pojawił się utworzony wcześniej obiekt danych. W polu 'Binding' wpisujemy nazwę, np. 'f1'. Zatwierdzamy 'OK' i klikamy 'Next'. Wybieramy w następnym oknie 'Literal value' i klikamy 'Next'. W następnym kroku wybieramy pole z naszego Data Object, 'dzial'. Klikamy 'Next'. W tym kroku jako 'Operator' wybieramy 'equal to' i zatwierdzamy 'Next'. W następnym oknie w polu 'Value list (optional):' wpisujemy opcje wyboru ktore pojawią się podczas definiowania zestawu warunków - wpisujemy tu działy firmy np. 'it,hr,marketing,serwis,kontroling'. Zatwierdzamy 'Next' i w ostatnim oknie nadajemy etykietę dla tej kolumny, niech będzie to 'dzial'. Klikamy 'Finish'.

Kolumna kwota

Postępujemy jak w powyżej z tym że nie tworzymy nowego 'Fact Pattern' a wykorzystujemy już utworzony (w polu 'Pattern:' wybieramy 'ObiektDanychOne [f]'). Jako operator wybieramy 'greater than'. W liscie wartosci do wybrania możemy wpisać kwoty dla których będziemy definiować warunki różnych poziomów akceptacji. Możemy też pozostawić to pole puste - kwoty wpiszemy później.

Action

Czyli kolumna z akcją do wykonania, gdy warunki są spełnione. Klikamy na 'Insert Column', wybieramy 'Set the value of a field', klikamy 'Next' i w następnym oknie ponownie wybieramy wcześniej utworzony pattern. Jako pole wybieramy 'poziomakceptacji'. W pole 'value list' wpisujemy "one","two" - parametry jako string nie sprawią problemów w późniejszym ich użyciu w procesie (np. wykorzystanie ich w bramkach). Ustawiamy header na 'poziomakceptacji'.

Tworzymy warunki

Mamy przygotowane kolumny, pora wstawic warunki (dwie pierwsze kolumny) i decyzję po spełnieniu warunków (ostatnia kolumna). Z górnego menu wybieramy 'Insert' => 'Append row'. Dodajemy klika warunków wybierając dział, kwote i poziom akceptacji. Przykładowy wygląd tabeli to wpisaniu warunków:

Te przykładowe warunki definiują że faktura działu IT powyżej kwoty 1000 będzie wymagać dwóch poziomów akceptacji a działy marketing i kontroling wymagaja tylko jednego niezależnie od kwoty faktury.

Umieszczamy Regułę Biznesową w procesie

W naszym testowym procesie akceptacji faktur Reguła Biznesowa jest umieszczona zaraz po zdarzeniu początkowym (Na diagramie mamy 'DMN' nie decision table ale idea jest ta sama).

Reguła Biznesowa powstaje po umieszczeniu na diagramie procesu Tasku i zamiana go na 'Business Rule'. We właściwościach obiektu, w 'Rule language' wybieramy 'DRL' (domyślna opcja) i jako 'Rule Flow Group' wybieramy właściwą 'Guided Decision Table' i atrybut którym będziemy się posługiwać w tej regule. Jak wyżej, 'Guided Decision Table' może mieć więcej niż jeden zestaw warunków/reguł zgrupowanych właśnie poprzez atrybuty.

Następnym zadaniem jest pobranie zmiennych Data Object do tego kroku w procesie (dzięki temu nasze reguły zadziałają) i zwrócenie ich na wyjściu (do ewentualnego wykorzystania w dalszych krokach). We włąsciwościach Business Rule, w Data assignment => Assignments definiujemy zmienne:

W Data Outputs mamy dodakowo zdefiniowana zmienną 'poziomakceptacji' (jest ta zmienna zdefiniowana na poziomie procesu). Jest ona tam właściwie tylko do testu odczytu zawartości pola 'poziomakceptacji' z Data Object. Na poziomie flow bramek możesz odczytać zawartość tego pola wskazując ObiektDanychOne.poziomakceptacji.

Gdybyś chciał inaczej odczytać zawartość pól ObiektDanychOne, możesz użyć JavaSkryptu w oknie On Entry Action, np:

var obiektDanychOne = kcontext.getVariable("ObiektDanychOne");  // Pobierz obiekt danych
if (obiektDanychOne != null) {
    var dzialValue = obiektDanychOne["poziomakceptacji"];  
    kcontext.setVariable("poziomakceptacji", dzialValue);  // Ustaw zmienną procesu poziomakceptacji
} else {
    print("ObiektDanychOne jest null!");
}

W procesie, dla flow odchodzących od bramek ustaw odoiednie 'Condition Expression'. Gdyby był to JavaScript mogło to by być: poziomakceptacji == "one"; lub ObiektDanychOne.poziomakceptacji == "one";

Testujemy proces

W Business Central, w menu Manage wybierz 'process instances'. Następnie 'New Process Instance' i wybierz właściwy proces i kliknij 'Start'. Pojawi się okno:

W zestawie pól brakuje 'poziomakceptacji' ponieważ usuneliśmy je ręcznie po utworzeniu formularzy. Wpisz testowe dane i uruchom proces klikając 'Submit'. We właściwościach instancji procesu, w zakładce Process Variables możesz podejrzeć jaką wartość otrzymała zmienna 'poziomakceptacji'.

B - DMN Decision

Drugim sposobem na stworzenie reguł biznesowych w procesie jest użycie DMN Decision. DMN Decision to standard DMN (Decision Model and Notation) opracowany przez OMG, który umożliwia modelowanie złożonych decyzji i zależności (DRD). Jest przyjazny dla biznesu, wykorzystując tabele decyzyjne i diagramy, a także wspiera język FEEL do tworzenia intuicyjnych wyrażeń.

Różnice między DMN Decision a Guided Decision Table:

Cecha	DMN Decision	Guided Decision Table
Standard	Międzynarodowy standard DMN (OMG)	Własny format Drools/jBPM
Złożoność decyzji	Obsługuje skomplikowane, hierarchiczne modele	Proste reguły warunek-akcja
Czytelność	Bardzo przyjazny dla biznesu (FEEL, diagramy)	Intuicyjny, ale bardziej techniczny
Silnik wykonawczy	DMN Engine	Drools Rule Engine
Zastosowanie	Skomplikowane modele z wieloma zależnościami	Proste lub średnio zaawansowane reguły

Tworzenie modelu DMN Decision

W oknie projektu kliknij na 'Add Asset' i wybierz 'DMN Decision'. W pierwszym oknie dialogowym nadaj nazwę obiektowi, przypisz reguły do odpowiedniego pakietu projektu.

Reguły budujemy myszką wybierając odpowiednie obiekty. W oknie tworzenia modelu wybieramy symbol prostokąta, 'DMN Decision' i przeciągamy go na obszar roboczy. To 'decyzja' w naszym modelu. Nazwa która nadamy dla tego obiektu to nazwa zmiennej która zwróci z naszego modelu decyzję biznesową, w tym przykładzie nazywa się 'Poziom akceptacji'. Dla zmiennej określamy 'data type' - np. numer.

Następnie definiujemy dane wejściowe - zmienne które wchodzą do modelu, na podstawie których podejmujemy decyzje zwracaną przez obiekt 'DMN Decision' (jak wyżej). Klikamy na ikonki elips, 'DMN Input Data' i umieszczamy je w obszarze roboczym modelu a następnie łączymy je strzałkami typu 'Create DMN Information Requirenment' z obiektem decyzji. Nazwy tych obiektów to nazwy zmiennych danych wejściowych - mamy tu dwie zmienne; 'dział' typu string i 'kwota' typu number. W naszym przykładzie mamy tylko dwie zmienne wejściowe ale oczywiście ich liczba może być większa.

Edycja warunków

Następnym krokiem jest edycja logiki decyzyjnej. Wybieramy obiekt 'DMN Decision' nazwany w tym przykładzie 'Poziomakceptacji' i klikamy na ikonkę 'Edit':

Po wybraniu tej ikony przejdziemy do innego ekranu gdzie zobaczymy pusty prostokąt z nazwą 'Select expression'. Klikając w niego otworzymy okno wyboru typu logiki którą chcemy zastosować w naszym modelu:

Wybieramy 'Decision Table'. W tabeli która pojawi się na ekranie definiujemy reguły biznesowe; w tym przykładzie mamy dwie kolumny danych wejściowych 'dzial' oraz 'kwota' i trzecią kolumnę z decyzją, .Poziomakceptacji'.

Nowe wiersze dodajemy poprzez kliknięcie prawym przyciskiem myszy na wiersz tabeli i wybranie z menu 'Insert below'. Kończąć definicję reguł nie zapomnij o 'Hit policy'.

HIT Policy

Hit Policy w DMN określa, jak traktowane są wyniki w tabeli decyzyjnej, gdy spełnionych jest wiele reguł.

Typy:

UNIQUE: Tylko jedna reguła może być spełniona.
FIRST: Pierwsza spełniona reguła (wg kolejności).
ANY: Dowolna reguła, jeśli wszystkie dają ten sam wynik.
PRIORITY: Wynik o najwyższym priorytecie.
COLLECT: Wyniki wszystkich spełnionych reguł (sumowanie, zliczanie, itp.).

Hit Policy wpływa na logikę decyzji i sposób zwracania wyników. Kliknij zatem na literkę Hit Policy w tabeli i wybierz odpowiednią dla Twojego modelu (w naszym przykładzie to 'unique'):

Dokumentacja modelu DMN

By zastosować ten model DMN w procesie, będziesz potrzebować dwóch informacji; nazwy modelu i jego 'namespace'. Te dane odczytasz z dokumentu który pojawi się na ekranie kiedy klikniesz na zakładkę 'Documentation':

Umieszczenie DMN Decision w procesie

Umieszczanie DMN w procesie odbywa się poprzez umieszczenie aktywności typu 'Task' a następnie wybranie typu tasku jako 'Business rule'.

Pamiętaj by ustawić odpowiednie mapowanie danych wejściowych w 'Data Assignments => Data Inputs and Assignments' dla tego tasku (task 'DMN' musi otrzymywać zmienne 'dzial' i 'kwota' a zwracac zmienną 'Poziomakceptacji').