W opisywanym wdrożeniu system WMS nie rozmawia z Subiektem GT bezpośrednio. Zapisuje zadanie do kolejki w bazie danych, a osobny proces po stronie serwera Subiekta odbiera je i wykonuje przez Sferę, czyli interfejs programistyczny Subiekta GT. Z tej zasady wynikają trzy niezależne tory wymiany danych.
Opisujemy to na przykładzie systemu Studio WMS.net. Ogólną zasadę zapisu dokumentu do kolejki zamiast wysyłki wprost opisuje strona o integracji systemu magazynowego z ERP. Tutaj pokazujemy jej odmianę dla Subiekta GT: własne kolejki i różne drogi odczytu oraz zapisu.
Trzy tory zamiast jednego
Integracja ma trzy niezależne tory. Pierwszy przenosi dokumenty magazynowe z WMS do Subiekta. Drugi sprowadza z Subiekta do WMS dokumenty i stany. Trzeci wysyła z WMS do Subiekta kartoteki towarowe.
Każdy tor ma własną kolejkę i własne zadania w harmonogramie. Awaria jednego toru nie zatrzymuje pozostałych, więc kłopot z kartotekami nie wstrzymuje wysyłki dokumentów magazynowych.
| Tor | Kierunek | Co przesyła |
|---|---|---|
| Dokumenty magazynowe | WMS do Subiekta | Dokumenty z kolejki nagłówków i pozycji |
| Import dokumentów i stanów | Subiekt do WMS | Dokumenty i stany magazynowe odczytane z Subiekta do lustra w bazie WMS |
| Kartoteki towarowe | WMS do Subiekta | Dodawanie i aktualizacja towarów z kolejki kartotek |
WMS zapisuje zadanie do kolejki, a wykonuje je osobny proces po stronie Subiekta. Awaria jednego toru nie zatrzymuje pozostałych.
Zadania torów są osobne. Zadanie wysyłki kartotek jest aktywne w harmonogramie, a wieczorem osobna procedura kolejkuje kartoteki do wysłania. Pobieranie dokumentów z Subiekta to inne zadanie. Każdy tor można więc oceniać osobno, patrząc na jego kolejkę.
Niezależne znaczy tu: osobna kolejka i własne zadania w harmonogramie. Dokument magazynowy czeka na własną kolejkę, a nie na zakończenie importu stanów albo wysyłki kartotek. Przy każdej rozbieżności między programami pierwsze pytanie brzmi więc, którym torem dana informacja przechodzi.
Kolejka w bazie zamiast połączenia bezpośredniego
Zadania do wykonania leżą w tabelach kolejek w bazie danych WMS. Kolejki wychodzące służą do wysyłki do Subiekta, a tabele lustra są kopiami danych Subiekta odczytywanymi przez WMS. Obok nich są tabele sterujące, na przykład ponowień i wzorców błędów.
Kolejka dokumentów ma dwie tabele: nagłówki i pozycje. Pozycja wskazuje swój nagłówek przez identyfikator zewnętrzny, którym jest numer referencyjny dokumentu w WMS. W przykładzie dokument o numerze referencyjnym 1001 ma jeden nagłówek i dwie pozycje, a obie pozycje niosą identyfikator zewnętrzny 1001. Numer jest wymyślony.
Wiersz kolejki jest zamrożonym obrazem danych z chwili zapisu. Nie pokazuje bieżącego stanu kartoteki ani dokumentu, więc późniejsza zmiana w WMS nie poprawia wiersza, który już czeka w kolejce.
Zadania uruchamia usługa harmonogramu działająca poza serwerem aplikacji WMS. WMS przekazuje dane do Subiekta wyłącznie przez kolejki w bazie danych. Zadania wykonuje usługa harmonogramu, a WMS może dodatkowo uruchomić wybrane zadanie na żądanie. Samą usługę i wywołanie zadania z transakcji opisuje artykuł o usłudze harmonogramu zadań.
Odczyt przez SQL, zapis przez Sferę
Dane z Subiekta WMS odczytuje bezpośrednio z jego bazy SQL, z pominięciem Sfery. Odczyt nie zajmuje więc stanowiska licencyjnego. Zapis do Subiekta zawsze wymaga Sfery i wolnego stanowiska.
Skutek tej asymetrii jest taki, że wysyłka potrzebuje stanowiska licencyjnego i bywa wrażliwa na zajętą licencję. Zajęte stanowisko Sfery i przekroczony limit licencji należą do błędów, które integracja traktuje jako tymczasowe. Zasady ponawiania opisuje artykuł o klasyfikacji błędów i ponowieniach wysyłki.
Dokumenty i stany, które WMS odczytuje z bazy Subiekta, trafiają do lustra danych w bazie WMS. Stany magazynowe w samym programie opisuje strona o stanach magazynowych.
Znacznik przetwarzania w wierszu kolejki
Każdy wiersz kolejki ma znacznik przetwarzania. Wartość 0 oznacza oczekiwanie, 1 oznacza, że wiersz wysłano, a -1 oznacza błąd. Treść błędu trafia do kolumny statusu.
| Znacznik | Znaczenie | Co dzieje się z wierszem |
|---|---|---|
| 0 | Oczekiwanie | Wiersz czeka na wysyłkę do Subiekta |
| 1 | Wysłano | Zadanie zostało wykonane po stronie Subiekta |
| -1 | Błąd | Treść błędu jest w kolumnie statusu |
W przykładzie dokument WZ o numerze referencyjnym 1001 zapisuje się do kolejki ze znacznikiem 0. Gdy proces po stronie Subiekta wykona zadanie, znacznik zmienia się na 1. Gdyby wykonanie się nie powiodło, znacznik miałby wartość -1, a w kolumnie statusu pojawiłaby się treść błędu. Numer jest wymyślony.
Znacznik pokazuje w samej kolejce, które wiersze czekają, które wysłano i które zakończyły się błędem. Pięć zapytań, którymi tę kolejkę się diagnozuje, opisuje artykuł o diagnostyce kolejki integracji w T-SQL.
Dokumenty trafiające do tej kolejki powstają w procedurach eksportu, które opisuje artykuł o eksporcie dokumentów magazynowych do Subiekta GT. Rodzaje dokumentów, które WMS prowadzi, zestawia strona o dokumentach magazynowych.
Tor, który jest wyłączony celowo
Poza trzema opisanymi torami istnieje tor kontrahentów, ale jest wyłączony celowo. Kontrahenci nie należą do zakresu integracji, a pobieranie ich przez Sferę kończyło się błędami na nazwach ze znakami specjalnymi.
Wyłączony tor jest decyzją o zakresie, a nie usterką. Do Subiekta trafiają natomiast kartoteki towarowe, które obsługuje trzeci tor, a ich pola opisuje strona o kartotekach w systemie WMS.
Granica zakresu ma znaczenie przy planowaniu. Kto zamierza przenosić kontrahentów między programami, musi to uzgodnić poza torami opisanymi na tej stronie.
Pytania przed projektem integracji z Subiektem GT
Poniższe pytania nie są faktami o opisywanym wdrożeniu. Pomagają przygotować analizę przedwdrożeniową, którą opisuje artykuł o analizie przedwdrożeniowej WMS.
- Zakres. Które dokumenty magazynowe mają trafiać do Subiekta, a które zostają tylko w WMS?
- Kartoteki. Czy towary mają być zakładane w WMS i wysyłane do Subiekta, czy odwrotnie?
- Licencje. Ile stanowisk Sfery będzie wolnych w porach wysyłki dokumentów?
- Kontrahenci. Czy wystarczy numer kontrahenta w kartotece, czy trzeba przenosić całą kartotekę?
Granice tego opisu
Strona opisuje mechanizm, a nie wyniki. Nie podajemy liczby wierszy w kolejkach, dat ostatniego ruchu ani nazw obiektów w bazie. Nie twierdzimy też, że integracja działa bez awarii. Nie opisujemy bieżącego stanu poszczególnych torów w opisywanym wdrożeniu, tylko ich zasadę działania.