Konfiguracja konsultacji ad-hoc w procesie głównym

Konsultacje służą do komunikacji użytkowników Flowee. Zastępuje klasyczną komunikację mailową. Dzięki konsultacjom w ramach sprawy/procesu jest zapisana historia konsultacji wraz z dokumentami dołączanymi do konsultacji. Bez wychodzenia z kontekstu zadania można się skonsultować z dowolnym użytkownikiem Flowee.

Ten fragment procesu odpowiada za:

• włączenie zakładki „Konsultacje” na zadaniu,

• załadowanie konfiguracji dostępnych konsultacji z DMN,

• konfigurację kolejek dla konsultacji ad-hoc,

• przygotowanie danych niezbędnych do uruchamiania osobnych instancji procesu konsultacyjnego.

Konsultacje ad-hoc:

• są osobną definicją procesu => FLOWEE_AD_HOC_CONSULT

  

• są uruchamiane z poziomu zakładki „Konsultacje”,

  

• proces główny jedynie dostarcza konfigurację.

Krok 1: Business Rule Task „konfiguracja konsultacji”

Task pobiera z DMN konfigurację dostępnych konsultacji dla danego procesu.

➤ Dodanie elementu

1. Create task → Business Rule Task

2. Nazwa: konfiguracja konsultacji

➤ Konfiguracja

W panelu Implementation ustaw:

a) Type (wymagane)

DMN

b) Decision reference (wymagane)

CONSULTATION_CONFIG

c) Binding (wymagane)

latest

d) Result variable (wymagane)

DMNresult

e) Map decision result (wymagane)

resultList (List<map<String, Object<<)

➤ Input / Output parameters

Przejdź do: Extensions → Input/Output

Input parameter

Output parameter

Efekt: konfiguracja konsultacji zapisywana jest w procesie jako JSON w zmiennej FnConsultingConfig.

Krok 2: Business Rule Task „konfiguracja kolejek konsultacji ad hoc”

Task pobiera z DMN konfigurację kolejek dla konsultacji ad-hoc.

➤ Dodanie elementu

1. Create task → Business Rule Task

2. Nazwa: konfiguracja kolejek konsultacji ad hoc

➤ Konfiguracja

W panelu Implementation ustaw:

a) Type (wymagane)

DMN

b) Decision reference (wymagane)

AD_HOC_QUEUE

c) Binding (wymagane)

latest

d) Result variable (wymagane)

DMNresult

e) Map decision result (wymagane)

resultList (List<map<String, Object<<)

➤ Input / Output parameters

Input parameter

Output parameter

Efekt: w procesie dostępna jest konfiguracja kolejek, do których będą trafiały konsultacje.

Krok 3: Włączenie zakładki „Konsultacje” na zadaniu

Aby na manualnym zadaniu pojawiła się zakładka „Konsultacje”, należy dodać odpowiedni input parameter.

➤ Konfiguracja manual taska

Na manualnym (User Task / Manual Task), na którym mają być dostępne konsultacje:

Przejdź do: Extensions → Input/Output → Add input parameter

Dodaj:

Efekt:

• na zadaniu pojawi się zakładka „Konsultacje”,

• tasklista otrzyma informację, że dla tej sprawy dostępne są konsultacje ad-hoc.

Efekt działania

• proces główny posiada pełną konfigurację konsultacji,

• dostępna jest konfiguracja kolejek ad-hoc,

• użytkownik widzi zakładkę „Konsultacje”,

• możliwe jest uruchamianie osobnych instancji procesu konsultacyjnego z poziomu zadania.

Reguła DMN „AD_HOC_QUEUE” – schemat projektowy

Reguła AD_HOC_QUEUE służy do definiowania listy kolejek, do których może zostać skierowana konsultacja ad-hoc w zależności od kodu procesu.

Nie steruje przebiegiem procesu – jest wyłącznie konfiguratorem danych dla UI i mechanizmu uruchamiania konsultacji.

https://modeler.develop.flowee.finture.com/panel/rules/definition/AD_HOC_QUEUE/11/

