Proces nieskończony

Jadąc ostatnio autobusem komunikacji miejskiej, chciałem przy wejściu „odbić” kartę. Karta ta musi zostać przyłożona do czytnika w momencie, gdy nie ma się wykupionego biletu długookresowego a korzysta się z mechanizmu tzw. portmonetki. Zamiast poprawnie naliczonej opłaty zobaczyłem pomarańczowy ekran z błędem. Na szczęście drugi czytnik działał poprawnie.

Po zajęciu miejsca, akurat z dobrym widokiem na czytnik, zauważyłem, że na ekranie jest odliczany czas. Potem następował restart aplikacji, wyświetlenie „poprawnego” ekranu czytnika, informację o błędzie komunikacji i ponownie pomarańczowy ekran. A potem po minucie, znów restart i wszystko zaczynało się od początku. I tak w nieskończoność (tak mi się zdawało). Prezentuje to poniższy diagram w BPMN.

Na powyższym diagramie zaprezentowano typ obiektu BPMN określanego jako podproces (ang. subprocess, co jest oznaczone znakiem „+”) z oznaczeniem wykonywania go w pętli (ang. loop subprocess). Jego charakter wykonywania w pętli jest oznaczony symbolem strzałki (w kształcie okręgu) a same szczegóły działania są opisane na diagramie. W dolnej części diagramu wskazano części składowe tego podprocesu.

Wydaje się, że po określonej liczbie restartów czytnik mógłby się zatrzymać i wyświetlić ekran z błędem i prośbą o skorzystanie z innego czytnika lub mógłby się wyłączyć do momentu ręcznej ingerencji przez operatora (np. na pętli autobusowej). W takiej sytuacji potrzebne byłoby wskazanie liczby powtórzeń oraz obsługi sytuacji, gdy po określonej liczbie powtórzeń efekt procesu nie jest zgodny z oczekiwaniami.

Specjalnie na diagramie zostawiłem oznaczenie błędu (czerwony symbol z „x”) przy obiekcie podprocesu pochodzące z aplikacji, w której go rysowałem. Aplikacja wskazała mi, że nie określiłem poprawnego warunku zakończenia pętli, co zrobiłem świadomie, aby zobrazować, że opisywany proces w rzeczywistości się nie kończył – nie miał np. warunku na liczbę wykonywanych powtórzeń w sytuacji, gdy zdarzenie początkowe pojawia się za każdym razem (np. błąd komunikacji).

Reklama

Jak „zatrzymać” pętlę?

Do poprzedniego wpisu dot. algorytmu przydziału zadania, pojawił się komentarz: “Jak w powyższym przypadku zatrzymać pętle? Mam na myśli to, że po kliku przebiegach algorytmu nadal może nie być sędziego.”. Dzięki za komentarz, Postanowiłem temat kontynuować w dzisiejszym wpisie, jednakże nadal nie będę wnikał o jaki rodzaj zadań chodzi podczas przydziału wg algorytmu.

W poprzednim wpisie wskazałem, że momencie braku możliwości przydziału osoby w danym przebiegu, sposobem jest powtórzenie próby przydziału w kolejnym przebiegu. Ten kolejny przebieg, w których uwzględnimy tę sprawę może być rzeczywiście tym następnym lub po jakimś czasie, wszystko zależy od konfiguracji algorytmu. Zgadzam się, że to może nie rozwiązać kwestii.

Dlatego można też sprawdzić liczbę takich prób lub sprawdzić potencjalnie kiedy – efekt jest zawarty z zdarzeniu Możliwy przydział w czasie T przy wyjściu z bramki po zadaniu Zweryfikuj ograniczenia:

• będzie dostępna osoba, która ma określoną specjalizację, gdy ten fakt jest ograniczeniem (zarówno ze względu na założone limity jako niedostępność fizyczną);
• zmniejszy się liczba spraw, która jest obecnie w obsłudze, tj. zostaną zakończone lub zmieni się ich status, gdy obecne wykorzystanie “kolejek” zadań jest ograniczeniem;
• osoba o największym doświadczeniu mogłaby podjąć się zadania.

Alternatywą dla tych przykładowych rozwiązań, jest przekazanie przy określonych warunkach, sprawy do ręcznego przydziału, do administratora lub do innego forum – zawarte w zdarzeniu Do ręcznego przeglądu i po analogicznej bramce jak powyżej. Zgadzam się, że algorytm powinien przewidywać jakieś wyjście z pętli, aby sprawy nie krążyły w nim bez przydziału, bez rozwiązania. Dla zadań mogą być określone oczekiwane czasy ich rozwiązania lub jednostka je przyjmująca ma zdefiniowane parametry pierwszej rekacji lub nawet rozwiązania danego zadania.

