Autor przedstawia dylematy związane z doborem właściwej architektury systemu komputerowego do obsługi magazynu. Zadaniem jest przeniesienie wybranych procesów logistycznych na urządzenia mobilne przy równoczesnej integracji z tradycyjnym systemem zarządzania magazynem a szerzej z systemem klasy ERP.
Wróćmy jednak do początków naszej przygody z urządzeniami mobilnymi (potocznie przez nas zwanymi terminalami). Zadanie postawione przed nami było złożone:
- Urządzenie mobilne ma komunikować się w czasie rzeczywistym z systemem PS_ 2000, tak aby każda zmiana na urządzeniu miała bezpośrednie odzwierciedlenie w systemie i odwrotnie;
- Praca w magazynie odbywa się w sposób ciągły (24h/dobę przez 7dni w tygodniu), więc oprogramowanie musi być niezawodne, a instalacja uaktualnień nie może dezorganizować pracy magazynu; • Każdy terminal musi być identyfikowalny, każdy użytkownik jest autentykowany i autoryzowany w oprogramowaniu na terminalu;
- Wybrane oprogramowanie z dokładnością do wersji ma działać na konkretnych urządzeniach mobilnych;
- Rozwiązanie musi być skalowalne – początkowo obsługiwało około 100 urządzeń, obecnie ponad 200, a kolejne magazyny i oddziały czekają na wdrożenie;
- Musi istnieć możliwość monitorowania liczby zalogowanych użytkowników i obciążenia systemu.
Prócz trudnych wyzwań, które powyżej krótko opisałem, dochodzą również ograniczenia które wpływają na sposób rozwiązania:
- Urządzeniami mobilnymi używanymi w magazynie są terminale firmy Motorola pracujące pod kontrolą systemu operacyjnego Windows CE;
- Komunikacja urządzeń ze światem zewnętrznym odbywa się drogą radiową – WiFi;
- System PS_2000 został napisany w C++ Builder i jedyną metodą integracji z jego modułami jest bezpośrednia wymiana komunikatów przez TCP/IP;
- Urządzenia mobilne mają bardzo ograniczoną wielkość pamięci trwałej (flash), w której są przechowywane pliki. Programy po pełnym zimnym restarcie są usuwane z pamięci urządzenia.
Od początku nie mieliśmy wątpliwości, że to rozwiązanie powinno powstać w technologii Microsoft .NET. Pragnęliśmy również stworzyć rozwiązanie modułowe, rozproszone, z łatwą możliwością skalowania.
Rozwiązanie
Ostatecznie zaproponowaliśmy system, którego architekturę można przedstawić za pomocą Rysunku 1. Na każdym urządzeniu mobilnym zostaje początkowo zainstalowane oprogramowanie Uploader, służące jedynie do instalacji pozostałych programów. Programy takie jak Komora przyjęć, Przesunięcia Międzymagazynowe, Stacja wydań itp. są programami wielowarstwowymi, których cienki klient pracujący na terminalu łączy się z serwerem aplikacji. W poszczególnych modułach ładowanych przez serwer aplikacji została zaimplementowana logika biznesowa programów i warstwa dostępu do danych. Moduły logiki biznesowej aplikacji często wywołują operacje z systemu ERP (tutaj PS_2000). Wywołanie tych operacji odbywa się z wykorzystaniem serwera poleceń (command server).
Serwer poleceń może być połączony z wieloma instancjami modułu systemu ERP, dlatego jego głównym zadaniem jest kolejkowanie, balansowanie obciążenia i dystrybucja poleceń. Szczególne znaczenie ma XML Web Service: Dynamic URL. Aplikacja uruchamiając się na urządzeniu mobilnym woła Dynamic URL. Na podstawie ID terminala i nazwy oraz wersji aplikacji Dynamic URL zwraca adres serwisu Business Logic Interface. Rozwiązanie takie pozwala na znaczną konfigurację systemu i skalowalność. W zależności od potrzeb na tym samym komputerze lub fizycznie innej maszynie, można zaimplementować kolejny serwis Business Logic Interface, gdy np. chcemy, aby nowa wersja programu działała jedynie na wybranych terminalach. Skalowalność jest też zapewniona na następnym poziomie. Mianowicie zarówno komunikacja między Business Logic Interface a serwerem aplikacji oraz serwerem aplikacji i serwerem poleceń odbywa się z wykorzystaniem .NET Remoting. Daje to oczywiście możliwość wdrożenia każdego z tych serwerów na oddzielnych maszynach.
Źródło: www.sdjournal.org