Usługa harmonogramu zadań i wywołanie zadania z poziomu transakcji WMS

Opisujemy, jak w jednym wdrożeniu Studio WMS.net zadania integracji z Subiektem GT wykonuje osobna usługa, a nie sam WMS. Nazywamy ją usługą harmonogramu zadań SoftwareStudio, a w tym wdrożeniu nosi nazwę SSSERVICE. Tekst jest napisany dla działu IT i kierownika projektu i dotyczy projektu klienta, a nie standardowego ustawienia produktu.

Usługa uruchamia tory integracji, które opisuje artykuł o trzech niezależnych torach integracji. Stan ich kolejek pomaga ocenić artykuł o diagnostyce kolejki integracji w T-SQL. Inne wdrożenie, w którym formularz wywołuje zadanie usługi bez czekania na wynik, opisuje artykuł o zadaniu uruchamianym z formularza.

Harmonogram poza serwerem aplikacji

Usługa harmonogramu zadań działa poza serwerem aplikacji. To ona uruchamia integrację z Subiektem GT. WMS przekazuje dane do Subiekta wyłącznie przez kolejki w bazie danych, a wybrane zadanie może dodatkowo uruchomić na żądanie. Konfiguracja zadań mieszka po stronie usługi, a nie w bazie WMS. Inne metody wymiany danych z systemem ERP zestawia artykuł o integracji ERP z WMS.

Tabela zestawia wybrane zadania z dokumentu wdrożenia, a nie pełny wykaz. Trzy z nich mają ustawiony harmonogram, a czwarte jest na co dzień wyłączone z harmonogramu.

Pobieranie stanów odbywa się prosto z bazy Subiekta, z pominięciem Sfery, czyli interfejsu programistycznego Subiekta GT. Według dokumentacji wdrożenia czas pobierania stanów zmniejszono z 25-30 do 5-10 sekund, a komunikaty o braku wolnych stanowisk przy odczycie ustały.

Zadanie zdefiniowane na jednym serwerze, wykonywane na drugim

Zadanie może być zdefiniowane na jednym serwerze, a wykonywane zdalnie na drugim, na którym działa proces łączący z Subiektem. Wykonanie zdalne wskazuje trzy parametry: adres usługi, jej port i serwer wykonawczy. Ich wartości w tekście pomijamy.

Skutek widać na liście zadań lokalnych usługi na serwerze wykonawczym. Pokazuje ona wyłącznie zadania systemowe, takie jak sprzątanie logów i historii. Zadania integracji na tej liście nie ma, bo jest zdefiniowane po drugiej stronie.

Definicję zadania widać więc po stronie serwera, na którym je zdefiniowano, a wykonanie po stronie serwera wykonawczego. Osoba, która zagląda tylko do jednej z tych maszyn, zobaczy połowę obrazu.

Brak zadania integracji na liście zadań lokalnych serwera wykonawczego nie świadczy o awarii. Zadanie jest zdefiniowane po drugiej stronie.

Gdzie szukać historii i logów

Tabele usługi w bazie klienta, czyli trzy tabele zadań, historii i logów, są puste. Historii i logów szuka się więc na maszynie, która wykonuje zadania.

Dla działu IT wynika z tego kolejność działań przy zgłoszeniu. Najpierw ustalamy, na której maszynie zadanie jest wykonywane, potem sprawdzamy stan usługi z przeglądarki, a na końcu konfigurację zadania. Puste tabele usługi w bazie klienta nie są objawem awarii.

Usługa udostępnia interfejs WWW API. Pozwala on sprawdzić stan usługi i wyświetlić listę zadań lokalnych, a także uruchomić zadanie zdalnie i pobrać jego logi. Stan samej usługi sprawdza się z przeglądarki.

Odpowiedź ze statusem Ok oznacza tylko, że usługa żyje, a nie że zadanie integracji jest włączone. Tabela zestawia trzy objawy zgłaszane przy diagnozie.

