Ten poradnik dotyczy implementacji wymiany danych między systemem nadrzędnym a RDS. Zacznij od ustalenia, czy projekt używa SAP Warehouse Robotics, czy własnego interfejsu ERP. Opis architektury wyjaśnia tę różnicę oraz rolę adaptera.
Przykładowe komunikaty pokazują sposób projektowania integracji. Nie stanowią specyfikacji API SAP ani potwierdzenia obsługi tych samych funkcji we wszystkich wersjach RDS.
Ustal kontrakt, zanim skonfigurujesz endpoint
Zdefiniuj właściciela zlecenia, identyfikator korelacyjny, źródło i cel, identyfikator nośnika, priorytet oraz warunek zakończenia. Określ dozwolone zmiany stanu i sposób mapowania lokalizacji.
HTTP API z JSON jest jednym z możliwych sposobów komunikacji. W wariancie Warehouse Robotics trzeba dodatkowo spełnić jego kontrakt za pomocą adaptera opisanego przez SAP. Własny endpoint RDS nie jest automatycznie gotowym konektorem SAP.
Potwierdź wersję systemu, konfigurację HTTPS, uwierzytelnienie, uprawnienia, limity czasu i zasady ponawiania. Numer portu sam w sobie nie dowodzi szyfrowania połączenia.
Wysyłanie zlecenia i mapowanie danych
Katalog producenta SEER opisuje Wind Task, konfigurację interfejsów i skrypty. W konkretnej instalacji trzeba powiązać odebrane dane z odpowiednim procesem, sprawdzić parametry i ustalić odpowiedź na błąd.
Poniższy JSON zachowuje przykład z wcześniejszego opisu. Nazwy pól są elementem przykładowego kontraktu, a nie standardem SAP:
{
"data": {
"taskRecordId": "ID_zlecenia_z_SAP_12345",
"targetSiteId": "Loc-05",
"content": "Towar_X"
}
}Przy takim formacie należy określić, skąd proces bierze miejsce pobrania, jak identyfikuje nośnik i co oznacza pole content. Dla żądania JSON ustal nagłówek Content-Type: application/json. Sam poprawny format nie oznacza jeszcze przyjęcia zadania biznesowego.
Public Interface i Interface Configuration to nazwy spotykane w opisie konfiguracji RDS. Konkretny endpoint, powiązanie z Wind Task i sposób obsługi odpowiedzi należy sprawdzić w dokumentacji oraz konfiguracji używanej wersji.
Callbacki i ponowienia
Oddziel przyjęcie żądania, rozpoczęcie transportu, pobranie, odłożenie, zakończenie, błąd i anulowanie. Uzgodnij, które z tych zdarzeń są wymagane przez system nadrzędny i kiedy wolno potwierdzić ruch magazynowy.
W opisie RDS występują Event Configuration oraz Callback After Completion Of Action z HttpPostTemplate. Traktuj je jako nazwy mechanizmów do sprawdzenia dla danej wersji. Niezależnie od narzędzia callback powinien mieć identyfikator zadania, stan, czas i kod błędu.
Odbiorca musi rozpoznawać duplikaty. Po utracie odpowiedzi nadawca powinien sprawdzić stan i ponowić komunikację według uzgodnionej reguły, bez automatycznego uruchamiania drugiego transportu. Zapisuj historię komunikatów i decyzji operatora.
Odpytywanie statusów i przykłady zależne od wersji
Odpytywanie może służyć uzgodnieniu stanu po utracie połączenia, sprawdzeniu zajętości punktu i analizie historii. Sam odczyt „punkt wolny” nie rezerwuje go — między odczytem a startem misji sytuacja może się zmienić.
Zachowujemy poniższe identyfikatory z wcześniejszego materiału jako przykłady do weryfikacji, nie instrukcję gotową do uruchomienia. Nie ustalono wersji RDS, dla której wszystkie są obowiązującym kontraktem:
- porty 8080 i 8090;
- /handle/register/<nazwa_interfejsu> oraz /handle/register/interfaceTask;
- /api/work-sites/sites;
- /api/stat/taskList i /api/stat/agvTaskSuccessList;
- metoda receiveThirdOrder(orderParam: string).
Przed użyciem potwierdź dostępność, metodę HTTP, schemat żądania i odpowiedzi, uwierzytelnienie oraz uprawnienia. Oficjalne centrum SEER wskazuje dokumentację RDS; dostęp do szczegółowych instrukcji może wymagać konta. Nie należy otwierać portów tylko na podstawie przykładu z artykułu.
Automatyka zakładowa i odpowiedzialność za sygnały
OPC UA, MQTT i Modbus TCP mogą być elementami architektury integrującej sterowniki, bramy, windy lub telemetrię. Obecność konkretnego protokołu i konektora zależy od produktu, licencji i konfiguracji. Nie zastępuje to kontraktu zleceń i potwierdzeń ERP.
Zwykłych komunikatów procesu nie traktuj jako kanału bezpieczeństwa. Funkcje bezpieczeństwa i ich walidacja wymagają osobnego projektu. Połączenie sygnałów PLC z warstwą SAP, np. za pośrednictwem rozwiązania integracyjnego, trzeba opisać jako osobny zakres.
Odbiór integracji i utrzymanie
Przetestuj poprawne zadanie, nieprawidłowy nośnik, zajęty cel, timeout, powtórzony komunikat, restart i anulowanie w trakcie misji. Sprawdź, czy status w SAP odpowiada temu, co fizycznie wykonała flota, i czy odzyskanie po awarii nie powiela ruchu.
Ustal właścicieli adaptera, konfiguracji RDS i danych SAP, monitoring błędów oraz tryb aktualizacji wersji. Potrzeba utrzymania tych elementów nie znika po pierwszym udanym przejeździe.
Rezultatem jest uzgodniony i przetestowany przepływ od zlecenia do potwierdzenia. Porozmawiajmy o Twojej architekturze, zaczynając od wersji systemów, opisu procesu i przykładowych zleceń.