Instalacja i konfiguracja przewodnik techniczny
System VSS.net (Yard Management System – YMS) obsługuje awizacje transportów, zarządzanie oknami czasowymi i ruch na placu manewrowym. Jego prawidłowe wdrożenie wymaga przygotowania infrastruktury serwerowej, konfiguracji uprawnień oraz integracji z systemami zewnętrznymi. Niniejszy przewodnik skierowany jest do administratorów IT odpowiedzialnych za instalację i konfigurację aplikacji w środowisku produkcyjnym.
Faza przygotowania – analiza wymagań
Przed wdrożeniem systemu VSS.net zespół IT musi przeprowadzić analizę wymagań biznesowych oraz technicznych. Kluczowe pytania to: ilu użytkowników będzie korzystać z systemu, jakie moduły funkcjonalne są niezbędne (np. awizacja dostawców, okna czasowe, raporty załadunków), czy wymagana jest integracja z systemem ERP (SAP, Dynamics, Enova) i czy magazyn dysponuje bramką do pomiaru czasu przyjazdu przewoźników.
SoftwareStudio prowadzi kick-off meeting, na którym definiuje się liczbę stanowisk operacyjnych, waliduje się harmonogram wdrożenia oraz ustalane są Service Level Agreements (SLA) dla wsparcia powdrożeniowego. Równolegle zespół dokonuje audytu infrastruktury IT – sprawdzenia dostępnych zasobów serwerowych, przepustowości sieci i istniejącej polityki bezpieczeństwa.
Wymagania sprzętowe serwera aplikacyjnego (IIS)
System VSS.net wymaga dedykowanego serwera aplikacyjnego z zainstalowanym usługą IIS (Internet Information Services). Minimalne wymagania sprzętowe to Windows Server 2019 Standard lub nowszy (zalecane Windows Server 2022), procesor dwurdzeniowy 2,2 GHz, pamięć RAM 1024 MB minimum, jednak praktycznie rekomendujemy 8 GB RAM dla zapewnienia sprawnych operacji pod obciążeniem produkcyjnym.
Przestrzeń dyskowa na serwerze powinna wynosić minimum 100 GB na dysku SSD lub SATA – zalecane 500 GB, aby umożliwić logowanie zdarzeń systemowych i przechowywanie cachów aplikacji. Dynamiczny wzrost przesyłów danych (notyfikacje o przyjazdach, aktualizacje statusów) wymaga szybkiego dostępu do dysku. W środowiskach o wysokiej przepustowości (powyżej 50 transportów dziennie) konieczne są dyski SSD typu 15k lub szybsze SATA.
Wymagania sprzętowe serwera bazy danych (SQL Server)
Baza danych Microsoft SQL Server powinna być zainstalowana na odrębnym, dedykowanym serwerze. Serwer bazy danych musi spełniać wymagania: Windows Server 2019 Standard lub nowszy, procesor minimum 4 rdzenie 2,2 GHz (zalecane 8 rdzeni w środowisku wielotransakcyjnym), pamięć RAM 32 GB minimum (w produkcji 64 GB jest praktyką standardową).
Dla przechowywania danych transakcyjnych VSS.net niezbędny jest dysk SSD o pojemności minimum 200 GB dedykowanego dla plików danych (.mdf) oraz osobny dysk SSD 100 GB dla logów transakcji (.ldf). Ta separacja dyków drastycznie poprawia wydajność operacji zapisu. Przechowywanie logów na osobnym dysku RAID 1 (mirror) zapewnia bezpieczeństwo danych w przypadku awarii sprzętu.
Komponenty oprogramowania – serwer
Na serwerze aplikacyjnym wymagane są następujące komponenty: Windows Server 2019/2022 Standard Edition z zainstalowaną rolą IIS wersja 7.5 lub wyższa (zazwyczaj preinstalowana w systemie), Microsoft SQL Server 2016 Express/Standard lub nowszy (zalecane SQL Server 2019/2022 Standard dla wydajności), SQL Management Studio do zarządzania bazą danych, .NET Framework 4.7.2 lub wyższy (VSS.net wymaga platformy .NET do wykonania), Windows Installer wersja 4.5 do instalacji komponentów, PowerShell 1.0 lub nowszy do automatyzacji operacji administracyjnych.
Opcjonalnie, SQL Reporting Services (SSRS) umożliwia generowanie zaawansowanych raportów dotyczących awizacji, czasu realizacji i statystyk operacyjnych. Rekomendujemy SSRS w przypadku organizacji wymagających dogłębnej analizy wskaźników operacyjnych.
Konfiguracja serwera IIS dla VSS.net
Po zainstalowaniu systemu operacyjnego Windows Server i roli IIS administrator IT musi: aktywować niezbędne role IIS (Application Development, Common HTTP Features, Health and Diagnostics, Performance, Security), zainstalować moduł Application Request Routing (ARR) dla load balancingu, skonfigurować Application Pool dla VSS.net z tożsamością usługi sieciowej (Network Service) lub dedykowanym kontem domeny o ograniczonych uprawnieniach.
Każdy Application Pool powinien mieć przydzielony limit pamięci (private memory limit 1024 MB) i ustawioną politykę recyklingu po 1440 minutach (24 godziny) lub po 200 mln żądań. Te parametry zapobiegają wyciekom pamięci i niespodziewanym restartom aplikacji. Powiązanie witryny (binding) powinno korzystać z protokołu HTTPS z certyfikatem SSL (TLS 1.2 minimum) – szczególnie ważne gdy VSS.net będzie dostępny z sieci publicznej.
Instalacja i konfiguracja bazy danych SQL Server
SQL Server 2016 lub nowszy instalowany jest w trybie mixed authentication (Windows + SQL login), aby zezwolić na dostęp zarówno dla kont domeny, jak i dla użytkowników SQL Server. Administrator IT tworzy dedykowanego użytkownika SQL o minimalnych uprawnieniach (w obrębie bazy danych VSS.net) – użytkownik powinien mieć role db_datareader i db_datawriter, bez dostępu do procedur systemowych.
Baza danych VSS.net wymaga ustawień: sortowanie Latin1_General_CI_AS (domyślne dla aplikacji polskojęzycznych), recovery model Full (aby umożliwić backup transakcyjny), backup compression enabled (zmniejsza rozmiar kopii zapasowych), enable snapshots isolation level (poprawia wydajność odczytów konkurencyjnych).
Integracja z systemami zewnętrznymi
VSS.net komunikuje się z systemami ERP poprzez REST API lub EDI. W przypadku integracji z SAP wymaga się zainstalowania middleware SAP XI (lub Cloud Integration, jeśli SAP w chmurze). Administrator IT musi: utworzyć konta techniczne w systemach źródłowych (SAP, Enova itp.), skonfigurować endpointy API z autentykacją OAuth 2.0, ustawić limity rate limitingu (np. maksymalnie 100 żądań/minutę) aby uniknąć przeciążenia systemów.
Integracja z kontrolą dostępu na bramce wymaga komunikacji z urządzeniem licznika czasu (bramka RFID, terminal LPR – License Plate Recognition). VSS.net obsługuje połączenia TCP/IP i protokoły HTTPS do przesyłania informacji o przyjazdach vozów w czasie rzeczywistym. Każda integracja powinna być przetestowana w środowisku sandbox przed wdrożeniem do produkcji.
Konfiguracja uprawnień i użytkowników
Administrator IT pracuje z zespołem biznesmem w celu zdefiniowania ról użytkowników. Typowe role to: dyrektor logistyki (dostęp do raportów strategicznych), kierownik placu (pełne zarządzanie transportami i oknami), operator awizacji (dodawanie i edycja awizacji dostawców), operator rampowy (potwierdzanie rozładunków), audytor (dostęp do logów i raportów bez prawa do zmian).
Każdy użytkownik przypisany jest do grupy bezpieczeństwa w katalogu Active Directory (AD), a ta grupa mapowana jest na role aplikacyjne w VSS.net. Uwierzytelnianie odbywać się powinno poprzez LDAP/Active Directory authentication – eliminuje to potrzebę zarządzania hasłami w samej aplikacji i zapewnia spójność z polityką bezpieczeństwa korporacyjnym.
Testy i wdrożenie
Przed przejściem do produkcji należy przeprowadzić serię testów: test wydajności (symulacja 50-100 użytkowników jednocześnie), test integracji (weryfikacja komunikacji z ERP i bramką), test odporności na awarie (backup/restore, failover bazy danych), test bezpieczeństwa (penetration testing, audyt uprawnień).
Po pomyślnym przejściu testów zespół SoftwareStudio wspiera migrację danych historycznych (stare awizacje, transporty z poprzednich systemów), szkolenie użytkowników końcowych oraz rozruch systemu w ostrych warunkach produkcyjnych. Obowiązkowe jest ustalenie procedur disaster recovery – regularnie testowane backup bazy danych, dokumentacja kroków przywracania, alert monitoring dla krytycznych komponentów infrastruktury.
Wsparcie powdrożeniowe i monitorowanie
Po uruchomieniu VSS.net w produkcji zespół IT powinien wdrożyć monitoring infrastruktury (CPU, RAM, dysk, połączenia sieciowe), logi aplikacji (Event Log na serwerze IIS, SQL Server logs, Application Insights jeśli dostępny), alerty e-mail dla zdarzeń krytycznych (błędy aplikacji, brak dostępu do bazy danych). SoftwareStudio świadczy wsparcie techniczne przez określony okres – zazwyczaj 3-6 miesięcy po wdrożeniu – w ramach Service Level Agreement definiującego czasy odpowiedzi na problemy krytyczne i operacyjne.