System TMS online - trzy warstwy zamiast instalacji lokalnej
System TMS online składa się z trzech warstw. Przeglądarka wyświetla interfejs, serwer aplikacji wykonuje logikę zleceń, a baza danych przechowuje stan zleceń i floty. Użytkownik nie instaluje programu na komputerze, bo kod interfejsu pobiera się przy każdym uruchomieniu razem z odpowiedziami serwera.
W instalacji lokalnej każde stanowisko ma własną kopię aplikacji i łączy się z bazą w sieci firmowej. Wersja online przenosi serwer aplikacji oraz bazę do centrum danych dostawcy albo do chmury publicznej. Komunikacja odbywa się przez HTTPS, więc dyspozytor w biurze i kierowca na parkingu korzystają z tego samego adresu.
Linkway.TMS jest w opisie producenta rozwiązaniem chmurowym typu SaaS, uruchamianym przez przeglądarkę i bez lokalnej instalacji. Szczegóły modelu opisuje artykuł producenta o działaniu systemu TMS w chmurze. Poniższe sekcje opisują mechanizmy ogólne, które stoją za takim modelem, a nie specyfikację konkretnego produktu.
| Aspekt | Instalacja lokalna | System TMS online |
|---|---|---|
| Uruchomienie | program na każdym stanowisku, serwer w firmie | przeglądarka i adres z logowaniem |
| Baza danych | serwer SQL utrzymywany przez dział IT klienta | baza w środowisku dostawcy, wspólna dla zespołu |
| Aktualizacja wersji | instalacja na każdym stanowisku lub na serwerze | wdrożenie po stronie dostawcy, użytkownik loguje się do nowej wersji |
| Kopie zapasowe | harmonogram i nośniki po stronie klienta | zadania dostawcy, zakres opisany w umowie |
| Dostęp spoza biura | VPN lub pulpit zdalny | bezpośrednio przez Internet z uwierzytelnieniem |
Reguła: model online przesuwa utrzymanie serwera do dostawcy, ale nie usuwa potrzeby uzgodnienia w umowie kopii zapasowych oraz czasu dostępności.
Dostęp przez przeglądarkę i praca wielu dyspozytorów
Przeglądarka jest klientem, który nie przechowuje danych zleceń trwale. Każda akcja, na przykład przypisanie pojazdu, wysyła żądanie do serwera, a serwer zwraca zaktualizowany widok. Dzięki temu ten sam stan widzą jednocześnie osoby przy różnych urządzeniach, także na tablecie lub telefonie.
Sesja oraz role użytkowników
Po zalogowaniu serwer tworzy sesję i przypisuje użytkownikowi rolę. Dyspozytor widzi edycję zleceń, księgowa rozliczenia, a kierowca wyłącznie swoje zadania. Podział ról po stronie serwera jest ważniejszy niż ukrycie przycisków w interfejsie, bo interfejs można ominąć wywołaniem adresu bezpośrednio.
Jednoczesna edycja tego samego zlecenia
Gdy dwie osoby zmieniają ten sam rekord, system musi wybrać zwycięzcę. Rozwiązaniem stosowanym w aplikacjach webowych jest blokada optymistyczna: rekord ma numer wersji, a zapis udaje się tylko wtedy, gdy wersja nie zmieniła się od odczytu. W SQL Server służy do tego kolumna typu rowversion. Nazwy tabeli i kolumn w przykładzie są poglądowe.
CREATE TABLE dbo.ZlecenieTransportowe (
ZlecenieId int IDENTITY(1,1) PRIMARY KEY,
Numer nvarchar(30) NOT NULL,
PojazdId int NULL,
Status tinyint NOT NULL,
DataZaladunku datetime2(0) NOT NULL,
Wersja rowversion NOT NULL
);
UPDATE dbo.ZlecenieTransportowe
SET PojazdId = @PojazdId
WHERE ZlecenieId = @ZlecenieId
AND Wersja = @WersjaOdczytana;
IF @@ROWCOUNT = 0
THROW 50001, N'Zlecenie zmieniono w międzyczasie.', 1;Drugi dyspozytor, który próbuje zapisać zmianę na starej wersji, dostaje komunikat zamiast po cichu nadpisać cudzą decyzję. Pełny opis blokad i wersjonowania wierszy zawiera przewodnik Microsoft Learn o blokowaniu transakcji i wersjonowaniu wierszy.
Jedna baza danych dla zleceń i floty
Największa różnica względem arkuszy i lokalnych plików to wspólny rekord. Każdy rekord ma jeden identyfikator, więc status zmieniony w jednym miejscu jest widoczny wszędzie. Model danych ogranicza też błędy, bo relacje pilnuje baza, a nie pamięć dyspozytora.
| Encja | Przykładowe pola | Relacja |
|---|---|---|
| Zlecenie | numer, załadunek, rozładunek, status | jedno zlecenie ma jeden lub wiele przystanków |
| Pojazd | numer rejestracyjny, typ zabudowy, ładowność | pojazd obsługuje wiele zleceń w czasie |
| Kierowca | imię i nazwisko, uprawnienia, dostępność | kierowca jest przypisany do pojazdu na zlecenie |
| Dokument | typ, numer, plik, data dodania | dokument należy do zlecenia |
Wspólna baza pozwala też raportować bez kopiowania danych. Zestawienie kosztów trasy i przychodu ze zlecenia powstaje jednym zapytaniem, ponieważ obie liczby leżą w tym samym schemacie. Na tym opiera się analiza rentowności, którą opisuje artykuł o obiegu dokumentów w Linkway.TMS w części dotyczącej rozliczeń.
Wiele urządzeń pracujących na jednej bazie wymaga świadomego podejścia do transakcji. Krótka transakcja na jednym zleceniu blokuje tylko kilka wierszy, a długa transakcja z pętlą po całej flocie zablokuje pracę zespołu. Przy poziomie READ COMMITTED z wersjonowaniem wierszy odczyty nie czekają na zapisy, co ma znaczenie przy mapie odświeżanej co kilkanaście sekund.
Aktualizacje i kopie zapasowe po stronie dostawcy
Producent Linkway.TMS opisuje automatyczne aktualizacje oprogramowania i regularne kopie zapasowe jako cechy wersji chmurowej. Mechanizm ogólny wygląda podobnie u większości dostawców: nowa wersja trafia najpierw do środowiska testowego, a potem do produkcji w zaplanowanym oknie serwisowym albo bez przerwy, gdy zmiana dotyczy wyłącznie kodu aplikacji.
Wersjonowanie i zgodność zmian
Zmiana schematu bazy jest trudniejsza od zmiany interfejsu, bo dotyka danych. Bezpieczny sposób polega na dodaniu nowej kolumny z wartością domyślną, wdrożeniu kodu, który ją zapisuje, i dopiero później usunięciu starej. Dzięki temu w każdej chwili działają jednocześnie dwie wersje kodu, a użytkownik nie widzi przerwy.
Kopie zapasowe i odtwarzanie
Kopia, której nikt nie próbował odtworzyć, jest jedynie założeniem. Dwa parametry opisują ryzyko: RPO to maksymalna utrata danych liczona w czasie, a RTO to czas do ponownego uruchomienia usługi. Oba należy uzgodnić z dostawcą, zamiast zakładać, że chmura sama gwarantuje ciągłość.
Reguła: w umowie na system online zapisuje się RPO oraz RTO wraz z miejscem przechowywania kopii, bo od nich zależy, ile dni zleceń firma może stracić po awarii.
Integracje systemu TMS online przez API
System działający w Internecie wymienia dane z systemami firmy przez interfejsy, a nie przez wspólne tabele. Najczęściej jest to API REST z formatem JSON, a przy starszych systemach pliki XML wgrywane na serwer. Zasady projektowania takich interfejsów opisuje wytyczne Microsoft Learn dotyczące projektowania API.
Producent wskazuje integrację z GPS i giełdami transportowymi oraz z systemami magazynowymi i księgowymi. Skutki takiej wymiany dla całego łańcucha dostaw opisuje artykuł o integracji TMS z ERP i WMS. Dane pozycji pojazdów zbiera moduł opisany w materiale o integratorze GPS dla flot, a platformy niezależne od siebie łączy Linkway.BRIDGE.
Idempotencja zleceń przyjmowanych z ERP
Wywołanie API może się powtórzyć po przerwie w łączności. Jeśli zlecenie z ERP dotrze dwa razy, w TMS nie mogą powstać dwa zlecenia transportowe. Rozwiązaniem jest klucz idempotencji: identyfikator dokumentu źródłowego wysłany w nagłówku, po którym serwer rozpoznaje powtórzenie.
POST /api/v1/zlecenia HTTP/1.1
Idempotency-Key: ZK-2026-000412
Content-Type: application/json
{
"numerZewnetrzny": "ZK/2026/000412",
"zaladunek": { "kod": "MAG-01", "okno": "2026-10-05T08:00/2026-10-05T10:00" },
"rozladunek": { "kod": "KL-0087" },
"ladunek": { "palety": 22, "masaKg": 11400 }
}Przy powtórzeniu serwer zwraca ten sam wynik co za pierwszym razem, a nie kod błędu. Podobny wzorzec opisuje w kontekście komunikatów wzorzec Idempotent Consumer w dokumentacji Microsoft. Klucz z systemu źródłowego działa też jako identyfikator do wyszukiwania sprawy w obu systemach.
Moduły i aplikacje mobilne w jednym środowisku
System TMS online z modułami pracuje na tej samej bazie, więc zmiana w jednym miejscu jest widoczna w pozostałych. Producent Linkway.TMS wymienia moduły transportu, floty, księgowości z finansami oraz narzędzi. Zakres każdego z nich przedstawia tabela.
| Moduł Linkway.TMS | Zakres funkcji według opisu producenta |
|---|---|
| Transport | zarządzanie zleceniami i planowanie tras |
| Flota | zarządzanie pojazdami i monitoring kierowców |
| Księgowość i finanse | fakturowanie i rozliczenia z przewoźnikami |
| Narzędzia | rezerwacje i śledzenie dostępności sprzętu |
Po stronie kierowcy działa aplikacja mobilna. Opis aplikacji linkway.TRACKER wskazuje potwierdzanie etapów dostawy, rejestrowanie przyczyn opóźnień i zgłaszanie problemów w czasie rzeczywistym. Analizy wydajności kierowców i kosztów w przeglądarce zapewnia Linkway.FLEET.
Awizacje dostaw i okna czasowe planuje się w osobnym systemie, ale wymiana statusów z TMS jest możliwa. Model danych takiej wymiany omawia artykuł o awizacji transportu po stronie przewoźnika i dyspozytora, a jego szerszy kontekst chmurowy przedstawia materiał o wykorzystaniu chmury obliczeniowej.
Dostępność i wydajność w godzinach szczytu
Obciążenie systemu transportowego nie rozkłada się równo w ciągu dnia. Najwięcej żądań pojawia się rano, gdy dyspozytorzy układają plan, oraz w chwili importu dużej partii zleceń z ERP. Mapa z pozycjami pojazdów dokłada do tego stały strumień odczytów. Serwer aplikacji obsługuje takie szczyty przez skalowanie poziome: dodaje się kolejne instancje za równoważnikiem obciążenia, zamiast kupować mocniejszy komputer.
Skalowanie poziome działa wtedy, gdy instancje aplikacji nie trzymają stanu w pamięci. Sesję użytkownika przechowuje wspólny magazyn albo podpisany token, więc kolejne żądanie trafia do dowolnej instancji. Baza danych pozostaje jednym wspólnym elementem, dlatego indeksy na kolumnach statusu i daty decydują o tym, czy lista zleceń otwiera się w ułamku sekundy.
CREATE NONCLUSTERED INDEX IX_Zlecenie_Aktywne
ON dbo.ZlecenieTransportowe (Status, DataZaladunku)
INCLUDE (Numer, PojazdId)
WHERE Status IN (1, 2, 3);Indeks filtrowany obejmuje tylko zlecenia w statusach otwartych. Jest więc mały i szybki do przeglądania, a zlecenia zamknięte nie obciążają listy roboczej dyspozytora.
| Objaw | Prawdopodobna przyczyna | Sposób weryfikacji |
|---|---|---|
| Lista zleceń otwiera się wolno | brak indeksu na kolumnach statusu i daty | plan wykonania zapytania w SQL Server Management Studio |
| Konflikty zapisu zdarzają się często | długie sesje edycji tego samego zlecenia | liczba błędów wersji w dzienniku aplikacji |
| Import z ERP trwa długo | zapis wiersz po wierszu w osobnych transakcjach | test paczki zleceń zapisywanej w jednej transakcji |
| Mapa pokazuje spóźnione pozycje | zbyt rzadki odczyt danych z telematyki | interwał odpytywania i długość kolejki komunikatów |
Praca kierowcy przy słabym zasięgu
Aplikacja online zakłada połączenie z serwerem, a kierowca regularnie przejeżdża przez miejsca bez zasięgu. Opis producenta nie precyzuje trybu pracy bez łączności, więc ten punkt należy potwierdzić u dostawcy przed wdrożeniem. Mechanizm ogólny, który rozwiązuje problem, to lokalna kolejka zdarzeń wysyłana po odzyskaniu sieci.
Zdarzeniem jest potwierdzenie załadunku lub rozładunku, a także zgłoszenie opóźnienia. Aplikacja zapisuje je na urządzeniu z czasem akcji i wysyła po odzyskaniu łączności. Serwer przyjmuje zdarzenia w kolejności ich wystąpienia, a nie w kolejności odbioru, bo w przeciwnym razie plan zleceń pokazywałby nieprawdziwą chronologię.
- Znacznik czasu zdarzenia - czas potwierdzenia ustawia urządzenie w chwili akcji, a serwer zapisuje osobno czas odbioru wiadomości.
- Numer w partii - kolejny numer zdarzenia na urządzeniu pozwala zachować porządek potwierdzeń nawet przy jednoczesnym wysłaniu kilku wpisów.
Rozbieżność zegara telefonu jest realnym źródłem błędów. Serwer porównuje czas odbioru z czasem zdarzenia i oznacza wpisy, w których różnica przekracza przyjęty próg, do weryfikacji przez dyspozytora.
Bezpieczeństwo danych w modelu online
Dane o zleceniach i cenach frachtu są informacją handlową, więc dostęp musi być ograniczony technicznie. Transport szyfrowany TLS chroni dane w drodze, a szyfrowanie dysków chroni je w miejscu przechowywania. Dostawca odpowiada za warstwę infrastruktury, a klient za konta użytkowników i ich uprawnienia.
- Uwierzytelnianie - hasło uzupełnione drugim składnikiem ogranicza skutki wycieku samego hasła.
- Rejestr zdarzeń - zapis, kto i kiedy zmienił zlecenie, pozwala wyjaśnić spór z klientem lub przewoźnikiem.
- Zakres ról - kierowca widzi swoje zadania, a stawki dla klientów zostają poza jego ekranem.
- Odbiór dostępu - konto odchodzącego pracownika jest blokowane w dniu zakończenia współpracy.
Weryfikację tych zapisów najlepiej przeprowadzić jeszcze przed wdrożeniem. Etapy projektu, w tym analizę i konfigurację ról, opisuje materiał o wdrożeniu systemu linkway.TMS w czterech etapach.
Migracja danych z arkuszy do systemu online
Przejście z arkuszy wymaga załadowania danych podstawowych, czyli kartotek pojazdów oraz kierowców. Dane trafiają najpierw do tabeli pośredniej, w której walidacja odrzuca duplikaty numerów rejestracyjnych i puste pola obowiązkowe. Dopiero poprawne wiersze przechodzą do tabel docelowych.
Błędy z importu wracają do osoby przygotowującej dane jako lista wierszy z opisem problemu. Taki obieg skraca poprawki, bo nikt nie szuka błędu w całym pliku. Wątek porównania arkusza z systemem rozwija artykuł Excel w transporcie a system TMS.
Kiedy model online jest właściwym wyborem
Model online sprawdza się wtedy, gdy zespół pracuje w kilku lokalizacjach, a firma nie utrzymuje własnego serwera. Instalacja lokalna zostaje uzasadniona przy wymaganiu izolacji sieciowej albo przy integracji z systemem, który nie ma dostępu z zewnątrz. Porównanie obu modeli dla systemów magazynowych przedstawia artykuł o programie magazynowym w chmurze i on-premise, a rachunek kosztów licencji i subskrypcji zawiera tekst o modelach cenowych oprogramowania magazynowego.
Przy wyborze dostawcy system TMS online warto porównać z tym, co producent opisuje na stronie rozwiązania. Zestawienie modułów i integracji jest w opisie Linkway.TMS na stronie producenta, a ogólniejszy przegląd rozwiązań programowych zawiera artykuł o programie TMS. Wynik takiego porównania zależy od integracji, jakie firma faktycznie potrzebuje w pierwszym roku.
