Program WMS.net rozpatrywany od strony działu IT to przede wszystkim architektura, wymagania infrastrukturalne i sposób licencjonowania, a nie lista funkcji magazynowych. Ten materiał opisuje specyfikację techniczną Studio WMS.net - model klient-serwer, wymagania systemowe, silnik raportowy, możliwości dostosowania oraz integracji przez API. Ogólny przegląd funkcji produktowych, takich jak ewidencja zapasów czy obsługa dokumentów magazynowych, opisuje strona Studio WMS.net - oprogramowanie do zarządzania magazynem, natomiast poniższy tekst koncentruje się wyłącznie na warstwie technicznej, którą przed decyzją wdrożeniową musi ocenić administrator systemów lub kierownik IT.
Architektura klient-serwer programu WMS.net
WMS.net zbudowany jest w architekturze klient-serwer - centralny serwer aplikacji wraz z bazą danych obsługuje wielu użytkowników jednocześnie, a stacje robocze, przeglądarki i urządzenia mobilne pełnią rolę klientów łączących się z tym serwerem. Taki podział pozwala utrzymać jedno, spójne źródło danych o stanach magazynowych, niezależnie od tego, z jakiego miejsca i jakiego urządzenia korzysta operator w danym momencie.
W praktyce oznacza to, że logika biznesowa - reguły dotyczące rezerwacji towaru, kolejności kompletacji czy weryfikacji dokumentów - wykonywana jest po stronie serwera, a nie na poszczególnych stacjach klienckich. Dzięki temu aktualizacja reguł biznesowych wymaga zmiany w jednym miejscu, a nie na każdym komputerze z osobna, co upraszcza zarządzanie środowiskiem przy większej liczbie stanowisk.
Warstwa serwera aplikacji i baza danych Microsoft SQL Server
Serwer aplikacji WMS.net oparty jest na technologii Microsoft ASP.net, a dane przechowywane są w bazie Microsoft SQL Server. To ta warstwa odpowiada za przetwarzanie dokumentów magazynowych, aktualizację stanów oraz udostępnianie danych raportom i modułom integracyjnym. Szczegółowy opis architektury bazodanowej i sposobu, w jaki system magazynowy SQL obsługuje duże wolumeny transakcji, znajduje się w osobnym materiale poświęconym tej warstwie.

