Wymagania techniczne systemu awizacji Studio VSS.net

Autor: Adam Siemiątkowski, SoftwareStudio Group Sp. z o.o.

Poniżej zebraliśmy wymagania dla obu platform, parametry usługi (SLA) oraz zasady kopii bezpieczeństwa i ochrony danych. Definicję procesu opisuje strona co to jest awizacja, a zakres wymiany danych z otoczeniem strona integracja ERP z systemem awizacji.

Wymagania techniczne systemu awizacji

Platforma wyznacza system serwera i bazę danych. Tabela zestawia obie platformy, a stanowisko użytkownika jest takie samo: przeglądarka internetowa bez instalacji dodatkowego oprogramowania.

Po stronie klienta wymagania ogranicza się do kilku elementów, które zależą od zakresu modułów. Tabela pokazuje, co przygotować przed projektem; wymagania można przenieść do macierzy z wzoru zapytania ofertowego na system awizacji i wykorzystać jako załącznik techniczny.

Aplikacja webowa bez instalacji na stanowiskach

Użytkownik otwiera system w przeglądarce, więc na komputerach pracowników i przewoźników nie instaluje się żadnego oprogramowania. Nowa wersja aplikacji trafia na serwer, a użytkownicy korzystają z niej od razu, bez własnych aktualizacji.

Przewoźnicy wchodzą do portalu z własnych komputerów, a dla kontrahentów zewnętrznych dostępny jest moduł Proxy z osobną witryną. Ochrona i kierowcy mogą korzystać z aplikacji na Androida oraz z kiosku samoobsługowego, a stanowisko dyspozytora nadal wymaga wyłącznie przeglądarki. Przykładowy widok kalendarzy pokazuje zrzut poniżej.

Studio VSS.net

Kalendarze awizacji - widok kafelkowy typów i obiektów

Ekran startowy sekcji kalendarzy w Studio VSS.net pokazuje trzy kategorie widoków. Sekcja Kalendarze ogólne zawiera kafelki Kalendarz ogólny i Zajętość ramp. Dwie pozostałe sekcje grupują kalendarze według obiektów i według magazynów kontrahenta demonstracyjnego. Kafelki prowadzą od razu do wybranego kontekstu planowania dostaw.

Wdrożenie na serwerze klienta

Na serwerze klienta dane pozostają w sieci firmowej, a administrację systemu operacyjnego i bazy danych prowadzi dział IT klienta. Ten sam obraz aplikacji, który działa w chmurze SoftwareStudio, instaluje się na maszynie klienta, więc funkcje w obu modelach są takie same. Instalacja na platformie GT obejmuje obraz Docker, reverse proxy, certyfikat SSL i konfigurację kopii bazy.

Model lokalny ułatwia audyty bezpieczeństwa i integrację z lokalnymi systemami ERP oraz WMS w zamkniętej sieci. Dostęp do informacji o transportach i kontrahentach reguluje mechanizm ról i uprawnień użytkowników, a obowiązki administratora danych, w tym ograniczenie przechowywania i rozliczalność, wynikają z rozporządzenia 2016/679 (RODO). Zasady dla danych kierowców opisuje strona ochrona danych kierowców i dostawców zgodnie z RODO.

Studio VSS.net

Kalendarze w kartotekach - kody i uprawnienia

Ekran przedstawia zestawienie kalendarzy w sekcji Kartoteki. Tabela ma kolumny Aktywne, Kod, Nazwa kalendarza i Domyślny sposób prezentacji danych oraz flagi uprawnień do dodawania i usuwania wydarzeń. Każdy kalendarz jest osobną konfiguracją: określa źródło danych, sposób filtrowania, widok domyślny i uprawnienia ról.

Platforma ST: Windows Server i SQL Server

Generacja ST działa jako aplikacja webowa na SQL Server, uruchamiana na Windows Server. Wersje systemu operacyjnego i bazy uzgadnia się w analizie przedwdrożeniowej z działem IT klienta. Licencje Microsoft wchodzą w opłatę abonamentową SaaS albo zapewnia je klient w instalacji lokalnej, a zasady rozliczenia samej platformy awizacyjnej porządkują licencje oprogramowania.