Wywołanie zadania z transakcji

Dokumentacja integracji opisuje wywołanie zadania z JavaScriptu transakcji WMS jako wzorzec. Nie twierdzimy, że opisywany klient z niego korzysta. Wzorzec obejmuje także zadania, które na co dzień są wyłączone z harmonogramu i służą do pobrania pojedynczej informacji na żądanie. Wywołanie przyjmuje cztery parametry.

• Identyfikator zadania - wskazuje zadanie w usłudze.
• Tryb - synchroniczny albo asynchroniczny.
• Zgoda na zadanie nieaktywne - pozwala uruchomić zadanie wyłączone z harmonogramu.
• Słownik parametrów - wartości przekazywane zadaniu.

Komunikat „Unknown web method” przy wywołaniu zadania z parametrami oznacza starszą wersję systemu bez tej metody. Rozwiązaniem jest wymiana wersji, a nie zmiana konfiguracji.

Zadanie na żądanie z parametrami

Przykładem jest stan jednego produktu w jednym magazynie. Parametrami są identyfikator produktu i magazyn. Tryb synchroniczny jest tu istotny, bo wywołanie czeka na wykonanie zadania, żeby transakcja mogła zaraz potem odczytać pobrane dane.

Przy trybie asynchronicznym transakcja dostałaby odpowiedź, zanim zadanie zapisze dane, więc odczyt mógłby trafić na stan sprzed wywołania. Przykład z fikcyjnymi danymi, zgodny ze wzorcem: transakcja wywołuje zadanie dla produktu o identyfikatorze 1001 i magazynu MAG-A w trybie synchronicznym, a po jego zakończeniu odczytuje pobrane dane.

Wywołanie na żądanie różni się od zadania z harmonogramu momentem uruchomienia. Harmonogram uruchamia zadanie o ustalonej porze, a transakcja prosi o jedną informację w chwili, gdy jest potrzebna.

Dlaczego brak zmiany w wierszu jest prawidłowy

Zadanie liczy skrót pobranej informacji. Przy zgodności skrótu nie rusza wiersza, także daty ostatniej modyfikacji. Powtórne uruchomienie dla niezmienionego stanu nie zostawia więc śladu w danych, i jest to zachowanie prawidłowe.

Brak zmiany daty w wierszu nie znaczy, że zadanie się nie wykonało. Przy sprawdzaniu, czy zadanie zadziałało, patrzymy dlatego na logi na serwerze wykonawczym, a nie na datę w wierszu.

Dla projektu oznacza to, że odbiór zadania opisujemy przez logi i wynik wywołania, a nie przez zmianę wiersza w danych.

Pytania do zadania na etapie analizy

Przed wdrożeniem usługi harmonogramu zadajemy cztery pytania. To pytania, a nie fakty o opisywanym wdrożeniu. Odpowiedzi zapisuje się w analizie, której zakres opisuje artykuł o analizie przedwdrożeniowej WMS.

• Gdzie zdefiniowano zadanie - na którym serwerze i który serwer je wykonuje.
• Które zadania działają na żądanie - czy mają być wyłączone z harmonogramu.
• Czy transakcja czeka na wynik - tryb synchroniczny czy asynchroniczny.
• Gdzie szukamy logów - na której maszynie i kto ma do niej dostęp.

Czego ta strona nie opisuje

Strona nie podaje adresów, portów, nazw serwerów ani identyfikatorów zadań. Nie pokazujemy też kodu wywołania. Nie twierdzimy, że zadania integracji w konkretnym magazynie działają albo stoją: czy zadanie jest włączone, sprawdza się w konfiguracji usługi, a nie w odpowiedzi o jej stanie.

Błędy wysyłki dokumentów i ich ponowienia opisuje artykuł o klasyfikacji błędów w T-SQL, a samą wysyłkę dokumentów artykuł o eksporcie dokumentów magazynowych do Subiekta GT.