Instancja bazy danych może działać na dedykowanym serwerze fizycznym, maszynie wirtualnej lub w środowisku chmurowym udostępnionym przez dostawcę infrastruktury. Wybór platformy zależy od polityki bezpieczeństwa danych obowiązującej w firmie oraz od tego, czy dział IT preferuje pełną kontrolę nad sprzętem, czy przeniesienie odpowiedzialności za utrzymanie serwera na zewnątrz.
Warstwa klienta - stacja robocza, przeglądarka i urządzenia mobilne
Po stronie klienta WMS.net udostępnia trzy warianty dostępu do tych samych danych. Stacja robocza z zainstalowaną wersją Framework łączy się bezpośrednio z serwerem aplikacji, przeglądarka internetowa korzysta z wersji web bez instalacji lokalnej, a terminal lub skaner z systemem Android obsługuje operacje magazynowe w czasie rzeczywistym z poziomu hali. Każdy z tych klientów odczytuje i zapisuje dane w tej samej bazie, więc zmiana wprowadzona na skanerze jest natychmiast widoczna na stacji biurowej.
Wymagania systemowe i specyfikacja infrastruktury
Przed przystąpieniem do wdrożenia dział IT powinien zweryfikować dostępną infrastrukturę pod kątem poniższych wymagań. Poniższe zestawienie porządkuje specyfikację techniczną poszczególnych warstw systemu.
| Wymaganie | Specyfikacja |
|---|---|
| Serwer aplikacji | Windows Server, procesor minimum 4-rdzeniowy, 8 GB RAM (zalecane 16 GB przy większej liczbie stanowisk) |
| Baza danych | Microsoft SQL Server 2012 lub nowszy, edycja Standard lub Express dla mniejszych wdrożeń |
| Stacja robocza (wersja Framework) | Windows 10 lub 11, .NET Framework 3.5 lub nowszy, minimum 4 GB RAM |
| Dostęp przez przeglądarkę | Aktualna wersja Chrome, Edge lub Firefox, stałe łącze do serwera aplikacji |
| Urządzenia mobilne | Terminale i skanery z systemem Android, sieć WiFi w obrębie magazynu |
| Sieć | Sieć lokalna (LAN) lub łącze internetowe o odpowiednim paśmie, zależnie od modelu wdrożenia |
| Silnik raportowy | SQL Server Reporting Services, definicje raportów w formacie RDL |
| Szyfrowanie transmisji | Protokół SSL/TLS między stacją kliencką a serwerem aplikacji |
Skala tych wymagań rośnie wraz z liczbą jednoczesnych użytkowników oraz wolumenem dokumentów przetwarzanych dziennie. Magazyn obsługujący kilkanaście stanowisk poradzi sobie na jednym serwerze średniej klasy, natomiast sieć wielomagazynowa z integracją ERP i rozbudowaną kompletacją wymaga infrastruktury dobranej indywidualnie podczas analizy przedwdrożeniowej.
Model licencjonowania - licencja na stanowisko czy na serwer
SoftwareStudio udostępnia dwa podstawowe modele licencjonowania programu WMS.net, a wybór między nimi ma bezpośredni wpływ na koszt utrzymania systemu w kolejnych latach. Licencja na stanowisko rozliczana jest według liczby jednoczesnych użytkowników korzystających z aplikacji - sprawdza się w magazynach o ograniczonej, przewidywalnej liczbie stanowisk. Licencja na serwer obejmuje nieograniczoną liczbę stanowisk w ramach jednej instalacji, co bywa korzystniejsze w dużych magazynach z pracą zmianową, gdzie liczba jednoczesnych użytkowników zmienia się w ciągu doby.
Dział IT powinien uwzględnić w analizie nie tylko bieżącą liczbę stanowisk, lecz również plany rozwoju magazynu - dodanie kolejnych użytkowników w modelu licencji na stanowisko wiąże się z dokupieniem licencji, natomiast w modelu serwerowym rozbudowa floty stanowisk nie zmienia kosztu licencyjnego. Ostateczny dobór modelu ustalany jest podczas analizy przedwdrożeniowej wspólnie z zespołem SoftwareStudio.
Silnik raportowy i wydruki w formacie RDL
Raportowanie w WMS.net oparte jest na SQL Server Reporting Services, a definicje poszczególnych raportów i wydruków przechowywane są w formacie RDL (Report Definition Language) - standardowym formacie XML opisującym układ, źródło danych i formatowanie dokumentu. Taka architektura pozwala działowi IT samodzielnie modyfikować istniejące wydruki lub tworzyć nowe zestawienia w narzędziu Report Builder, bez ingerencji w kod aplikacji i bez udziału programisty przy każdej drobnej zmianie układu dokumentu.

SoftwareStudio zaleca przechowywanie kopii plików RDL w bezpiecznym folderze na dysku NTFS, poza samą instancją serwera raportów - w razie awarii lub migracji środowiska pozwala to na szybkie ponowne opublikowanie wszystkich raportów bez odtwarzania ich od podstaw. Silnik raportowy obsługuje zarówno standardowe wydruki dokumentów magazynowych, jak i analityczne zestawienia stanów, rotacji czy wartości zapasu, generowane na żądanie lub według harmonogramu.
Możliwości dostosowania i API do integracji z innymi systemami
Warstwa konfiguracyjna WMS.net pozwala dostosować strukturę lokalizacji, kartotek, dokumentów i uprawnień do procesów danej firmy bez modyfikacji kodu źródłowego aplikacji - szczegóły tego procesu opisuje strona konfiguracja programu magazynowego. Dla działu IT istotniejsza bywa jednak warstwa integracyjna, ponieważ to ona decyduje, czy WMS.net da się osadzić w istniejącym ekosystemie systemów firmy bez budowy kosztownych mostków pośredniczących.

