Gdy Klient nie decyduje…

Informujemy, że podczas składania zamówienia niektóre produkty były na wyczerpaniu i nie są już dostępne. Zgodnie z regulaminem sklepu, zamówienie zostanie pomniejszone o dany produkt. Jeżeli zamówienie było opłacone z góry, środki zostaną zwrócone na konto w ciągu 7 dni roboczych.”. Taką wiadomość otrzymałem z jednego ze sklepów internetowych, prawie tydzień od złożenia zamówienia. O tym, że realizacja zamówienia będzie wydłużona wiedziałem od momentu składania zamówienia. Także później przyszła informacja o tym, że potrwa dłużej. Jednak gdy otrzymałem taką wiadomość byłem trochę zaskoczony, bo składając zamówienie nie było informacji o potencjalnych brakach produktów.

Przy wcześniejszych zamówieniach, które składałem, takie sytuacje się zdarzały, ale sposób działania sklepu był inny. Jedne sklepy oczekiwały potwierdzenia w zakresie proponowanych akcji lub anulowania zamówienia. Były też propozycje telefoniczne zastąpienia produktu innym w podobnej cenie. Pierwszy raz mi się zdarzyło, że to sklep zadziałał w określony sposób, tylko mnie informując. W sumie cieszę się, że nie czekali z realizacją zamówienia na moją decyzję, a zwrócą środki za brakujące produkty, a resztę zamówienia zrealizują.

Na poniższym diagramie w BMPN spróbowałem przedstawić opisywaną sytuację (mam nadzieję, że w poprawny sposób).

zamowienie_error_500px

W celu zobrazowania sposobu obsługi sytuacji, gdy na magazynie jednak nie ma produktu, użyty został obiekt BPMN wskazujący na błąd wewnątrz procesu (ang. intermediate error event), a dokładnie w ramach wykonania kroku procesu. Po wystąpieniu tego zdarzenia, następuje poinformowanie Klienta (pierwszy krok po zdarzeniu) oraz zwrot środków (drugi krok po zdarzeniu). Obiekt błędu jest umieszczony na obramowaniu kroku Skompletuj zamówienie. Jest to wskazanie, że błąd nastąpił w trakcie realizacji tego kroku i został przejęty (ang. catch) i obsłużony (ang. handle) ramach wskazanych kroków.

Mogę sobie wyobrazić, że podczas tego kroku, pracownik sklepu przechodzi przez magazyn z elektroniczną listą produktów, znajduje je po kolei i umieszcza w środku transportu. Po przejściu kilkunastu pozycji zamówienia, nie odnajduje kolejnego produktu w odpowiedniej ilości. Oznacza to, kompletuje resztę. Na tej podstawie proces idzie dla zebranych produktów dalej, a dla brakujących jest obsługa sytuacji nietypowej/wyjątkowej.

Innym rozwiązaniem jest, gdy taki obiekt błędu jest umieszczany jako niezależny element w ramach przebiegu procesu (ang. sequence flow). Przykład takiego zastosowania tego obiektu można zobaczyć w innym wpisie dotyczącym wyjątków.

Lokalnie czy na serwerze?

Kilka razy na tydzień czy nawet dziennie, wypełniamy w przeglądarce formularze. Czy to pola do logowania w aplikacji, czy to formularz zamówienia, rejestracji w serwisie czy może komentarz na forum? Każdy z tych formularzy ma określoną liczbę pól, istotną dla danej operacji. Wypełniając formularz nie zastanawiamy się jednak na tym, że pod nim kryje się dodatkowa logika. Tę logikę zauważamy, gdy ominiemy pole lub wpiszemy błędną wartość. Otrzymujemy odpowiedni komunikat, a potem wprowadzamy uzupełnienia i wysyłamy formularz. Działanie to przedstawia poniższy proces.

blog_walidacje450

W powyższym procesie zakładamy, że po wysłaniu formularza jest wykonywana walidacja sposobu jego wypełnienia. Walidacja taka może odbyć się lokalnie, zdalnie (tj. na serwerze) lub w każdym z tych miejsc. Walidacja wykonywana lokalnie przeważnie nie wymaga komunikacji z serwerem i jest wykonywana przez przeglądarkę użytkownika (np. przy użyciu tzw. Java Script, o czym więcej pod linkiem na końcu wpisu). Walidacja wykonywana zdalnie (na sewerze) wymaga przesłania danych do serwera i poczekania na jego odpowiedź.

walidacje_2_450px

Jak widać na diagramie, mamy 2 ścieżki – lokalną na zielono oraz z wykorzystaniem serwera na żółto. Na obydwu ścieżkach wystąpienie błędu (oznaczonego obiektem error event) powoduje powrót do formularza. W pierwszym przypadku formularz do serwera jest przesyłany o 1 raz mniej niż w drugim przypadku.

Częścią wspólną są zdarzenia: początkowe, czyli Zaakceptowany formularz oraz końcowe, czyli Formularz poprawny oraz Formularz niepoprawny. W ramach części procesu, są podobne kroki, ale wykonywane w innych miejscach. Chcąc wdrożyć mechanizmy po obywdu stronach można wykorzystać różne języki programowania i metody. Jak widać w podlinowanym artykule możliwości jest wiele i w zależności od sposobu zaprojektowania rozwiązania mechanizmy są rozdzielone lub silnie ze sobą powiązane (jak np. przy wykorzystaniu AJAX).

Jak stosować zdarzenie error wewnątrz procesu?

W pracy korzystam z narzędzia napisanego w VBA (ang. Visual Basic for Applications) do generowania wynikowego pliku tekstowego z arkusza kalkulacyjnego. Jednym z kroków jest odczytanie liczby rekordów i przypisanie jej do zmiennej pomocniczej.

Podczas tworzenia narzędzia założyłem zmienną jako Liczba Całkowita (typ Integer). Podczas próby wykonania nowego raportu pojawił się błąd „overflow”. Oznacza on, że nie można przepisać wartości większej niż dopuszcza to typ pola (na diagramie zdarzenie błąd wartości). Po poprawieniu (zmiana na Long) mechanizm zadziałał poprawnie.

Podany przykład można byłoby zobrazować następująco na diagramie:

error_ev_pl1_450px
Na powyższym diagramie jest zaprezentowane zastosowanie zdarzenia tzw. intermediate o charakterze błędu (ang. error event), co powoduje przerwanie wykonania algorytmu. Obrazuje to zdarzenie końcowe z krzyżykiem.  Tego typu zdarzenie błędu umieszczamy na brzegu czynności mogącej spowodować błąd (na diagramie Odczytaj liczbę wierszy) i  łączymy z czynnością obsługującą (na diagramie Wyświetl komunikat) lub z zdarzeniem końcowym procesu.