• Logowanie przez Active Directory lub Entra ID jest dostępne w pakietach i wymaga uzgodnienia z działem IT.
• Kopie bazy SQL Server wykonuje się narzędziami przyjętymi w infrastrukturze klienta, a w usłudze SaaS prowadzi je SoftwareStudio.
• Konfigurację zmienia się przez wydanie wersji lub wgranie transakcji, więc zmiany planuje się razem z działem IT.
• Kolejna wersja językowa portalu wymaga prac w kodzie stron, a język komunikacji z kierowcą wybiera się w polu awizacji.

Platforma GT na .NET 10 i PostgreSQL 18

Pakiet awizacji VSS na platformie GT nazywa się MAW. Platforma GT nie wymaga licencji Microsoft ani licencji bazy danych, a runtime GT pozostaje własnością SoftwareStudio i jest licencjonowany.

• Runtime: ASP.NET Core na .NET 10, uruchamiany w kontenerach Docker na Linuksie.
• Baza danych: PostgreSQL 18, która nie wymaga licencji bazy ani licencji Microsoft.
• Konfiguracja: pliki YAML oraz szablony HTML ze skryptami JS, wczytywane na gorąco bez restartu aplikacji.
• Wielojęzyczność: natywna, a kolejny język wymaga pliku tłumaczeń i szablonów.

Zakres platformy .NET 10 opisuje dokumentacja Microsoft Learn, a mechanizmy kopii bazy PostgreSQL 18 dokumentacja PostgreSQL. Koszty instalacji i licencji GT zestawia strona o kosztach systemu awizacji.

Wirtualizacja i kontenery

Instalacja ST na serwerze klienta może działać na maszynie wirtualnej albo fizycznej, a platforma GT uruchamia się jako kontener Docker na hoście z Linuksem. System można więc zainstalować na istniejących zasobach i dopasować moc obliczeniową do obciążenia magazynu.

Kontenery wymagają maszyny z dostępem administracyjnym, dlatego hosting współdzielony z PHP nie spełnia tego warunku. Zasady wdrożenia na serwerze klienta opisuje strona o wdrożeniu etapami.

Kopie bezpieczeństwa i ochrona danych

W usłudze Studio VSS.net kopie bezpieczeństwa wykonuje się co 24 godziny, przechowuje przez 14 dni i replikuje. Połączenia szyfruje protokół TLS 1.2 lub nowszy, a dane przetwarza się w Europejskim Obszarze Gospodarczym; parametry zestawia tabela SLA w dalszej części strony.

W instalacji lokalnej na platformie ST kopie bazy SQL Server można wykonywać narzędziami zgodnymi z mechanizmem Volume Shadow Copy Service (VSS), ale spójność kopii zależy od wybranego narzędzia i jest uzgadniana z działem IT klienta. Na platformie GT kopię bazy PostgreSQL 18 wykonuje się metodami opisanymi w dokumentacji PostgreSQL.

Odtwarzanie po awarii

Procedurę odtwarzania uzgadnia się w projekcie wdrożeniowym i sprawdza w teście odtworzenia. Zalecana kolejność obejmuje cztery kroki, a każdy z nich kończy się weryfikacją przed przejściem do następnego.

Test odtworzenia warto powtarzać po każdej zmianie wersji platformy lub infrastruktury. Zapisy statusów z godziną i autorem pozwalają sprawdzić, które awizacje powstały po ostatniej kopii.

Lista pytań do działu IT przed projektem

Odpowiedzi na kilka pytań wyznaczają platformę oraz zakres prac przed konfiguracją. Warto zebrać je na etapie analizy, razem z danymi do projektu wdrożenia YMS.

SLA i warunki usługi Studio VSS.net

Parametry poniżej dotyczą usługi Studio VSS.net. Pełne warunki określa umowa, a koszty zawiera strona o cenniku systemu awizacji.

Wróć do podstaw: co to jest awizacja dostaw, lub zobacz wdrożenie etapami.