Łączenie procesu głównego z podprocesem – Call Activity i mapowanie danych

Call Activity służy do uruchamiania oddzielnej instancji procesu (podprocesu) z poziomu procesu głównego.

Podproces:

• posiada własne zmienne,

• własny kontekst,

• własny cykl życia.

Model działania Call Activity

Uruchomienie Call Activity powoduje:

1. utworzenie nowej instancji procesu,

2. skopiowanie wybranych danych z procesu głównego do podprocesu (In),

3. wykonanie podprocesu,

4. (opcjonalnie) przepisanie wyników z podprocesu do procesu głównego (Out).

Schemat:

Proces główny

|
| In mappings (wejście)
V
Podproces
|
| Out mappings (wyjście)
V
Proces główny

Kontrakt danych między procesami

Każde połączenie procesu z podprocesem musi mieć zdefiniowany kontrakt danych, który odpowiada na trzy pytania:

Identyfikacja sprawy

(dzięki temu podproces „wie”, do czego należy)

Typowe pola:

• numer sprawy (business key),

• id procesu nadrzędnego.

Kontekst biznesowy

(dane potrzebne do pracy podprocesu)

Np.:

• dane klienta,

• typ procesu,

• konfiguracje,

• parametry startowe.

Dane zwrotne (opcjonalnie) (rezultat pracy podprocesu)

Np.:

• decyzja,

• status,

• wygenerowane dokumenty,

• flagi sterujące.

Konfiguracja Call Activity w procesie głównym

Wybór procesu

W panelu właściwości:

In mappings w procesie głównym – przekazywanie danych do podprocesu

In mappings definiują, jakie zmienne z procesu głównego zostaną skopiowane do podprocesu.

Minimalny, zalecany standard:

Identyfikacja sprawy

Znaczenie:

• parentProcessInstanceId – pozwala podprocesowi odwoływać się do procesu głównego.

Kontekst procesu (przykładowe)

W zależności od przypadku:

• dane klienta,

• kod procesu,

• konfiguracja DMN,

• dane formularzy.

Zasada:

Podproces powinien dostać tylko to, czego realnie potrzebuje do działania. Nie przekazujemy całego JSONa procesowego formData.

Out mappings w procesie głównym – zwrot danych do procesu głównego (opcjonalne)

Out mappings stosujemy, gdy podproces przykładowo:

• wypracowuje decyzję,

• generuje dane,

• ustawia status,

• produkuje wynik wykorzystywany dalej.

Przykłady:

• decyzja konsultacji,

• data zakończenia,

• status sprawy,

• identyfikator utworzonego bytu.

Zalecany schemat mapowania

W dokumentacji procesu zawsze warto rozbić mapowania na trzy logiczne grupy:

A. Dane identyfikacyjne

• business key

• id procesu nadrzędnego

B. Dane robocze

• formularze

• parametry

• konfiguracje

C. Dane wynikowe

• decyzje

• statusy

• flagi sterujące

Utworzenie podprocesu

Podproces jest osobną instancją procesu, zatem trzeba utworzyć nowy proces zgodnie z opisem tutaj: Tworzenie pustego procesu

Konfiguracja startowa podprocesu – inicjalizacja danych z procesu głównego

Po uruchomieniu podprocesu przez Call Activity, wszystkie dane przekazane w sekcji In mappings stają się zmiennymi nowej instancji procesu.
Samo przekazanie zmiennych to jednak za mało – w architekturze Flowee konieczne jest dodatkowe zsynchronizowanie danych domenowych z procesu głównego do domeny danych podprocesu.

Do tego celu służy dedykowany Script Task wykonywany na początku podprocesu.

Cel kroku „set process data”

Zadaniem tego elementu jest:

• pobranie identyfikatora procesu nadrzędnego,

• odczytanie pełnych danych domenowych procesu głównego,

• skopiowanie ich do domeny danych nowej instancji podprocesu.

Dzięki temu:

• podproces pracuje na aktualnym kontekście biznesowym,

• wszystkie formularze, checklisty i integracje widzą spójne dane,

• możliwa jest pełna niezależność instancji przy zachowaniu wspólnego stanu biznesowego.

Konfiguracja elementu w Flowee BPMS Modeler

Typ elementu

W podprocesie dodaj na początku:

Create task → Script task

Nazwa: set process data

Asynchroniczność

W panelu właściwości:

Asynchronous continuations → Before

Zapewnia to:

• osobną transakcję,

• poprawną inicjalizację danych,

• odporność na rollback w przypadku błędów integracyjnych.

Output parameter

W zakładce Input/Output → Output parameters dodaj:

Cel:

• zapisanie lokalnego identyfikatora instancji podprocesu do zmiennej procesowej,

• umożliwienie późniejszych wywołań dataDelegate w obrębie podprocesu.

Skrypt inicjalizacyjny

W polu Script ustaw:

Skrypt realizuje cztery kroki:

1. Pobranie identyfikatorów procesów:

   • aktualnego (processInstanceId)

   • nadrzędnego (parentProcessInstanceId – przekazanego w In mappings).

2. Odczyt danych domenowych procesu głównego:

   • przez dataDelegate.getValueByPath(parentProcessInstanceId, '')

3. Deserializację JSON do struktury Groovy.

4. Zapis pełnych danych do domeny podprocesu:

   • dataDelegate.setValuesByPath(processInstanceId, ['.': … ])

Efekt:

cała struktura danych procesu głównego zostaje skopiowana jako stan startowy podprocesu.

Powiązanie z Call Activity (kontrakt danych)

Ten krok wymaga, aby w Call Activity w procesie głównym istniało mapowanie parentProcessInstanceId:

Source: ${execution.getProcessInstanceId()}

Target: parentProcessInstanceId

Bez tego:

• podproces nie zna identyfikatora procesu głównego,

• nie jest w stanie pobrać jego danych,

• inicjalizacja zakończy się błędem.

Logika architektoniczna

Ten wzorzec realizuje tzw.:

„Snapshot danych procesu głównego w momencie startu podprocesu”.

Oznacza to, że:

• podproces otrzymuje pełny kontekst biznesowy,

• ale pracuje na własnej domenie danych,

• co umożliwia:

  • niezależne wersjonowanie,

  • odseparowane formularze,

  • własne logiki binzesowe.

Najczęstsze problemy

• brak zmiennej parentProcessInstanceId,

• próba pracy na danych bez inicjalizacji domeny,

• nadpisanie danych podprocesu w późniejszych krokach,

• używanie execution.getVariable() zamiast domeny danych.

Checklista poprawnej integracji

Przed uznaniem Call Activity za poprawnie skonfigurowane sprawdź:

☐ Czy podproces ma zmapowany numer sprawy?
☐ Czy podproces zna id procesu głównego processInstanceId/parentProcessInstanceId/processId?
☐ Czy wszystkie dane używane w podprocesie są jawnie przekazane, są zmapowane jako Inputs/In mappings?
☐ Czy dane, które mają wrócić, są zmapowane jako Outputs/Out mappings?
☐ Czy nazwy zmiennych w podprocesie są spójne z mapowaniami?

Najczęstsze błędy

• brak mapowania business key

• używanie w podprocesie zmiennych, które nigdy nie zostały przekazane

• przekazywanie całego kontekstu procesu zamiast potrzebnego minimum

• logika biznesowa zaszyta w mapowaniach