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.

PS_2000 to system zarządzania przedsiębiorstwem. Przez lata obrastał nowymi funkcjonalnościami, modyfikacjami, wariantami spowodowanymi potrzebami różnych klientów. Wydawałoby się nic specjalnego – system jak wiele innych na rynku. Pewnego jednak poranka, trudno w tej chwili dociec w jaki sposób (potrzeba matką wynalazków?), zrodził się pomysł rozbudowy systemu zarządzania magazynem w PS_2000 o moduł obsługujący urządzenia mobilne. Obecnie wszystkim nam wydaje się, że używanie urządzeń mobilnych w magazynie to oczywista oczywistość. Oprogramowanie na urządzeniu mobilnym bezpośrednio komunikujące się z systemem PS_2000 i wykorzystujące kody kreskowe porządkuje i znacząco upraszcza procesy magazynowe. Ponadto daje możliwość pełnego nadzorowania ruchów magazynowych czy kompletacji tak, że towary opuszczają magazyn zgodnie z zamówieniem (w uzgodnionym czasie, z towarem określonej serii i o właściwej dacie ważności). Rozmawiając obecnie z pracownikami magazynów Farmacol S.A. – bo o tej firmie właśnie tu mowa, wielokrotnie spotykam się ze stwierdzeniem, że nie wyobrażają sobie obecnie pracy bez tych urządzeń.

Założenia

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).

sdj_architektura_rozwiazania

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.

sdj_system_monitoringu_dla_serwera_aplikacji

Wspomniałem na początku artykułu o wymaganiu związanym z niezawodnością i wydajnością rozwiązania. Szczególnie narażone na potencjalne problemy wydawała nam się komunikacja z system ERP. Dlatego w serwerze poleceń został zaimplementowany system monitoringu (Rysunek 3). Monitorowane są czasy wykonania poszczególnych poleceń, liczby operacji oczekujących w kolejkach, ale również istnieje możliwość zablokowania wykonania konkretnego polecenia, czy testowanie poleceń. W serwerze aplikacji kontrolowana jest ilość równocześnie pracujących użytkowników z daną aplikacją (Rysunek 2). Dane związane z działaniem aplikacji, dla każdego użytkownika są przechowywane w obiektach sesji serwera aplikacji. Web serwis Busines Logic Interface pozostaje bezstanowy i jest tylko prostą warstwą pośredniczącą – fasadą serwera aplikacji. Jak w każdym rozwiązaniu opartym o sesje użytkownika czasem istnieje potrzeba przechowywania informacji wspólnych dla wielu sesji. Powstał w tym celu oddzielny moduł (nie umieszczony na diagramie). Niezależny moduł był niezbędny aby zapewnić wymianę informacji między sesjami pochodzącymi z potencjalnie wielu serwerów aplikacji. Moduł ten został zrealizowany jako serwis Windows.

sdj_system_monitoringu_dla_serwera_polecen

W artykule przedstawiłem architekturę wdrożonego systemu zarządzania magazynem z wykorzystaniem urządzeń mobilnych. Rozwiązanie jest nowoczesne, zapewnia skalowalność i możliwość dowolnej konfiguracji modułów. W końcu, co najważniejsze, spełnia oczekiwania klienta.

Źródło: www.sdjournal.org
Autor: Rafał Deja - Autor jest doktorem nauk technicznych z zakresu informatyki. Specjalizuje się w projektowaniu rozwiązań webowych opartych na technologiach .NET. Jest Architektem Rozwiązań w Polsoft Engineering Sp. z o.o. oraz wykładowcą na Wyższej Szkole Biznesu.

PRZECZYTAJ RÓWNIEŻ:


Back to top