Guide d’intégration de ProShop ERP pour l’ordonnancement de la production avec SkyPlanner APS

ProShop propose deux interfaces aux outils d’ordonnancement externes. Elles sont décrites dans sa documentation destinée aux développeurs de l’API :

1. ProShop GraphQL API. « ProShop provides a GraphQL API, available via HTTP(S). » (ProShop fournit une API GraphQL accessible via HTTP(S).) Il existe un seul point de terminaison : chaque appel est une requête HTTP POST vers <proshop root>/api/graphql, avec query, variables et operationName dans un corps JSON. Chaque module dispose d’une requête au singulier pour un enregistrement et d’une requête au pluriel pour les listes. Les listes sont paginées à l’aide de pageSize (20 par défaut) et de pageStart. Elles renvoient records et totalRecords, et acceptent les arguments filter et query, qui reprennent les critères de la fonction Advanced Search de chaque module. Le schéma peut être exploré par introspection. (Présentation de l’API ProShop)
2. Recently Updated Records API. « A simple REST interface allows external integrations to request information between arbitrary points in time. » (Une interface REST simple permet aux intégrations externes de demander des informations sur un intervalle de temps librement défini.) Appelez <proshop root>/recentlyupdatedrecords avec start (ISO 8601) et, en option, end et filterby, par exemple workorders,workcells,purchaseorders,timetracking,deletions. L’équipe ProShop doit d’abord activer l’index. (API Recently Updated Records)

Les écritures passent par des mutations GraphQL. Time Tracking Login est l’exemple documenté. Les droits d’écriture sont accordés module par module, au moyen des portées d’autorisation (scopes).

La documentation développeur de ProShop ne décrit ni webhooks sortants ni abonnements GraphQL. Il faut donc interroger ProShop périodiquement. L’API Recently Updated Records allège ce traitement : demandez tous les enregistrements créés, modifiés ou supprimés depuis la dernière exécution, en filtrant les types nécessaires à l’ordonnancement. Récupérez ensuite les ordres de fabrication modifiés par leur numéro via GraphQL. ProShop indique que cette méthode est plus rapide qu’une requête sur lastModifiedTime.

Un cycle de cinq minutes pour les ordres de fabrication et le suivi des temps, et d’une heure pour les pièces et les commandes d’achat, est un choix courant. SkyPlanner envoie des webhooks lorsque l’état ou le planning change : les écritures en retour sont donc déclenchées par les événements.

1. Chargement initial des données de base. Parcourez Parts, Work Cells, Users, Tools et Fixtures par pages, à l’aide des requêtes GraphQL au pluriel. Définissez une valeur élevée pour pageSize lors du premier chargement et bouclez en vous appuyant sur totalRecords. Définissez la correspondance des cellules de travail : celles qui représentent des machines deviennent des postes de travail, et celles qui représentent des personnes deviennent du personnel. Une même opération peut ainsi réserver à la fois une machine et son opérateur.

2. Synchronisation des ordres de fabrication. Lisez les ordres de fabrication actifs avec leurs opérations, leurs temps cibles et leurs enregistrements de nomenclature, ainsi que les commandes d’achat ouvertes. SkyPlanner considère les matières commandées comme disponibles à la date de livraison de la commande d’achat et met le stock à jour lorsque celle-ci passe au statut Delivered. La détection des modifications passe par Recently Updated Records avec filterby=workorders,purchaseorders,deletions.

3. Renvoi des dates planifiées. Lorsque le moteur positionne ou déplace une opération, un webhook SkyPlanner déclenche une mutation GraphQL qui définit les dates planifiées de l’ordre de fabrication, avec une Authorization disposant de workorders:w. Les prévisions de respect des délais et les dates de besoin pour les achats dans ProShop reposent alors sur les dates de SkyPlanner.

4. Déclarations en atelier. Les opérateurs enregistrent leur travail avec SkyPlanner Mobile Confirmations ou Production Timer. Ces relevés de temps permettent de maintenir le planning à jour. Vous choisissez de renvoyer ou non les temps réels vers ProShop Time Tracking, sur l’opération de l’ordre de fabrication concernée. Sinon, les opérateurs continuent de pointer leurs temps dans ProShop comme auparavant, et SkyPlanner les lit via timetracking.

5. Systèmes de référence et règles de gestion des conflits. Consignez ces règles avant la mise en production :

Désignez un seul système pour écrire les dates des ordres de fabrication. Dès que SkyPlanner ordonnance une cellule de travail, les responsables de l’ordonnancement cessent de réorganiser sa liste dans ProShop. Les deux plannings ne se font ainsi jamais concurrence.

• Les temps cibles sont déterminants. ProShop calcule les durées à partir des temps de préparation et de cycle estimés. Récupérez les temps cibles actuels, et non l’estimation initiale. Distinguez le temps de préparation du temps d’exécution pour que la matrice des temps de préparation puisse remplacer le temps de préparation défini par une valeur unique.
• Cellules de travail représentant des personnes. Une cellule de travail peut correspondre à une personne. Associez ces cellules au personnel dans SkyPlanner, et non aux machines, sinon chaque opérateur sera traité comme une machine parallèle.
• Time Tracking nécessite un utilisateur. Depuis avril 2026, la mutation Time Tracking Login « requires user context » (nécessite un contexte utilisateur) et n’est pas autorisée avec Client Credentials. Envoyez les temps des opérateurs via OAuth 2.0 Authorization Flow, ou conservez le pointage dans ProShop et récupérez les données.
• Activez l’index des modifications. Recently Updated Records ne fonctionne qu’après son activation par l’équipe ProShop. Demandez-la dès la première semaine.
• Enregistrements soumis à l’ITAR. ProShop filtre les enregistrements soumis aux restrictions ITAR pour chaque connexion. Une option de Developer System Config détermine s’ils sont renvoyés sous forme de valeurs null ou exclus des résultats. Convenez des ordres de fabrication auxquels l’intégration aura accès et gérez les valeurs null à chaque lecture.
• Opérations sous-traitées. Les opérations réalisées chez vos fournisseurs représentent un délai écoulé, sans mobiliser votre capacité. Modélisez-les comme des étapes définies uniquement par leur durée.