Program internetowy WWW do zarządzania magazynem - jak działa cienki klient

Program internetowy WWW do zarządzania magazynem działa wyłącznie w przeglądarce. Nie wymaga instalacji na stacji roboczej ani lokalnego pliku wykonywalnego. Użytkownik otwiera adres systemu jak stronę internetową. Po zalogowaniu pracuje na aktualnych danych. SoftwareStudio buduje takie rozwiązania w technologii ASP.NET z bazą danych Microsoft SQL Server, która przechowuje stany i dokumenty.

Ten artykuł wyjaśnia mechanikę takiego programu: co dzieje się między kliknięciem a odpowiedzią, jak system rozpoznaje użytkownika i czym wersja webowa różni się od aplikacji instalowanej lokalnie. Wybór modelu hostingu opisuje osobny tekst o programie magazynowym w chmurze i on-premise.

Jak działa program internetowy WWW w przeglądarce

W klasycznym programie desktopowym logika aplikacji i część danych znajdują się na dysku stacji roboczej, więc każdą instalację trzeba osobno konfigurować i aktualizować. Program internetowy odwraca ten układ. Logika biznesowa i reguły magazynowe oraz baza danych działają na serwerze, a przeglądarka pełni rolę okna, które wyświetla interfejs i wysyła żądania.

Weźmy potwierdzenie pobrania towaru z lokalizacji w trakcie kompletacji. Operator klika przycisk, a przeglądarka wysyła żądanie do serwera protokołem HTTPS. Serwer sprawdza dostępność towaru w bazie, zapisuje ruch magazynowy i odsyła widok kolejnej pozycji. Poniższa tabela rozkłada ten cykl na kroki.

Cały cykl trwa zwykle ułamek sekundy. Użytkownik nie widzi, że dane dwukrotnie przebyły łącze między jego urządzeniem a serwerem. Podstawy protokołu, na którym opiera się ta wymiana, opisuje przegląd HTTP w dokumentacji MDN.

Zapytanie AJAX z przeglądarki

Odświeżenie fragmentu ekranu bez przeładowania strony zapewnia technika AJAX. Skrypt w przeglądarce wysyła żądanie w tle i po odpowiedzi podmienia tylko zmieniony element. Przykład w jQuery pokazuje, jak zablokować przycisk na czas operacji, by użytkownik nie wysłał tego samego potwierdzenia dwa razy.

// przykład: potwierdzenie pobrania bez przeładowania strony
$('#potwierdz').on('click', function () {
  var $przycisk = $(this).prop('disabled', true);
  $.ajax({
    url: '/api/kompletacja/potwierdz',
    method: 'POST',
    contentType: 'application/json',
    data: JSON.stringify({ idPozycji: 1042, ilosc: 6 })
  })
  .done(function (wynik) { pokazPozycje(wynik.nastepna); })
  .fail(function (xhr) { pokazBlad(xhr.responseJSON.komunikat); })
  .always(function () { $przycisk.prop('disabled', false); });
});

Blokada przycisku chroni przed podwójnym kliknięciem po stronie przeglądarki, ale nie zastępuje kontroli na serwerze. Ostateczną ochroną przed duplikatem jest logika w bazie danych, którą pokazuje kolejny przykład. Adres i nazwy w obu fragmentach są ilustracyjne i nie opisują interfejsu konkretnego produktu.

Transakcja po stronie bazy danych

Serwer nie powinien składać operacji z kilku niezależnych poleceń, bo przerwanie w środku zostawiłoby dane w stanie pośrednim. Zapis ruchu i zmiana stanu powinny należeć do jednej transakcji. Procedura składowana w T-SQL zapewnia to w jednym miejscu, niezależnie od tego, z jakiego urządzenia przyszło żądanie.

-- przykład: potwierdzenie pobrania w jednej transakcji
CREATE PROCEDURE dbo.PotwierdzPobranie
    @IdPozycji int, @Ilosc decimal(18,3), @IdUzytkownika int
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;
    BEGIN TRANSACTION;

    UPDATE s SET s.Ilosc = s.Ilosc - @Ilosc
    FROM dbo.StanLokalizacji AS s
    JOIN dbo.PozycjaKompletacji AS p
      ON p.IdLokalizacji = s.IdLokalizacji AND p.Indeks = s.Indeks
    WHERE p.Id = @IdPozycji AND s.Ilosc >= @Ilosc;

    IF @@ROWCOUNT = 0
    BEGIN
        ROLLBACK TRANSACTION;
        THROW 50001, N'Brak wystarczającego stanu na lokalizacji.', 1;
    END;

    INSERT dbo.DziennikOperacji (IdUzytkownika, IdPozycji, Ilosc, Czas)
    VALUES (@IdUzytkownika, @IdPozycji, @Ilosc, SYSDATETIME());
    COMMIT TRANSACTION;