Podsumowując, osoba tworząca założenia dla algorytmu przydziału zadań, może zadecyować o kolejności weryfikacji warunków przydziału, tworzeniu listy osób branych pod uwagę przy danym zadaniu, poziomie skomplikowania algorytmu oraz momentu, w którym potrzebny jest przydział poza warunkami lub wręcz ręczna obsługa. Kształt algorytmu bazuje także na informacji zwrotnej od osób obsługujących, wiedzy o nich oraz sposobie parametryzacji zadań.

 

Reguła biznesowa w pętli

W poprzednim wpisie dotyczącym prezentacji pętli w BPMN, wskazałem, że w taki sposób przedstawiona pętla jest nieskończona. Brak połączenia lub zerwane połączenie powoduje powtórzenie czynności. Zabezpieczeniem przed nieskończonym wykonywaniem czynności jest wprowadzenie kroku, który ma sprawdzić:

• jaki jest status ostatniego działania,
• ile razy wystąpiła taka sytuacja,
• ile biznesowo razy dopuszczalne jest powtórzenie czynności,
• jaka powinna być kolejna czynność.

 

Powyższe elementy przekładają się na regułę biznesową, która na podstawie zainstniałych warunków (status operacji, liczba wystąpień, ograniczenie biznesowe) określa kolejne działanie – Powtórzenie działań lub zakończenie procesu. Taką sytuację przedstawia powyższy diagram w BPMN. Między wskazaniem zdarzeń a kolejnym krokiem, został dodany krok reguła biznesowa (ang. business rule task) o nazwie Określ działanie.

W kroku Powtórz działania powinien być odnotowywany historyczny status a zerowany bieżący, ponieważ bez tego proces nie wejdzie nigdy w ścieżkę dzwonienia do odbiorcy. Równocześnie może podbijać licznik wystąpienia statusu w danej kampanii. Decyzją biznesową można zmienić zapisy reguły biznesowej (wartości graniczne) bez konieczności zmiany procesu. Można też wskazać, że nigdy nie jest powtarzane wybieranie numeru.

Wyjście z pętli w BPMN

Ostatnio kilkakrotnie dzwonił do mnie „tajemniczy” numer prywatny. Domyślałem się, że to może być Bank lub inna instytucja. Kilkakrotnie próbowałem odebrać – albo mi się nie udało albo nie słyszałem. Zawsze pozostaje opcja „oddzwonię”, ale nie tym razem – na „Numer prywatny” nie da się oddzwonić. Jeden raz , udało się odebrać i usłyszałem tylko „Proszę czekać na zgłoszenie się operatora”. Pomyślałem – o mają automatyczne wybieranie numeru. Dobra, myślę, poczekam pół minuty, bo więcej nie byłem w stanie. Po pół minucie muzyczki, rozłączyłem się. I niestety brakowało mi jednego, informacji kto i dlaczego dzwoni. Po kilku dniach wreszcie się im udało, po odebraniu usłyszałem natychmiast miły głos operatora, który przedstawił się, wygłosił formułkę i przeszedł do rzeczy. Wysłuchałem go do końca. Następny raz już nie zadzwonili.

Powyższą sytuację można sobie wyobrazić jak pętlę per odbiorca kampanii. Zgodnie z definicja pętli (ang. loop) z matematyki umożliwia cykliczne wykonywanie ciągu czynności („pobranie rekordu, sprawdzenie statusu, wybranie numeru”) określoną liczbę razy, do momentu zajścia pewnych warunków („odbyto rozmowę” – status sprawdzany na bramce), dla każdego elementu kolekcji (działanie wykonywane dla każdego rekordu kampanii) lub w nieskończoność.

Kolejne czynności: sprawdź czy rozmowa się odbyła, wybierz numer, połącz z operatorem (gdy nie jest wolny, poinformuj o oczekiwaniu), a po rozmowie pomiń danego odbiorcę z kolejnego telefonu. Wyjściem z pętli jest zdarzenie „Odbyto rozmowę”. A zdarzenia: „Brak połączenia”, „Połączenie zerwane”, „Odbiorca niedostępny” powodują powtórzenie czynności dla danego odbiorcy.  Odczułem to na własnej skórze – a dzwoniący odczuł wszystkie powyższe zdarzenia z mojej strony. Powyższy diagram w BPMN obrazuje taką sytuację. Zobrazowana pętla, w sytuacji braku odebrania telefonu przez odbiorcę, jest nieskończona – należałoby dodać warunek o ilości prób lub maksymalny czas od rozpoczęcia kampanii do ostatniego telefonu.