Przewodnik po integracji ProShop ERP na potrzeby harmonogramowania produkcji w SkyPlanner APS

ProShop udostępnia zewnętrznemu systemowi harmonogramowania dwie możliwości połączenia, opisane w dokumentacji ProShop API Developer Documents:

1. ProShop GraphQL API. „ProShop provides a GraphQL API, available via HTTP(S).” (ProShop udostępnia GraphQL API przez HTTP(S)). Dostępny jest jeden endpoint: każde wywołanie to żądanie HTTP POST do <proshop root>/api/graphql z polami query, variables i operationName w treści JSON. Każdy moduł ma zapytanie w liczbie pojedynczej do pobierania jednego rekordu oraz zapytanie w liczbie mnogiej do pobierania list. Listy są stronicowane za pomocą pageSize (domyślnie 20) i pageStart. Zwracają records i totalRecords oraz przyjmują argumenty filter i query, które odpowiadają funkcji Advanced Search danego modułu. Schemat można odczytać za pomocą introspekcji. (Wprowadzenie do API ProShop)
2. Recently Updated Records API. „A simple REST interface allows external integrations to request information between arbitrary points in time.” (Prosty interfejs REST pozwala zewnętrznym integracjom pobierać informacje z dowolnego przedziału czasu). Wywołaj <proshop root>/recentlyupdatedrecords z parametrem start (ISO 8601) oraz opcjonalnymi parametrami end i filterby, na przykład workorders,workcells,purchaseorders,timetracking,deletions. Zespół ProShop musi najpierw włączyć indeks. (Recently Updated Records API)

Zapis odbywa się przez mutacje GraphQL. Udokumentowanym przykładem jest Time Tracking Login, a uprawnienia do zapisu przyznaje się osobno dla każdego modułu za pomocą zakresów uprawnień.

Dokumentacja dla programistów ProShop nie opisuje wychodzących webhooków ani subskrypcji GraphQL. Dane z ProShop pobiera się przez cykliczne odpytywanie. Recently Updated Records API ogranicza związane z tym obciążenie: wystarczy pobrać informacje o wszystkich rekordach utworzonych, zmodyfikowanych lub usuniętych od ostatniego uruchomienia, z filtrem obejmującym typy rekordów potrzebne do harmonogramowania. Następnie pobierz zmienione zlecenia produkcyjne według numeru przez GraphQL. Jak wskazuje ProShop, jest to szybsze niż zapytania według lastModifiedTime.

Zwykle wybiera się cykl pięciominutowy dla zleceń produkcyjnych i ewidencji czasu pracy oraz godzinny dla części i zamówień zakupu. SkyPlanner wysyła webhooki przy zmianie stanu lub harmonogramu, więc zapis zwrotny jest sterowany zdarzeniami.

1. Początkowe wczytanie danych podstawowych. Pobieraj kolejne strony Parts, Work Cells, Users, Tools i Fixtures za pomocą zapytań GraphQL w liczbie mnogiej. Przy pierwszym wczytaniu ustaw wysoką wartość pageSize i pobieraj dane w pętli na podstawie totalRecords. Ustal mapowanie komórek roboczych: komórki odpowiadające maszynom stają się stanowiskami roboczymi, a komórki odpowiadające osobom — personelem. Dzięki temu ta sama operacja może jednocześnie rezerwować maszynę i jej operatora.

2. Synchronizacja zleceń produkcyjnych. Odczytuj aktywne zlecenia produkcyjne wraz z operacjami, czasami docelowymi i rekordami BOM, a także otwarte zamówienia zakupu. SkyPlanner uznaje zamówiony materiał za dostępny w dniu dostawy określonym w zamówieniu zakupu i aktualizuje stan magazynowy po oznaczeniu zamówienia jako Delivered. Wykrywanie zmian odbywa się przez Recently Updated Records z filterby=workorders,purchaseorders,deletions.

3. Zapis zwrotny harmonogramu. Gdy silnik umieszcza operację w harmonogramie lub ją przesuwa, webhook SkyPlanner wyzwala mutację GraphQL, która ustawia planowane daty zlecenia produkcyjnego. Odbywa się to z użyciem Authorization z uprawnieniem workorders:w. Prognoza terminowości w ProShop oraz daty zapotrzebowania zakupowego opierają się wówczas na datach ze SkyPlanner.

4. Potwierdzenia z hali produkcyjnej. Operatorzy rejestrują pracę za pomocą SkyPlanner Mobile Confirmations lub Production Timer, a wpisy czasu pracy zapewniają aktualność harmonogramu. To Ty decydujesz, czy rzeczywisty czas pracy ma być przesyłany z powrotem do ProShop Time Tracking dla danej operacji zlecenia produkcyjnego. Jeśli nie, operatorzy rejestrują czas w ProShop tak jak dotychczas, a SkyPlanner odczytuje go przez timetracking.

5. Odpowiedzialność za dane i zasady rozstrzygania konfliktów. Spisz je przed uruchomieniem produkcyjnym:

Wybierz jeden system odpowiedzialny za zapis dat zleceń produkcyjnych. Gdy SkyPlanner zacznie harmonogramować pracę danej komórki roboczej, planiści przestają zmieniać kolejność na jej liście w ProShop. Dzięki temu oba plany nie będą ze sobą kolidować.

• Czasy normatywne decydują o wszystkim. ProShop oblicza czas trwania na podstawie szacowanych czasów przezbrojenia i cyklu. Pobieraj aktualne czasy normatywne, a nie pierwotne szacunki. Oddziel czas przezbrojenia od czasu wykonania, aby macierz czasów przezbrojeń mogła zastąpić pojedynczą wartość czasu przezbrojenia.
• Osoby jako gniazda robocze. Gniazdem roboczym może być osoba. Takie gniazda mapuj na personel w SkyPlanner, a nie na maszyny — w przeciwnym razie każdy operator stanie się maszyną pracującą równolegle.
• Time Tracking wymaga użytkownika. Od kwietnia 2026 mutacja Time Tracking Login „requires user context” (wymaga kontekstu użytkownika) i nie jest autoryzowana w trybie Client Credentials. Przesyłaj czas pracy operatorów przez OAuth 2.0 Authorization Flow albo nadal rejestruj go w ProShop i stamtąd odczytuj.
• Włącz indeks zmian. Recently Updated Records działa dopiero po włączeniu przez zespół ProShop. Poproś o to w pierwszym tygodniu.
• Rekordy objęte ITAR. ProShop filtruje rekordy objęte ograniczeniami ITAR osobno dla każdego połączenia. Opcja w Developer System Config określa, czy są zwracane jako wartości null, czy pomijane. Ustal, które zlecenia produkcyjne będą widoczne dla integracji, i obsługuj wartości null przy każdym odczycie.
• Operacje u podwykonawców. Operacje wykonywane u dostawców zajmują czas, ale nie obciążają Twoich zdolności produkcyjnych. Modeluj je jako etapy uwzględniające wyłącznie czas.