END;

Dzięki opcji XACT_ABORT ewentualny błąd wykonania wycofuje całą transakcję, a warunek w klauzuli WHERE chroni stan przed zejściem poniżej zera. Mechanizm działa tak samo dla komputera biurowego i terminala na hali, ponieważ cała logika mieszka na serwerze.

Model cienkiego klienta w architekturze webowej

Taki podział pracy nazywa się modelem cienkiego klienta. Stacja robocza nie przechowuje ani nie przetwarza danych magazynowych, tylko renderuje interfejs przesłany przez serwer. Dwa komputery o bardzo różnej mocy obsłużą ten sam program z podobną wydajnością, o ile mają stabilne połączenie.

Model cienkiego klienta różni się od wersji Framework, w której aplikacja instaluje się lokalnie i łączy z bazą danych ze stacji roboczej. W wersji webowej nowa funkcja trafia do wszystkich użytkowników w chwili wdrożenia na serwerze. W instalacji lokalnej każde stanowisko działa niezależnie, więc dwa komputery mogą przez pewien czas pracować na różnych wersjach tego samego modułu.

Jedna wersja i wdrożenie na serwerze

Jedno miejsce wdrożenia zamiast wielu kopii programu ułatwia także testowanie. Nową funkcję sprawdza się raz, na jednym środowisku serwerowym, a nie na wielu konfiguracjach sprzętowych klientów. Dla użytkownika oznacza to brak instalatorów i brak pytań o wersję, a dla administratora jedną kopię konfiguracji do pilnowania.

Sesja i uprawnienia użytkownika

Protokół HTTP nie przechowuje informacji między żądaniami, więc serwer rozpoznaje użytkownika po identyfikatorze sesji przekazywanym w ciasteczku. Mechanizm ten opisuje dokumentacja MDN o ciasteczkach HTTP. Po zalogowaniu serwer tworzy sesję, a każde kolejne żądanie sprawdza jej ważność i rolę konta.

Komunikację między przeglądarką a serwerem szyfruje HTTPS, co uniemożliwia odczytanie i podmianę danych w trakcie transmisji. Dostęp wymaga indywidualnego loginu i hasła, a zakres uprawnień odpowiada roli w strukturze magazynu. Operator kompletacji nie zobaczy zestawień finansowych przeznaczonych dla kierownika. Szczegóły kont i ról opisują artykuły o logowaniu i autoryzacji oraz o rolach i użytkownikach systemu WMS.

Reguła: uprawnienia weryfikuje serwer przy każdym żądaniu, a nie interfejs. Ukrycie przycisku w przeglądarce nie jest zabezpieczeniem, bo żądanie można wysłać ręcznie.

Dziennik operacji i wygasanie sesji

Sesja wygasa automatycznie po okresie bezczynności, co ogranicza ryzyko pozostawienia otwartego systemu na współdzielonym stanowisku. Przy terminalach używanych przez kilku operatorów warto skrócić ten czas w ustawieniach systemu. Zmniejsza to szansę wprowadzenia danych na cudzym koncie.

Każda operacja magazynowa, na przykład przyjęcie lub korekta stanu, trafia do bazy ze znacznikiem czasu i identyfikatorem użytkownika. Zapis działa niezależnie od urządzenia: operacja z tabletu na hali zostawia taki sam ślad jak operacja z komputera biurowego. W razie rozbieżności w stanach administrator ustala, kto i kiedy wprowadził zmianę, bez przeszukiwania dokumentów papierowych.

Wydajność list i stronicowanie po stronie serwera

Kartoteka towarowa albo lista dokumentów może liczyć setki tysięcy wierszy. Przeglądarka nie powinna pobierać ich naraz, bo wydłuży to czas odpowiedzi i zużyje pamięć urządzenia. Program internetowy zwraca więc jedną stronę wyników, a filtrowanie i sortowanie wykonuje baza danych, która ma do tego indeksy. Użytkownik widzi ekran po ułamku sekundy niezależnie od wielkości zbioru.

-- przykład: pięćdziesiąt kolejnych pozycji kartoteki dla wybranej strony
SELECT k.Indeks, k.Nazwa, k.JednostkaMiary
FROM dbo.Kartoteka AS k
WHERE k.Indeks LIKE @Fraza + N'%'
ORDER BY k.Indeks
OFFSET @Strona * 50 ROWS FETCH NEXT 50 ROWS ONLY;

Wzorzec zaczynający się od stałego prefiksu może skorzystać z indeksu po kolumnie Indeks. Wzorzec zaczynający się od znaku wieloznacznego zmusza bazę do przeglądu całej tabeli. Ta różnica tłumaczy, czemu wyszukiwanie po początku symbolu bywa szybsze niż wyszukiwanie po dowolnym fragmencie. Tabela i kolumny w przykładzie są ilustracyjne.

