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

Sylob documente deux API REST publiques : « L’ERP Sylob expose deux types d’API REST publiques (autrement nommées \ »webservices\ ») qui autorise la lecture et l’écriture de données. » (base de connaissances Forterro)

1. API REST Système d’information (lecture). Elle exécute une requête enregistrée, créée dans l’activité « Interroger le système d’information ». L’URL d’appel propre à la requête s’obtient via « Autres actions » > « Afficher le web service », sous la forme /rest/query/{identifiantQuery}/resultat. Les paramètres définissent la limite de résultats, le format des nombres, les variables de la requête et la structure des résultats. Les résultats sont renvoyés en XML par défaut, ou en JSON avec l’en-tête Accept: application/json. Cette API est incluse dans l’ERP.
2. API REST Action (lecture et écriture). Elle exécute une action définie dans l’activité « Gérer les actions web service », le catalogue d’actions de Sylob. Elle expose deux opérations : GET /rest/v2/action/{code}/describe renvoie le schéma de données d’une action, et POST /rest/v2/action/{code}/execute l’exécute avec un corps de requête JSON. Les types d’actions comprennent :

– Modification de données : modifie un ou plusieurs champs d’un enregistrement via le mécanisme de modification rapide de Sylob. Describe répertorie les champs modifiables. – Message EDI : crée, modifie ou supprime des enregistrements au moyen d’un message EDI. – Scénario de saisie : exécute un scénario de saisie, question par question. L’exemple fourni par Sylob est « Déclarer un début ou une fin », qui déclare le début ou la fin d’une opération (Sylob_Action_006). – Publication, dépôt et téléchargement de documents.

1. Messages EDI. Le moteur EDI de Sylob gère les exports et les imports. Un message standard, Sylob_Recup_Decl_Pro, récupère les déclarations de production. (Forterro)
2. Fichiers et ETL. Sylob ERP Cloud propose l’ »Intégration de fichiers via SFTP pour une migration facile des intégrations existantes. » (Sylob) Les résultats des requêtes peuvent aussi être exportés vers Excel : c’est un moyen rapide de démarrer l’essai SkyPlanner.

La base de connaissances publique de Sylob ne documente aucun mécanisme d’abonnement à des webhooks sortants. Les modifications sont transmises à SkyPlanner par l’exécution périodique de requêtes enregistrées qui filtrent les OF ouverts et les modifications récentes, selon une fréquence que vous définissez.

Sylob protège l’ERP contre les volumes de requêtes trop importants. Depuis la version 2025.Q2, le paramètre société « Protection des API » active la limitation des appels par utilisateur et la pagination des résultats volumineux. Sylob annonce sa généralisation à partir de la version 2026.Q2. Les réponses contiennent des en-têtes RateLimit. Un appel dépassant le quota renvoie HTTP 429 Too Many Requests avec une valeur Retry-After. (Forterro) Prévoyez ces contraintes dans la synchronisation : requêtes incrémentales, pagination et temporisation avant une nouvelle tentative en cas de réponse 429.

De son côté, SkyPlanner envoie des webhooks lorsque l’état ou le planning change. Le renvoi des données vers Sylob est donc déclenché par les événements.

1. Chargement initial des données de base. Créez une requête enregistrée par objet (articles, nomenclatures, gammes, postes de charge, employés) et consultez les résultats via l’API Système d’information, ou effectuez un chargement unique à partir d’un export Excel. Définissez avec soin la correspondance des postes de charge. Dans Sylob, un centre de charge regroupe des ressources : un centre comprenant trois machines correspond donc généralement à un groupe de postes de travail comprenant trois postes dans SkyPlanner.

2. Synchronisation des ordres. Récupérez les OF fermes et leurs opérations, ainsi que les stocks et les commandes fournisseurs ouvertes. SkyPlanner considère les matières commandées comme disponibles à la date de livraison de la commande fournisseur et actualise le stock lorsque celle-ci passe au statut Delivered. L’ordonnancement tient donc compte à la fois du stock et des approvisionnements attendus.

Ordonnancez les OF fermes, pas les propositions du CBN. Ces propositions évoluent au prochain calcul des besoins nets.

3. Retour du planning vers Sylob. Pour chaque opération positionnée ou déplacée par le moteur, l’intégration appelle une action Modification de données sur l’opération de l’OF (Opération d’ordre de fabrication), en transmettant le début prévu, la fin prévue et le poste de charge. L’action applique la logique de modification rapide de Sylob, comme lorsqu’un planificateur modifie l’opération. Describe renvoie les champs modifiables, ce qui permet à l’intégration de valider les données à envoyer avant le premier appel. Si un utilisateur est en train de modifier un enregistrement, l’appel se solde par un échec contrôlé ; réessayez à la prochaine modification.

4. Déclarations en atelier. Les opérateurs enregistrent leur travail avec SkyPlanner Mobile Confirmations ou Production Timer. Les débuts et fins d’opération sont transmis via le scénario « Déclarer un début ou une fin ». Les relevés de temps et les quantités alimentent les déclarations de production sur la même opération de l’OF : temps de réglage, temps de production, quantité produite, rebuts et opération terminée. Si votre usine effectue déjà ses déclarations via Sylob Apps ou des terminaux d’atelier, conservez un seul canal de déclaration pour éviter les doubles saisies.

5. Responsabilité des données et règles de résolution des conflits. Consignez ces règles avant la mise en production :

SkyPlanner n’a besoin ni de CADPLAN ni des activités de planification à capacité finie de Sylob. Confiez à SkyPlanner la gestion des dates des opérations : lorsque deux outils d’ordonnancement écrivent les mêmes dates, ils écrasent mutuellement leurs modifications. Une fois cette gestion confiée à SkyPlanner, Autopilot réordonnance automatiquement la production à chaque changement significatif, et les nouvelles dates sont renvoyées à Sylob.

• Licence Action API. La lecture via les requêtes enregistrées est incluse. L’écriture via le catalogue d’actions nécessite le module Sylob « Webservice » ou une licence API sur MyForterro. Prévoyez ce point avec votre interlocuteur Sylob avant la phase de renvoi des données.
• Les requêtes définissent le contrat d’interface. La lecture repose sur les requêtes enregistrées. Donnez-leur des noms explicites, transmettez les filtres sous forme d’attributs variables à l’exécution et gérez leurs versions avec celles de l’intégration.
• Groupes de postes de charge. Un poste de charge Sylob peut regrouper plusieurs machines. Décidez pour chaque poste de charge si SkyPlanner doit le représenter par un groupe de postes de travail ou par des machines distinctes.
• Ordonnancement à rebours et calculs de charge. Sylob ordonnance à rebours à partir des dates de besoin, et un calcul de charge programmé peut replanifier les OF en retard. Convenez des activités qui pourront encore écrire les dates des opérations une fois leur gestion confiée à SkyPlanner, ou décidez de n’en conserver aucune.
• Unités des temps de réglage et d’exécution. Avant l’import, vérifiez les unités et si le réglage est défini par OF ou par pièce. Des unités incorrectes faussent toutes les durées.
• Calendriers. Les horaires hebdomadaires des postes de charge et leurs exceptions doivent couvrir l’horizon d’ordonnancement. Sinon, de la capacité disparaît du planning.
• Limitation des appels. Sylob limite les appels par utilisateur et pagine les résultats volumineux. L’interrogation incrémentale reste largement en deçà du quota.
• CORS et navigateurs. Les appels de serveur à serveur évitent les contraintes CORS. Pour les clients exécutés dans un navigateur, les origines autorisées doivent être configurées côté Sylob.