Cel reguły

• zmapowanie kodu procesu na zestaw dostępnych kolejek konsultacyjnych,

• dostarczenie:

  • nazwy czytelnej dla użytkownika,

  • technicznego kodu kolejki.

Reguła jest wykorzystywana w Business Rule Task: „konfiguracja kolejek konsultacji ad hoc”

a jej wynik jest serializowany do zmiennej: FnConsultingQueueConfig

Ogólny schemat reguły

Typ reguły

• Decision Table

• Hit Policy: COLLECT

➡ oznacza to, że:

• reguła nie wybiera jednej decyzji,

• tylko zwraca listę wszystkich pasujących wierszy.

W praktyce: jedna instancja procesu może mieć wiele dostępnych kolejek konsultacyjnych.

Input do reguły

Reguła ma jeden obowiązkowy parametr wejściowy:

Źródło danych:

• przekazywany z procesu BPMN:

Output reguły

Reguła posiada dwa pola wyjściowe, które razem opisują jedną kolejkę.

Postać wyniku

Ze względu na COLLECT, wynik reguły ma postać:

W procesie wynik jest dodatkowo serializowany do JSON:

Ta zmienna jest następnie wykorzystywana przez:

• warstwę UI (lista kolejek),

• mechanizm uruchamiania procesu konsultacyjnego.

Polityka reguły (logika biznesowa)

Reguła realizuje politykę:

„Dla danego procesu głównego dostępny jest określony zestaw kolejek konsultacyjnych.”

Charakterystyka:

✅ jedna reguła = jedna kolejka
✅ wiele reguł może pasować do jednego procesu
✅ brak ograniczenia do jednej decyzji
✅ reguła pełni rolę słownika konfiguracyjnego

Przykład z definicji:

processCode = "TRAINING"

→ zwracane są wszystkie kolejki szkoleniowe

processCode = "DEMO"

→ zwracana jest tylko jedna kolejka

Więcej o politykach DMN tutaj.

Zalecany wzorzec budowy takiej reguły

Każda reguła typu AD_HOC_QUEUE powinna:

Mieć charakter wyłącznie konfiguracyjny

• bez skomplikowanych warunków,

• bez logiki decyzyjnej,

• bez obliczeń.

Zawierać minimum jedno pole filtrujące

W tym przypadku:

• processCode

W przyszłości dopuszczalne rozszerzenia:

• typ klienta,

• segment,

• rola użytkownika,

• region,

• produkt.

Zwracać dane w postaci gotowej do użycia przez UI

Standard:

• queueName – do wyświetlenia,

• queueCode – do logiki systemowej.

Używać polityki COLLECT

Aby:

• nie ograniczać się do jednej kolejki,

• umożliwić dynamiczne sterowanie konfiguracją bez zmiany BPMN.

Dobre praktyki

• nie zmieniać nazw outputów (queueName, queueCode) – są kontraktem z UI,

• jeden wiersz = jedna kolejka,

• nie duplikować queueCode w obrębie jednego procesu,

• trzymać regułę jako „słownik biznesowy”, a nie silnik decyzyjny,

• nową kolejkę dodajemy przez:
  ➜ nowy wiersz,
  ➜ bez zmiany procesu.

Reguły typu AD_HOC_QUEUE służą do centralnego definiowania dostępnych kolejek konsultacji ad-hoc. Są to reguły konfiguracyjne, zwracające listę rekordów opisujących kolejki. Proces główny nie zawiera na sztywno żadnych kolejek – cała konfiguracja pochodzi z DMN.

Reguła DMN „CONSULTATION_CONFIG” – schemat projektowy

Reguła CONSULTATION_CONFIG służy do definiowania globalnej konfiguracji konsultacji ad-hoc dla danego procesu głównego. Można jedną reguły wykorzystać do wszystkich procesów biznesowych a można dla każdego procesu tworzyć osobną analogiczną regułę, co nie jest dobra praktyką.