Reguła: liczbę wierszy w odpowiedzi ogranicza serwer, a nie przeglądarka. Filtr wykonany dopiero po pobraniu danych oznacza, że cały zbiór przeszedł przez łącze.

Dostęp z różnych urządzeń i lokalizacji

Jedynym wymaganiem po stronie użytkownika jest przeglądarka, więc z programu korzysta się z komputera biurowego oraz z laptopa. Działają też tablet i terminal mobilny z systemem Android, bez różnic w funkcjach. Kierownik magazynu sprawdza stany magazynowe ze smartfonu podczas rozmowy z dostawcą, a dyrektor operacyjny przegląda raporty z domu w tej samej przeglądarce co w biurze.

Zasada obejmuje także oddziały rozproszone geograficznie. Każda lokalizacja loguje się do wspólnego systemu i nie potrzebuje osobnej kopii programu. Zespoły pracujące zdalnie korzystają z danych bez konfigurowania tunelu VPN do aplikacji desktopowej, bo dostęp kontroluje sam system.

Program internetowy WWW a aplikacja desktopowa

Wybór między dostępem przez przeglądarkę a instalacją lokalną zależy od stanowiska i infrastruktury firmy. Zestawienie porządkuje różnice między architekturami.

Żadna z architektur nie jest lepsza uniwersalnie. Program internetowy wygrywa tam, gdzie liczy się dostęp z wielu miejsc i minimalna obsługa stanowisk. Wersja Framework sprawdza się przy intensywnej pracy wielookienkowej na jednym stanowisku. Część firm używa obu wariantów: operatorzy na hali pracują w przeglądarce, a księgowość korzysta z wersji Framework przy rozliczeniach wymagających otwarcia wielu dokumentów naraz.

Wymagania techniczne stanowiska w przeglądarce

Uruchomienie programu nie wymaga przygotowania stanowiska w sposób znany z instalacji tradycyjnego oprogramowania. Potrzebne są cztery elementy.

• Aktualna przeglądarka - Chrome albo Edge, a także każda inna przeglądarka zgodna ze standardami HTML5, bez wtyczek.
• Stabilne połączenie z Internetem - przepustowość wystarczająca do przesyłania zapytań i wyników, bez wymogu łącza o wysokiej prędkości.
• Konto z rolą - login i hasło tworzy administrator, przypisując uprawnienia odpowiednie do stanowiska pracy.
• Urządzenia peryferyjne - ewentualna integracja z lokalną drukarką etykiet lub skanerem kodów kreskowych podłączonym do stanowiska.

Poza urządzeniami peryferyjnymi nie trzeba instalować sterowników ani dodatkowego oprogramowania. Dokumenty magazynowe, kartoteki i raporty działają bezpośrednio w oknie przeglądarki. Przegląd urządzeń mobilnych używanych z systemami WMS zawiera materiał o terminalach radiowych w serwisie SoftwareStudio.

Zastosowania programu internetowego WWW w logistyce

Architektura webowa pasuje do firm o różnym profilu, które łączy potrzeba dostępu do jednego systemu z wielu miejsc jednocześnie.

• Sklepy internetowe bez własnego magazynu - obsługa zamówień i operacji magazynowych zdalnie, z dowolnego miejsca z dostępem do Internetu.
• Firmy wielooddziałowe - centralny wgląd w stany wielu lokalizacji z jednej przeglądarki, bez osobnej kopii systemu w każdym oddziale.
• Operatorzy logistyczni 3PL - klienci logują się do własnego widoku stanów bez dostępu do danych pozostałych kontrahentów.
• Zespoły zdalne i hybrydowe - kierownicy i dział zakupów sprawdzają dane spoza siedziby firmy.

Integracja z systemami ERP i platformami sprzedażowymi

Program internetowy nie działa w oderwaniu od reszty narzędzi firmy. Integruje się z systemami ERP, takimi jak SAP, Comarch Optima czy Microsoft Dynamics, oraz z platformami sprzedażowymi przez REST API i Web Services. Zamówienie ze sklepu trafia do kolejki kompletacji, a po nadaniu przesyłki status aktualizuje się w programie magazynowym i na platformie sprzedażowej bez ręcznego przepisywania. Techniczne strony takiej wymiany omawia artykuł o integracji WMS z ERP przez REST i kolejki.

Wdrożenie warto poprzedzić rozmową o wymaganiach dotyczących konfiguracji oraz o modelu hostingu, czyli o serwerach dostawcy lub o infrastrukturze klienta. Różnice tych modeli, w tym odpowiedzialność za serwery i kopie zapasowe, opisuje strona o magazynie w chmurze. Działanie systemu można sprawdzić w demo online.