Akcje cykliczne

Facebooktwitterpinterestlinkedinmail
Dotyczy wersji: 2020.1.x i wyższych; autor: Marcin Wiktor

Wprowadzenie

W przypadku aplikacji posiadających dużą ilość zależnych od siebie obiegów często pojawiają się problemy związane z wydajnością takich aplikacji, z powodu przesuwania/tworzenia wielu obiegów w tym samym czasie. Szybkość tworzenia/aktualizowania podobiegów zależy od wielu czynników takich jak: rodzaj formularza, ilość danych/akcji/reguł, szybkości odpowiedzi z zewnętrznych źródeł, obciążenia serwera czy też ogólnej wydajności. W przypadku próby aktualizacji kilkudziesięciu podobiegów w tym samym czasie może dojść do przekroczenia maksymalnego czasu wykonania akcji (timeout).

Poniższy artykuł pokazuje w jaki sposób możemy poradzić sobie z tym problemem wykorzystując tylko standardowe funkcjonalności WEBCON BPS. Można w tym celu utworzyć mechanizm kolejkowania operacji, który będzie aktualizował po 10 dokumentów równocześnie.

Przypadek biznesowy

Chcemy stworzyć aplikację, która będzie pozwalała naszym pracownikom rozliczanie pojedynczych wydatków służbowych. Ze względu na to, że w naszej firmie pojedynczych wydatków jest sporo, to chcemy aby do działu księgowości trafiał grupowy przegląd większej ilości wydatków zamiast pojedynczych zadań.

W tym celu stworzymy aplikację „Rozliczanie wydatków służbowych” składającą się z 2 procesów:

  • Zgłoszenie/rejestracja wydatku służbowego (kroki: Rejestracja – Oczekiwanie na rozliczenie (krok systemowy) – Archiwum/Odrzucone)
  • Rozliczenie wydatku (kroki: Rejestracja – Oczekiwanie na rozliczenie (krok systemowy) – Archiwum)

Aplikacja „Rozliczanie wydatków służbowych” będzie pozwała zgrupować na liczbie pozycji kilkadziesiąt pojedynczych wydatków. Księgowość będzie mogła zdecydować co zrobić: cofnąć do poprawy, zaakceptować lub odrzucić każdy z wydatków osobno.

Następnie akcja cykliczna będzie przeszukiwała każdy z dokumentów rozliczeń i aktualizowała po 10 dokumentów naraz. Ma to na celu poprawić wydajność aplikacji i zapobiec sytuacjom, że za duża ilość aktualizowanych wydatków sprawi, że zostanie przekroczony maksymalny czas wykonywania akcji (tzw. Timeout).

W środowisku produkcyjnym, w prawdziwej aplikacji należy indywidualnie zweryfikować jakie ilości dokumentów mogą być aktualizowane w tym samym czasie. Powinno się przy tym wziąć pod uwagę ilość akcji na przejściu ścieżką, ewentualne integracje z zewnętrznymi systemami czy ogólną wydajność serwera. Na potrzeby pokazania działania takiego mechanizmu – ustalmy, że w tym samym czasie będziemy aktualizować po 10 dokumentów.

W tle będzie działała też druga akcja cykliczna, która będzie przesuwała do Archiwum wszystkie dokumenty rozliczenia, w których zaktualizowano już wszystkie wydatki.

Poniższe screeny przedstawiają przygotowane formularze:

Rys. 1. Formularz zgłaszania nowego wydatku

 

Rys.2. Formularz rozliczania zgłoszonych wydatków

 

Rys.3 Schemat połączenia między procesami

 

Zaprojektujmy teraz mechanizm kolejki tak, aby akcji cykliczna brała do przesunięcia tylko te dokumenty, które nie zostały przesunięte w poprzednim wywołaniu cyklu. W tym celu na liście wydatków musimy dodać atrybut typu checkbox, w którym będziemy trzymać informację czy dany wydatek został przesunięty czy jeszcze nie. Domyślnie ustawiamy NIE ponieważ na początku wszystkie wydatki będą oczekiwały na przesunięcie.

 

Rys.4. Atrybut pomocniczy, którym będziemy oznaczać zaktualizowane wydatki

 

Rys. 5. Konfiguracja kroku sterującego – Czy zaktualizowano wszystkie wydatki?

 

Rys. 6. Cykl przesuwający wydatki

 

Rys. 7. Konfiguracja #1 Akcji cyklicznej

 

Rys. 8. Konfiguracja #2 Akcji cyklicznej

 

Kolejnym krokiem jest obsługa przesuwania wydatków z poziomu obiegu Rozliczenie wydatku. Na kroku „Oczekiwanie na zakończenie” musimy przygotować dwie akcje:

  1. Akcja odpowiedzialna za przesunięcie 10 wydatków do odpowiedniego kroku (w zależności od decyzji Księgowości)
  2. Akcja która aktualizuję listę wydatków na rozliczeniu, zaznaczając które wydatki zostały zaktualizowane przez akcję nr 1

Rys. 9. Akcje na ścieżce „Sprawdź czy rozliczono wszystkie wydatki”

 

Rys. 10. Konfiguracja akcji „Przesuń wydatki”

 

Rys. 11. Konfiguracja akcji „Aktualizuj listę wydatków”

 

Konfiguracja gotowa. Spróbujmy teraz dodać kilkanaście wydatków i spróbować je rozliczyć. W takim przypadku po pierwszym uruchomieniu cyklu, 10 wydatków powinno zostać zaktualizowanych, a w drugim uruchomieniu, te które pozostały.

Rys. 12. Rozliczenie oczekujące na zakończenie

 

Po pierwszym wykonaniu się cyklu możemy zauważyć, że równo 10 wydatków zostało zaktualizowanych i formularz Rozliczenia dalej pozostał w kroku „Oczekiwanie na zakończenie”:

Rys. 13. Lista wydatków po pierwszym wykonaniu akcji cyklicznej

 

Po drugim wykonaniu się akcji cyklicznej, pozostałe 4 wydatki także zostały zaktualizowane i ponieważ, wszystkie z wydatków są już przesunięte, formularz rozliczenia trafił do archiwum:

Rys. 14. Lista wydatków po drugim wykonaniu akcji cyklicznej

 

Powyższy przykład przedstawia w uproszczony sposób obieg dokumentów – stopień skomplikowania obiegów będzie zależał od założeń biznesowych Twojej firmy. Dlatego mechanizm taki powinien być odpowiednio przemyślany pod kątem sposobu działania i ilości przetwarzanych danych w jednym cyklu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *