System VSS - moduły na wspólnej bazie SQL Server i role użytkowników

System VSS jako platforma modułów

System VSS nie jest jednym programem do umawiania terminów. Studio VSS.net składa się z sekcji menu, które pracują na wspólnych danych. Wśród nich są awizacje i kartoteki. Osobne sekcje obsługują plac oraz bramę, a raporty zbiera sekcja Informacje. Moduł awizacji jest więc tylko jedną z części i został opisany w artykule o awizacjach VSS.net jako module produktu.

Ten tekst zajmuje się platformą. Pyta, jak sekcje dzielą dane, kto ma do nich dostęp i na jakim serwerze to wszystko działa. Ogólne zasady systemów klasy YMS zawiera artykuł o yard management system, a tutaj liczy się konkretny układ jednego produktu.

Układ menu odzwierciedla kolejność pracy: awizacja powstaje w jednym miejscu, w dniu dostawy przechodzi przez bramę i plac, a po wyjeździe trafia do raportów. Każdy etap ma własny ekran. Portiernia i magazynier pracują więc na tych samych rekordach, ale widzą je inaczej.

Przebieg jednej wizyty przez moduły

Najłatwiej zrozumieć platformę, śledząc jedną wizytę pojazdu od zatwierdzenia do raportu. Każdy krok zapisuje dane w innej sekcji, ale wszystkie odwołują się do tej samej awizacji i tego samego pojazdu.

Zmiana statusu i rejestracja wjazdu są jednym zdarzeniem. Jeśli którakolwiek z tych dwóch czynności się nie uda, druga nie może pozostać zapisana. Rozwiązuje to transakcja, którą baza zatwierdza w całości albo wycofuje. Poniższa procedura jest przykładem mechanizmu, a nazwy tabel i kolumn są poglądowe.

CREATE PROCEDURE dbo.usp_RejestrujWjazd
    @AwizacjaId int,
    @PojazdId   int
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;

    BEGIN TRANSACTION;

    UPDATE dbo.Awizacja
    SET    Status = 2                -- 2 = pojazd na bramie
    WHERE  AwizacjaId = @AwizacjaId
      AND  Status = 1;               -- 1 = oczekująca

    IF @@ROWCOUNT = 0
        THROW 50001, N'Awizacja nie ma statusu oczekującej.', 1;

    INSERT INTO dbo.WjazdNaBrame (PojazdId, AwizacjaId, CzasWjazdu)
    VALUES (@PojazdId, @AwizacjaId, SYSUTCDATETIME());

    COMMIT TRANSACTION;
END;

Warunek na status w klauzuli WHERE chroni przed dwukrotnym zarejestrowaniem tego samego wjazdu, a opcja XACT_ABORT wycofuje całą transakcję przy pierwszym błędzie. Portiernia nie musi rozumieć tej mechaniki. Dla niej liczy się tylko to, że po odczycie kodu ekran dyspozytora pokazuje zmieniony status.

Wspólna baza SQL Server i model danych

Platforma działa na Windows Server z serwerem stron IIS oraz bazą Microsoft SQL Server w edycji Express albo Standard. Wszystkie moduły korzystają z jednej bazy. To rozwiązanie zamiast synchronizacji między osobnymi produktami: zmiana w jednym miejscu jest od razu widoczna w pozostałych.

Jedna baza zamiast synchronizacji

Przy oddzielnych bazach każde przekazanie pojazdu między modułami wymagałoby komunikatu i obsługi błędów: co zrobić, gdy brama zapisała wjazd, a kalendarz jeszcze nie dostał statusu. We wspólnej bazie wjazd i zmiana statusu mogą być jedną transakcją. Odpada kolejka wiadomości i rozbieżność stanów między ekranami.

Cena tego wyboru jest wyraźna. Moduły dzielą schemat, więc zmiana w kartotece dotyka wielu ekranów, a wersje modułów muszą być aktualizowane razem. Sprawdza się to w platformie jednego producenta, ale nie nadaje się do składania systemów z niezależnych dostawców. W tym drugim przypadku właściwa jest integracja przez API lub pliki EDI, opisana niżej.

Wspólne kartoteki jako źródło referencji

Dane referencyjne, na przykład kontrahenci i pojazdy, są przechowywane raz. Awizacja, wjazd na bramę, wpis w księdze gości i zdjęcie z kamery wskazują ten sam rekord pojazdu po kluczu, zamiast kopiować numer rejestracyjny do własnej tabeli. Poniższy fragment pokazuje przykładowy schemat z kluczami obcymi.

CREATE TABLE dbo.Pojazd (
    PojazdId       int IDENTITY PRIMARY KEY,
    NumerRej       nvarchar(15) NOT NULL UNIQUE,
    KontrahentId   int NOT NULL
);

CREATE TABLE dbo.Awizacja (
    AwizacjaId     int IDENTITY PRIMARY KEY,
    PojazdId       int NOT NULL REFERENCES dbo.Pojazd (PojazdId),
    RampaId        int NOT NULL,
    OknoOd         datetime2(0) NOT NULL,
    OknoDo         datetime2(0) NOT NULL,
    Status         tinyint NOT NULL
);

CREATE TABLE dbo.WjazdNaBrame (
    WjazdId        int IDENTITY PRIMARY KEY,
    PojazdId       int NOT NULL REFERENCES dbo.Pojazd (PojazdId),
    AwizacjaId     int NULL REFERENCES dbo.Awizacja (AwizacjaId),
    CzasWjazdu     datetime2(0) NOT NULL
);

Kolumna AwizacjaId w tabeli wjazdów dopuszcza wartość pustą, ponieważ transport nieawizowany też wjeżdża na teren i musi zostać zapisany. Klucz obcy pilnuje spójności: nie da się zapisać wjazdu pojazdu, którego nie ma w kartotece. Ograniczenia opisuje dokumentacja o kluczach głównych i obcych w SQL Server.

Reguła: każdy moduł odwołuje się do kartoteki po kluczu, a nie kopiuje jej danych.

Indeksy dla kalendarza ramp

Kalendarz pyta bazę o awizacje jednej rampy w zakresie czasu, i robi to przy każdym odświeżeniu ekranu przez każdego dyspozytora. Zamknięte wizyty przechodzą do historii, więc kalendarz potrzebuje tylko aktywnych. Indeks filtrowany obejmuje wyłącznie wiersze spełniające warunek, dzięki czemu pozostaje mały, gdy archiwum rośnie.

CREATE NONCLUSTERED INDEX IX_Awizacja_Rampa_Okno
    ON dbo.Awizacja (RampaId, OknoOd)
    INCLUDE (OknoDo, Status, PojazdId)
    WHERE Status < 3;   -- tylko awizacje aktywne

Kolumny w klauzuli INCLUDE sprawiają, że zapytanie kalendarza nie sięga do tabeli głównej. Składnię i ograniczenia opisuje dokumentacja polecenia CREATE INDEX w T-SQL. Odczyty kalendarza nie powinny też czekać na zapisy z bramy, dlatego baza może pracować z opcją READ_COMMITTED_SNAPSHOT, w której czytelnik widzi ostatnią zatwierdzoną wersję wiersza.

Edycje SQL Server a skala wdrożenia

O wyborze edycji decyduje wielkość bazy i obciążenie. Edycja Express jest bezpłatna, ale ogranicza wielkość pojedynczej bazy do 10 GB, co dla małego obiektu z ruchem kilkudziesięciu pojazdów wystarcza przez długi czas. Edycja Standard nie ma takiego limitu bazy, a moc obliczeniowa jest ograniczona do mniejszej z wartości: 4 procesorów fizycznych lub 24 rdzeni. Aktualne limity opisuje dokumentacja o edycjach SQL Server.

Zdjęcia z kamer rozpoznających tablice rejestracyjne nie muszą trafiać do bazy. W opisanym w systemie modelu zdjęcia lądują na serwerze FTP i są łączone z awizacją, a baza przechowuje tylko odniesienie, dzięki czemu limit wielkości bazy nie rośnie od obrazów.

Role i uprawnienia użytkowników

Platforma z wieloma sekcjami wymaga precyzyjnego podziału uprawnień. Ochrona nie powinna zmieniać kartotek, a przewoźnik nie może widzieć zajętości cudzych ramp. Administrator tworzy konta i przypisuje im role, a najwyższe uprawnienia nadzorcze ma supervisor.

Zakładki uprawnień w module administracyjnym

Uprawnienia ustawia się na trzech poziomach. Poziomy dopełniają się: rola daje gotowy zestaw, a zakładka transakcji pozwala go zawęzić dla jednej osoby.

Można też ograniczyć dostęp do wybranych ramp i kontrahentów, co przydaje się w organizacjach z kilkoma wdrożeniami. Użytkownik z prawem tylko do podglądu widzi awizacje, ale nie edytuje ich ani nie zatwierdza.

Konta zewnętrzne i techniczne

Przewoźnik pracuje na uproszczonym interfejsie i widzi wyłącznie własne zgłoszenia. Konta techniczne służą integracjom, dlatego administrator zarządza kluczami i hasłami do API, także dla połączenia z instalacją VSS.net w innej lokalizacji tej samej grupy kapitałowej. Porównanie z modelem ról w magazynie przedstawia artykuł o rolach i użytkownikach w systemie WMS.

SELECT CASE WHEN EXISTS (
           SELECT 1
           FROM   dbo.UzytkownikRola ur
           JOIN   dbo.RolaTransakcja rt ON rt.RolaId = ur.RolaId
           WHERE  ur.UzytkownikId = @UzytkownikId
             AND  rt.Transakcja   = @Transakcja
       ) THEN 1 ELSE 0 END AS MaPrawo;

Zapytanie sprawdza, czy użytkownik ma prawo do operacji przez powiązanie z rolą. Wywołuje się je po stronie serwera przy każdym zapisie. Ukrycie przycisku w interfejsie nie jest zabezpieczeniem, bo żądanie HTTP można wysłać bez klikania.

Integracje i granice platformy

Platforma nie zastępuje ERP ani systemu magazynowego. Współpracuje z nimi przez REST API lub pliki EDI. Zatwierdzona awizacja może trafić do Studio WMS.net jako zlecenie przyjęcia lub wydania, a z ERP, na przykład SAP, enova365 albo Comarch, system pobiera zamówienia zakupu i tworzy propozycje awizacji.

Granica platformy przebiega tam, gdzie kończy się plac i brama. Składowanie towaru i kompletacja pozostają w systemie WMS, tak samo jak inwentaryzacja. Dla kierowców dostępna jest również aplikacja mobilna, o której traktuje artykuł o programie do awizacji na Androida.

Utrzymanie wspólnej bazy i kopie zapasowe

Jedna baza upraszcza integrację, ale oznacza też jeden punkt awarii dla wszystkich modułów. Kopia zapasowa nie jest więc dodatkiem do wdrożenia, tylko jego częścią. Rytm kopii zależy od tego, ile zdarzeń można stracić: awaria w środku zmiany kosztuje tym więcej, im rzadziej zapisywano dziennik transakcji.

BACKUP DATABASE VssPrzyklad
    TO DISK = N'D:\Kopie\VssPrzyklad_pelna.bak'
    WITH CHECKSUM, INIT;

Zadania cykliczne w wersji Standard uruchamia SQL Server Agent. Edycja Express go nie zawiera, więc to samo wykonuje harmonogram zadań Windows z wywołaniem narzędzia sqlcmd. Składnię i opcje kopii opisuje dokumentacja polecenia BACKUP w T-SQL. Przy wdrożeniu on-premise odpowiedzialność za ten harmonogram trzeba przypisać wprost, bo w modelu SaaS przejmuje ją dostawca.

Wdrożenie platformy w chmurze i on-premise

System działa w przeglądarce, więc na terminalach użytkowników nie trzeba niczego instalować. Serwer można postawić w dwóch modelach: SaaS w chmurze albo instalacji na serwerach klienta lub na dedykowanym serwerze VPS. Porównanie modeli dla rozwiązań magazynowych zawiera artykuł producenta o WMS w chmurze i on-premise, a opis produktu znajduje się na stronie Studio VSS.net.

Przed uruchomieniem wykonuje się analizę procesów logistycznych, która ustala liczbę ramp oraz typy pojazdów, a także zasady zatwierdzania. Kolejność uruchamiania modułów ma znaczenie, bo każdy kolejny opiera się na danych poprzedniego.

• Kartoteki i konta - najpierw kontrahenci z pojazdami, a dopiero potem rampy z rolami, bo bez nich nie da się założyć awizacji.
• Jedna brama pilotażowa - pierwsze tygodnie na jednej bramie i jednym typie dostaw, z dopuszczeniem dostaw bez rezerwacji.
• Kalendarz ramp - włączony po ustabilizowaniu procesu bramy, z parametrami długości okna i godzin pracy.
• Raporty i integracje - na końcu, gdy dane z pilotażu są kompletne i można je porównać z planem.

Procedury na bramie wymagają też ustalenia zasad poruszania się osób z zewnątrz po terenie zakładu. Ogólne wymagania dla osób przebywających na terenie zakładu zbiera Państwowa Inspekcja Pracy, a udokumentowane przekazanie zasad ma znaczenie przy zdarzeniach wypadkowych.