Program udostępnia mechanizmy integracyjne oparte na usługach sieciowych, pozwalające na automatyczną, dwukierunkową wymianę danych z systemami zewnętrznymi - zamówień, kartotek towarowych, stanów magazynowych i dokumentów. Zakres udostępnianych metod ustala się indywidualnie podczas analizy technicznej, dopasowując je do formatu danych i możliwości systemu, z którym WMS.net ma współpracować. Więcej o ogólnych zasadach łączenia różnych platform opisuje strona integracja systemów magazynowych.
Integracja z systemami ERP i SAP na poziomie technicznym
Najczęstszym scenariuszem integracyjnym pozostaje połączenie z nadrzędnym systemem ERP - WMS.net przekazuje do niego dane o przyjęciach, wydaniach i bieżących stanach magazynowych, a pobiera z niego zamówienia, zlecenia produkcyjne i kartoteki towarowe. W środowiskach korzystających z systemu SAP integracja wymaga dodatkowego uzgodnienia formatu wymiany komunikatów i harmonogramu synchronizacji - techniczne aspekty takiego połączenia opisuje strona integracja programu magazynowego z SAP. Niezależnie od docelowego systemu ERP, integracja odbywa się automatycznie, bez podwójnego wprowadzania tych samych danych przez pracowników dwóch różnych działów.
Wersja Framework jako architektura desktopowa
Wersja Framework to wariant WMS.net instalowany lokalnie na stacji roboczej, zbudowany na bibliotekach .NET Framework 3.5 i pracujący w interfejsie nawiązującym do pakietu Office. Z punktu widzenia architektury jest to aplikacja desktopowa, która po uruchomieniu nawiązuje stałe połączenie z serwerem aplikacji i pobiera z niego dane w czasie rzeczywistym, zamiast przechowywać własną, lokalną kopię bazy danych.

Taka konstrukcja pozwala na pracę wielookienkową - operator otwiera równocześnie kilka dokumentów lub kartotek i przełącza się między nimi bez utraty kontekstu, podobnie jak w arkuszu kalkulacyjnym. Dla działu IT oznacza to konieczność instalacji i aktualizacji komponentu klienckiego na każdej stacji roboczej, w odróżnieniu od wersji web, gdzie aktualizacja aplikacji wykonywana jest wyłącznie po stronie serwera i obejmuje wszystkich użytkowników jednocześnie.
Bezpieczeństwo, szyfrowanie i zarządzanie dostępem
Komunikacja pomiędzy stacją kliencką a serwerem aplikacji zabezpieczona jest protokołem SSL/TLS, co chroni dane logowania oraz informacje magazynowe przed przechwyceniem podczas transmisji. WMS.net można również zsynchronizować z Active Directory, czyli firmową domeną - w takim modelu baza danych programu nie przechowuje haseł użytkowników, a autoryzacja odbywa się na poziomie kont domenowych zarządzanych centralnie przez dział IT.
Uprawnienia w systemie przydzielane są na poziomie modułów i poszczególnych operacji, co pozwala administratorowi ograniczyć dostęp do funkcji wrażliwych, na przykład korekt stanów magazynowych czy zmiany konfiguracji, wyłącznie do wybranej grupy pracowników. Taki podział ról ułatwia audyt bezpieczeństwa i spełnienie wewnętrznych polityk dotyczących dostępu do danych.
Przed wyborem modelu licencjonowania i wariantu wdrożenia warto zestawić listę systemów, z którymi WMS.net ma się integrować - zakres i format wymaganych połączeń API często decyduje o tym, ile czasu zajmie faza analizy technicznej.
Wdrożenie z perspektywy działu IT - etapy prac
Z technicznego punktu widzenia wdrożenie WMS.net przebiega w kilku uporządkowanych etapach, niezależnie od wybranego modelu licencjonowania i wariantu klienta.
- Audyt infrastruktury - zespół IT wspólnie z SoftwareStudio weryfikuje dostępne zasoby serwerowe, sieciowe i sprzętowe względem wymagań systemowych programu.
- Przygotowanie środowiska - instalacja systemu operacyjnego serwera, bazy Microsoft SQL Server oraz konfiguracja uprawnień sieciowych i kont serwisowych.
- Instalacja aplikacji WMS.net - wdrożenie warstwy serwera aplikacji oraz, w zależności od wybranego wariantu, komponentów klienckich wersji Framework.
- Konfiguracja integracji - uruchomienie mechanizmów wymiany danych z systemem ERP lub innymi platformami zewnętrznymi przez API.
- Testy wydajnościowe i bezpieczeństwa - weryfikacja działania systemu pod obciążeniem oraz poprawności szyfrowania transmisji między klientem a serwerem.
- Uruchomienie produkcyjne i dokumentacja - dział IT klienta otrzymuje pełną dokumentację architektury wdrożonego środowiska oraz procedury administracyjne.
Pełny opis organizacyjnej strony tego procesu, obejmujący harmonogram, szkolenia i migrację danych, znajduje się na stronie wdrożenie systemu WMS. Firmy, które zamiast infrastruktury lokalnej rozważają wariant chmurowy z funkcjami automatyzacji zapasów, znajdą odrębne omówienie tej ścieżki na stronie programu WMS online - architektura opisana w niniejszym materiale dotyczy przede wszystkim wdrożeń on-premise oraz hybrydowych, zarządzanych bezpośrednio przez dział IT klienta.




