Monitor kolejki dokumentów do ERP nie opiera się w opisywanym rozwiązaniu na harmonogramie, tylko na zdarzeniach z codziennej pracy. Alert o wpisie powstaje raz na jego stan, a stan "w kolejce" potwierdza odczyt z ERP w tym samym przebiegu. Wiadomość i oznaczenie wpisu zapisują się w jednej transakcji.
Pracownik magazynu wysyła dokument przyjęcia, a ERP przyjmuje go do kolejki i nie podaje jeszcze numeru dokumentu. Mija pół godziny, nikt do tego dokumentu nie wraca, a w kolejce wciąż nie wiadomo, co się z nim stało. Monitor kolejki ERP z alertami ma pilnować takich wpisów w środowisku, w którym nie ma zadania harmonogramu.
Doganianie kolejki ERP nie opiera się na harmonogramie
Dokument przyjęcia wysłany do kolejki ERP ma w systemie wpis śledzenia. Wpis ma pięć stanów: w kolejce, zakończono, błąd, zatrzymano przed wysłaniem i anulowano. Stan "w kolejce" oznacza, że ERP przyjęło dokument do kolejki, a wynik nie jest jeszcze znany.
Ktoś musi więc dopilnować, żeby takie wpisy nie wisiały bez wiadomości. W opisywanym rozwiązaniu doganianie kolejki nie opiera się na harmonogramie ani na wyzwalaczu bazy danych, tylko na zdarzeniach z codziennej pracy. Procedura monitora uruchamia się przy czynnościach użytkowników, a nie według zegara.
Pobieranie zamówień z ERP, które odbywa się w odwrotnym kierunku, opisuje tekst o zamówieniach pobieranych z ERP przyrostowo. Sam przebieg wysyłki, w którym ekran co jakiś czas pyta o stan, opisuje tekst o wysyłce przyjęcia do ERP przez kolejkę. Model z zadaniem harmonogramu pokazuje strona o usłudze harmonogramu zadań, a ogólne tło integracji z ERP daje strona o integracji systemu awizacji z ERP.
Monitor uruchamiają trzy rodzaje zdarzeń z codziennej pracy
Monitor jest wywoływany w trzech miejscach. Pierwsze to czynności przy bramie oraz zapis albo edycja awizacji: monitor uruchamia się wtedy tuż przed wysłaniem statusu do ERP. Drugie to koniec każdej wysyłki dokumentu przyjęcia. Trzecie to otwarcie formularza dokumentu przyjęcia.
| Zdarzenie | Kiedy uruchamia się monitor | Tryb monitora |
|---|---|---|
| Potwierdzenie przybycia dostawy | Tuż przed wysłaniem statusu do ERP | Bez połączenia z ERP |
| Wjazd na teren | Tuż przed wysłaniem statusu do ERP | Bez połączenia z ERP |
| Wyjazd | Tuż przed wysłaniem statusu do ERP | Bez połączenia z ERP |
| Zapis awizacji | Tuż przed wysłaniem statusu do ERP | Bez połączenia z ERP |
| Edycja awizacji | Tuż przed wysłaniem statusu do ERP | Bez połączenia z ERP |
| Koniec wysyłki dokumentu przyjęcia | Na końcu każdej wysyłki | Z doganianiem |
| Otwarcie formularza dokumentu przyjęcia | Przy otwarciu formularza | Z doganianiem |
Nie każda zmiana statusu awizacji uruchamia monitor. Nie wywołują go trzy czynności: anulowanie awizacji, jej zakończenie oraz potwierdzenie przez managera. Sama zmiana statusu jest zapisana osobnym wywołaniem przed monitorem, a to, jak status trafia do ERP, opisuje tekst o statusie awizacji w ERP. Przejścia statusów i ślad w historii, który zostawiają, pokazuje tekst o znacznikach czasu etapów awizacji.
Przed eksportem statusu monitor działa w trybie bez połączenia z ERP. Sprawdza tylko tabelę śledzenia i przygotowuje alerty. Przy wysyłce dokumentu i przy otwarciu formularza działa z doganianiem, czyli dodatkowo pyta ERP o wpisy czekające w kolejce i zamyka te, które ERP już rozstrzygnęło.
Monitor stoi przed eksportem statusu po to, żeby uruchomił się niezależnie od wyniku eksportu. Błąd w samym monitorze nie zmienia wyniku wysyłki dokumentu ani zmiany statusu awizacji.
W kolejce znaczy tylko tyle, ile potwierdził odczyt
Samo wykonanie procedury doganiającej nie dowodzi, że ERP odpowiedziało. Wpis uznaje się za potwierdzony w kolejce dopiero wtedy, gdy w tym przebiegu odczyt jego stanu z ERP zakończył się poprawną odpowiedzią. Bez takiego odczytu monitor nie ma podstaw, żeby mówić, że dokument nadal czeka.
Wpis bez potwierdzenia trafia do alertu z dopiskiem, że nie jest potwierdzony w ERP i mógł już zostać przetworzony. Takie wpisy są kierowane tylko do podstawowej listy adresatów. Gdy kolejny przebieg potwierdzi wpis odczytem, powstaje drugi alert.
Zachowanie dla pięciu sytuacji pokazuje tabela. Stan nierozstrzygnięty, czyli taki, w którym po wysłaniu nie wiadomo, czy dokument powstał, opisuje szerzej tekst o stanie nierozstrzygniętym po wysłaniu dokumentu do ERP.
| Stan wpisu | Kiedy jest alert | Co mówi alert | Czy wraca |
|---|---|---|---|
| W kolejce, potwierdzony odczytem | Wpis jest starszy niż próg | Czeka w kolejce ERP | Nie, dopóki stan się nie zmieni |
| W kolejce, niepotwierdzony | Wpis jest starszy niż próg, a w tym przebiegu nie było udanego odczytu | Niepotwierdzony w ERP, mógł już zostać przetworzony | Tak, drugi alert po potwierdzeniu odczytem |
| Błąd | Od razu, gdy nie było alertu o tym stanie | Treść błędu, przycięta do 500 znaków | Nie, dopóki stan się nie zmieni |
| Nierozstrzygnięty | Jak przy błędzie | Dokument mógł powstać w ERP, trzeba to sprawdzić w ERP | Nie, dopóki stan się nie zmieni |
| Zatrzymany przed wysłaniem | Jak przy błędzie | System zatrzymał dokument przed wysłaniem | Nie, dopóki stan się nie zmieni |
Alert powstaje raz na wpis i stan
Do alertu kwalifikują się trzy rodzaje wpisów: starsze niż próg, z błędem i zatrzymane przed wysłaniem. Próg w przykładzie wynosi 30 minut, ale to ustawienie domyślne, a nie reguła, którą opisywane wdrożenie narzuca.
W tabeli śledzenia zapisują się czas ostatniego alertu i stan, o którym alarmowano. Kolejny alert powstaje dopiero wtedy, gdy wpis zmieni stan na inny wymagający uwagi, na przykład z "w kolejce" na "błąd". Ten sam wpis w tym samym stanie nie dostaje więc nowego alertu przy kolejnych przebiegach.
Alert o wpisie powstaje raz na stan, a stan "w kolejce" potwierdza tylko odczyt z ERP w tym samym przebiegu.
Jeden przebieg przygotowuje jeden zbiorczy alert z tabelą o sześciu kolumnach: dokument, zamówienie, stan, numer wpisu w kolejce, czas wysłania i błąd. Treść błędu jest przycięta do 500 znaków, a znaki specjalne są zamienione, żeby tekst z ERP nie psuł wiadomości.
Wpis z błędem oznaczonym jako nierozstrzygnięty opisuje się w alercie jako nierozstrzygnięty: dokument mógł powstać w ERP i trzeba to sprawdzić w ERP. Błąd z odrzuceniem dokumentu pokazuje się ze swoją treścią. Wpis, który w tej chwili jest wysyłany, jest pomijany w alercie danego przebiegu, bo użytkownik widzi jego wynik na ekranie.
Wiadomość i oznaczenie wpisu zapisują się razem
Wiadomość i oznaczenie wpisów jako zaalarmowanych zapisują się w jednej transakcji. Nie ma więc wpisu oznaczonego bez wiadomości ani wiadomości bez oznaczenia. System zapisuje wiadomość w kolejce wiadomości, a opis nie obejmuje jej dalszej drogi.
Gdy wywołujący ma już otwartą transakcję, monitor używa punktu zapisu, żeby jego błąd nie wycofał pracy wywołującego. Zgodnie z opisem błąd monitora nie zmienia wyniku wysyłki dokumentu ani zmiany statusu awizacji.
Monitor zaczyna od blokady aplikacyjnej bez czekania. Drugi równoległy przebieg, który nie dostanie blokady, kończy się od razu i niczego nie robi. To ogranicza ryzyko dwóch kopii tego samego alertu, gdy dwie osoby otworzą formularz w tej samej chwili. Wzorzec blokady i indeksu pilnującego duplikatów opisuje tekst o blokadzie aplikacyjnej i indeksie filtrowanym w T-SQL.
Bez zdarzeń monitor nie jest wywoływany
Monitor uruchamiają czynności z listy zdarzeń. Gdy nikt ich nie wykonuje, monitor nie jest wywoływany, a opis nie przewiduje innego sposobu jego uruchomienia. Monitor nie jest związany z godzinami pracy magazynu, bo uruchamia go także zapis awizacji.
Monitor ma tryb podglądu, który pokazuje wpisy kwalifikujące się do alertu i treść wiadomości bez zapisywania wiadomości i bez oznaczania wpisów. Podgląd działa bez doganiania, więc wpisy w kolejce mogą wyglądać w nim jak niepotwierdzone.
Inne opisy wdrożeń z tej sekcji zbiera przewodnik po systemie awizacji, a pomoc przy wdrożeniu takiego rozwiązania opisuje strona o serwisie i wsparciu technicznym.
Jeden wpis od wysłania do alertu w przykładzie
Przykład z danymi fikcyjnymi. Pracownik magazynu wysyła dokument przyjęcia do Zamówienia 26-1001, a ERP przyjmuje go do kolejki bez numeru dokumentu. Po 30 minutach pracownik logistyki zapisuje Awizację 26-2001, co uruchamia monitor w trybie bez połączenia z ERP.
Monitor widzi wpis starszy niż próg, ale bez udanego odczytu, więc przygotowuje alert z dopiskiem, że wpis jest niepotwierdzony i mógł już zostać przetworzony. Gdy kolejna osoba otworzy formularz dokumentu przyjęcia, monitor odczyta wpis z ERP. Jeśli odczyt się uda i dokument nadal nie ma numeru, powstanie drugi alert z potwierdzonym stanem w kolejce.
Gdyby ERP zdążyło utworzyć dokument, wpis zamknie się jako zakończony i drugiego alertu już nie będzie.
Pytania do ustalenia przed budową monitora
Przed budową podobnego monitora ustalamy cztery sprawy.
- Harmonogram - czy w środowisku jest agent harmonogramu, któremu wolno uruchamiać procedury, czy kolejkę trzeba dogonić przy pracy użytkowników.
- Adresat i czas - kto ma dostać alert o dokumencie zawieszonym w kolejce i po jakim czasie od wysłania.
- Rozróżnienie wpisów - jak odróżnić wpis, który ERP zdążyło przetworzyć, od wpisu, który naprawdę wisi.
- Poza godzinami - co ma się dziać z alertem poza godzinami pracy, gdy nikt nie wywoła monitora.