https://modeler.develop.flowee.finture.com/panel/rules/definition/CONSULTATION_CONFIG/14/

W przeciwieństwie do AD_HOC_QUEUE, która opisuje gdzie konsultację można skierować, ta reguła opisuje jak konsultacja ma być tworzona i obsługiwana:

• jaki formularz,

• jaki typ sprawy,

• jakie SLA,

• jaka komunikacja,

• jaki typ procesu.

Cel reguły

Reguła dostarcza kompletny zestaw parametrów startowych dla instancji procesu konsultacyjnego, w szczególności:

• konfigurację formularza,

• parametry biznesowe konsultacji,

• ustawienia SLA i kalendarza,

• konfigurację powiadomień mailowych,

• metadane procesu konsultacji.

Jej wynik jest zapisywany do zmiennej: FnConsultingConfig

i wykorzystywany przy:

• budowie zakładki Konsultacje,

• uruchamianiu nowej instancji procesu konsultacyjnego,

Ogólny schemat reguły

Typ reguły

• Decision Table

• Hit Policy: COLLECT

➡ formalnie reguła zwraca listę rekordów konfiguracyjnych.

W praktyce projektowo:

• dla jednego procesu powinna istnieć dokładnie jedna reguła wynikowa,

• COLLECT pozwala na przyszłe rozszerzenia (np. wiele typów konsultacji w jednym procesie).

Input do reguły

Reguła posiada jeden podstawowy parametr wejściowy:

Output reguły

Reguła zwraca obiekt konfiguracyjny konsultacji.

Postać wyniku

Ze względu na COLLECT, wynik reguły ma postać listy:

W procesie BPMN wynik jest serializowany:

Polityka reguły (logika biznesowa)

Reguła realizuje politykę:

„Każdy proces, który udostępnia konsultacje, musi posiadać centralnie zdefiniowaną konfigurację sposobu obsługi konsultacji.”

W szczególności reguła decyduje o:

• standardzie obsługi (SLA, kalendarz),

• integracji (mail, autoresponder),

• tożsamości procesu konsultacyjnego (processType),

• sposobie inicjalizacji danych (template, formCode).

Więcej o politykach DMN tutaj.

Zalecany wzorzec budowy reguły CONSULTATION_CONFIG

Jedna reguła = jedna konfiguracja konsultacji

Dla jednego processCode:

• dokładnie jeden wiersz,

• jeden obowiązujący standard konsultacji.

Reguła opisuje „kontrakt” procesu konsultacji

Reguła powinna zawierać wyłącznie:

• parametry inicjalizacyjne,

• dane konfiguracyjne,

• brak logiki warunkowej.

Nie powinna:

• wybierać kolejek,

• sterować przebiegiem procesu,

• zawierać obliczeń.

Pola wyjściowe mają charakter systemowy

Każdy output powinien być:

• stabilnym kluczem konfiguracyjnym,

• interpretowanym przez kod lub UI,

• niezmiennym semantycznie.

Np.:

• calendarType → silnik SLA,

• mailTemplateCode → moduł komunikacji,

• formCode → silnik formularzy.

Hit policy COLLECT jako zabezpieczenie rozwojowe

Umożliwia w przyszłości:

• wiele typów konsultacji w jednym procesie,

• wersjonowanie konfiguracji,

• rozszerzenie o warianty bez zmiany BPMN.

Dobre praktyki

• dokładnie jeden rekord na proces (na dziś),

• nie usuwać kolumn – rozszerzać, nie zmieniać kontraktu,

• puste pola oznaczają „brak funkcjonalności”, a nie błąd,

• nie wpisywać danych środowiskowych (np. konkretnych maili produkcyjnych),

• nazwy pól traktować jako API między DMN a procesem.

Reguła CONSULTATION_CONFIG centralizuje całą konfigurację techniczno-biznesową konsultacji ad-hoc. Proces główny nie zawiera na sztywno żadnych parametrów konsultacji – wszystkie ustawienia są dostarczane przez DMN i mogą być zmieniane bez modyfikacji BPMN.