17 Marzec 2016

Zrozumieć JBoss Drools

java programowanie

Autor: Marek Brzozowski

Zrozumieć JBoss Drools

droolsPlatformLogo

 

Drools (BRMS) – system zarządzania regułami biznesowymi

Zbiór bibliotek napisanych w języku Java zebranych w jeden pakiet JBoss Drools to kompleksowe rozwiązanie szeroko stosowane w biznesie, a dokładniej rzecz ujmując w procesie tworzenia rozwiązań informatycznych dla biznesu. Powstało z potrzeby ułatwienia i przyspieszenia tworzenia biznesowych działań i pozwoliło na zwiększenie elasyczności poprzez wyniesienie logiki biznesowej do konfiguracji danego oprogramowania. Dzięki takiemu podejściu reguły może modyfikować analityk systemowy lub biznesowy, a zmiany wprowadzać bezpośrednio w arkuszach MS Excel lub z użyciem pseudonaturalnego języka DSL (Domain Specific Language). Jednak zamim to zrobi to od nas – ekspertów Drools – zależy jakie wyrażenia DSL będzie miał do dyspozycji lub w jaki sposób będzie zmieniał reguły biznesowe.

Wiedza jest wszystkim

Najnowsza wersja pakietu to Drools 6.3.0.Final. Nie jest moim celem opisywać tu wszystkiego, a jedynie zwrócić uwagę na najważniejsze rzeczy, które pozwolą zrozumieć jak działają reguły. Z tego względu dociekliwych odsyłam do dokumentacji.

Osoby niezaznajomione z Drools’ami często podchodzą do problemu implementowania logiki biznesowej tak jak w kodzie Java, rozwiązując ją za pomocą for’ów, if’ów oraz kondensują całą logikę w ramach kilku reguł, co sprawia, że reguła ma ponad 1000 linii i jest mało czytelna. Reguły powinny być rozsądnie krótkie, logiczne, łatwe do zrozumienia. Jeśli już widzisz taki ciągnący się makaron – rozbij na mniejsze części.

Używaj reguł tam, gdzie:

  • logika zmienia się często,

  • problem jest złożony i tradycyjne podejście jest trudne w implementacji,

  • problem może nie jest złożony, ale tradycyjne podejście się nie sprawdzi,

  • „opiekun” logiki biznesowej nie jest techniczny

Najważniejszą sprawą jest jednak to, aby zrozumieć jak działają reguły. Najlepiej na przykładzie.

Niekończąca się opowieść

Ważna persona z biznesu chce by system przywitał nowego klienta, jeśli jeszcze tego nie zrobił. W tym celu definiujemy klasę Messages, odpowiedni proces oraz plik reguł jak poniżej:

process

 

Proste. Pierwsza reguła sprawdza czy przywitanie miało miejsce, jeśli nie to ustawia odpowiedni stan obiektu Messages. Druga reguła wita gościa:

 

Ważna persona z biznesu jednak chce by po przywitaniu pożegnać gościa. Modyfikujemy więc drugą i dodajemy trzecią regułę:

 

Dostajemy polecenie, aby po pożegnaniu gościa, przywrócić domyślny stan:

Proste, prawda? Po modyfikacjach reguły, zadowoleni, wrzucamy ją do systemu i… zabijamy serwer, a od przełożonych słyszymy kilka urodziwych słów. Dlaczego?!

Przeglądając logi zobaczymy powtarzające się sekwencje wykonywania reguł: reguła 1, reguła 2, reguła 3, reguła 1, reguła 2 itd. Przecież powinno się zakończyć na 3 regule.

I tu odkrywamy dwufazową kontrolę wykonania:

  1. Rule Runtime Actions
  2. Agenda Evaluation

W pierwszej fazie silnik reguł sprawdza, które reguły może wykonać (tzn które warunki części WHEN są spełnione). Po zakończonym procesie silnik przełącza się w drugą fazę. W tej fazie wykonuje regułę, jeśli takowa została znaleziona w pierwszej fazie i przełącza się do pierwszej fazy. Sprawdzanie wykonywane jest w tej samej agendzie lub grupie reguł. Proces powtarza się do momentu gdy nie znajdzie żadnej reguły do wykonania.

W naszym przypadku powstanie pętla nieskończona, gdyż reguła trzecia modyfikuje obiekty tak, że są spełnione warunki pierwszej reguły. Cały proces można słownie zobrazować tak:

  1. Faza 1 – silnik znajduje spełnione warunki 1 reguły, przełącza się w drugą fazę
  2. Faza 2 – wykonanie reguły 1, powrót do fazy 1 (bo wykonał regułę)
  3. Faza 1 – silnik znajduje spełnione warunki 2 reguły, przełącza się w drugą fazę
  4. Faza 2 – wykonanie reguły 2, powrót do fazy 1
  5. Faza 1 – silnik znajduje spełnione warunki 3 reguły, przełącza się w druga fazę
  6. Faza 2 – wykonanie 3 reguły, powrót do fazy 1
  7. patrz pkt 1.

Rozwiązania są przynajmniej dwa:
– użycie lock-on-active przy regule 1 (rule „Process first message” ruleflow-group „ProcessMessage” lock-on-active)
– przeniesienie reguły 3 do innej grupy (ruleflow-group „InnaGrupa”)

Jak widać zrozumienie działania reguł biznesowych jest dość istotne. Przede wszystkim zaoszczędzi czas, a po drugie pozwoli na efektywne i logiczne pisanie reguł.

Na firmowym GitHub znajdziecie maven’owy poligon doświadczalny.

We like cookies... and we use them.

In order to improve our service, we use cookies. You can block them by changing your browser settings.