Connecter Sage 100 / Sage 300 : vérifier la connectivité de la Web API Sage 300

Une seule connexion couvre les deux produits et le champ variant décide duquel il s’agit : sage300 exécute un test de connectivité réel contre la Web API Sage 300 avec votre adresse de service, votre code de société et votre compte utilisateur, tandis que sage100 renvoie un résultat honnête d’indisponibilité. Remplissez variant, URL de base, société, nom d’utilisateur et mot de passe, puis testez — Sage 300 d’abord.

C’est une seule connexion pour deux produits Sage, et le premier champ, variant, décide de tout ce qui suit. Avec variant à sage300, la connexion vérifie que ce système peut atteindre votre Web API Sage 300 : elle s’authentifie avec votre compte utilisateur Sage 300 via HTTP Basic et lit une fois le profil de votre société. Avec variant à sage100, le test n’envoie aucune requête : il renvoie un résultat honnête d’indisponibilité, car l’appel eBusiness Web Services de Sage 100 est basé sur SOAP et sa requête doit d’abord être confirmée à partir de votre propre WSDL. Pour les deux produits, gardez la portée en tête : cette connexion vérifie uniquement la connectivité. Elle n’importe ni commandes, ni clients, ni stock, et ne renvoie pas de stock — pour Sage 300, les noms de champs renvoyés par ses vues doivent d’abord être confirmés à partir du swagger de votre propre déploiement. Un test Sage 300 réussi prouve seulement que les cinq valeurs ci-dessous fonctionnent ensemble pour cette société, et rien de plus.

Prérequis#

• Vous savez quel produit vous utilisez réellement : Sage 300 ou Sage 100. Cela décide la valeur de variant, et les deux parcours se comportent de façon complètement différente dans le test.
• Pour Sage 300 : le service Web API Sage 300 tourne sur votre serveur, à une adresse de la forme https://server/Sage300WebApi. Vous pouvez vérifier le service vous-même en ouvrant {baseUrl}/swagger dans un navigateur : si cette page répond, le service est actif.
• Un compte utilisateur dans votre système Sage local pour l’intégration : pour Sage 300, un utilisateur Sage 300 pouvant s’authentifier via HTTP Basic et autorisé à utiliser la Web API ; pour Sage 100, un utilisateur Web Services. Il n’y a aucune inscription cloud pour ces identifiants : le compte vit dans votre propre système Sage.
• Votre code de société : pour Sage 300, l’Org ID de société qui apparaît dans l’adresse de la Web API, par exemple SAMINC ; pour Sage 100, votre code de société.

Obtenir les identifiants#

1. Décidez d’abord le mot variant, avant de réunir quoi que ce soit d’autre : saisissez sage300 si vous utilisez Sage 300, ou sage100 si vous utilisez Sage 100. Le mot exact compte : le test le lit littéralement.
2. Pour Sage 300, notez l’adresse de la Web API de votre serveur, par exemple https://server/Sage300WebApi. Ouvrez d’abord {cette adresse}/swagger dans un navigateur : si la page répond, vous avez la bonne adresse et le service tourne.
3. Pour Sage 100, notez plutôt l’adresse eBusiness Web Services de votre serveur, par exemple https://server/ebusinesswebservices. Gardez-la prête avec votre WSDL, que détient votre administrateur Sage.
4. Notez votre code de société : pour Sage 300, l’Org ID de société utilisé dans l’adresse de la Web API, par exemple SAMINC ; pour Sage 100, le code de société de l’entreprise que vous voulez connecter.
5. Demandez à votre administrateur Sage le compte utilisateur d’intégration dans votre système Sage local, et notez son nom d’utilisateur et son mot de passe comme un couple : pour Sage 300, l’utilisateur Sage 300 pour l’authentification HTTP Basic ; pour Sage 100, l’utilisateur Web Services. Utilisez un compte créé pour l’intégration, pas l’accès quotidien d’une personne.

Remplir dans Integration#

1. Ouvrez Integration → Marketplace → Sage 100 / Sage 300 → Nouvelle connexion.
2. variant, obligatoire, variante de produit : saisissez le seul mot sage300 si vous utilisez Sage 300, ou sage100 si vous utilisez Sage 100. sage300 va vers la Web API Sage 300 (OData). sage100 va vers eBusiness Web Services de Sage 100 (SOAP), qui nécessite d’abord la confirmation de votre WSDL et n’est pas encore ouvert aux tests.
3. base_url, obligatoire, URL de base du service : pour Sage 300, collez votre adresse Web API, par exemple https://server/Sage300WebApi. Pour Sage 100, collez plutôt votre adresse eBusiness Web Services, par exemple https://server/ebusinesswebservices.
4. company, obligatoire, code de société : pour Sage 300, saisissez l’Org ID de société qui correspond dans l’adresse de la Web API, par exemple SAMINC. Pour Sage 100, saisissez votre code de société.
5. username, obligatoire, nom d’utilisateur : saisissez le nom d’utilisateur du compte d’intégration dans votre système Sage local — l’utilisateur Sage 300 pour sage300, l’utilisateur Web Services pour sage100. La forme d’exemple est un nom d’utilisateur API créé pour cette connexion.
6. password, obligatoire, mot de passe : collez le mot de passe de ce même compte. C’est un champ de type mot de passe, conservé comme secret. Le nom d’utilisateur et le mot de passe doivent appartenir au même compte.

Tester la connexion#

Cliquez sur Tester la connexion. Ce qui se passe dépend de variant, et le test lit ce champ en premier. Si variant est vide, le test s’arrête avec MISSING_VARIANT ; s’il n’est ni sage300 ni sage100, il s’arrête avec INVALID_VARIANT. Si variant vaut sage100, le test renvoie aussitôt le résultat ERP_ENDPOINTS_PENDING et n’envoie aucune requête : c’est la réponse honnête pour Sage 100 aujourd’hui, pas une erreur dans vos autres champs. Si variant vaut sage300, le test vérifie les quatre autres champs et s’arrête avec MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME ou MISSING_PASSWORD s’il en manque un. Il s’authentifie ensuite via HTTP Basic — votre nom d’utilisateur et votre mot de passe — et lit le profil de la société, la métadonnée la plus légère qu’il puisse demander, à {base}/v1.0/-/{company}/CS/CSCompanyProfile, avec une limite de 12 secondes. Une réponse 200 réussit. Un 401 est signalé comme INVALID_TOKEN, un 403 comme MISSING_SCOPE et un 404 comme NOT_FOUND : voir la FAQ pour la signification de chacun.

Mapping / choisir un modèle#

Pour cette connexion, il n’y a aucun mapping standard à configurer et aucun modèle à choisir. Pour Sage 300, les vues renvoient des noms de champs qui suivent le swagger de chaque déploiement : tout mapping de commandes, de stock ou de clients doit donc être confirmé à partir du {baseUrl}/swagger de votre propre serveur lorsqu’une connexion de données est préparée pour vous — ce n’est pas quelque chose à deviner ni à saisir ici. Pour Sage 100, la requête SOAP elle-même doit d’abord être confirmée à partir de votre WSDL. Tant que cette confirmation par déploiement n’existe pas, cette connexion en reste à la vérification de connectivité effectuée à l’étape de test. Ne renommez ni vues ni champs dans Sage pour les adapter à un mapping deviné.

Activer#

Pour Sage 300, une fois le test réussi, activez la connexion pour l’enregistrer dans Integration avec ces valeurs vérifiées, afin que la même société puisse être revérifiée plus tard avec le même compte. L’activation ne démarre aucun flux de données : via cette connexion, ni commandes, ni clients, ni stock ne circulent, dans aucun sens. Si le mot de passe du compte d’intégration change plus tard, mettez à jour le champ de mot de passe ici et testez à nouveau. Pour Sage 100, il n’y a encore rien à activer : le résultat du test vous a déjà indiqué l’état, et changer les autres champs ne le changera pas.

FAQ#

J’utilise Sage 100 et le test renvoie ERP_ENDPOINTS_PENDING

Ce résultat est attendu pour Sage 100, et il n’est causé par rien de ce que vous avez saisi. Dès que le test lit variant comme sage100, il renvoie ce résultat sans envoyer aucune requête, car la connexion Sage 100 passe par eBusiness Web Services en SOAP, et cette requête doit d’abord être confirmée à partir du WSDL de votre propre déploiement. Aucune adresse, aucun code de société, aucun nom d’utilisateur ni mot de passe ne peut changer ce résultat aujourd’hui.

Ne changez pas les autres champs à répétition : ils ne sont pas la cause. Vérifiez une seule chose : si vous utilisez en réalité Sage 300, passez variant à sage300 et testez à nouveau, car vous étiez sur le mauvais parcours. Si vous utilisez vraiment Sage 100, gardez prêts votre adresse de service, votre code de société et votre utilisateur Web Services avec votre WSDL, et attendez l’ouverture du parcours Sage 100 avant de terminer cette connexion.

Le test s’arrête avec MISSING_VARIANT ou INVALID_VARIANT

Le test lit variant avant tout le reste, car ce seul mot achemine tout le test. MISSING_VARIANT signifie que le champ est vide. INVALID_VARIANT signifie que le mot qu’il contient n’est aucun des deux mots acceptés par la connexion : un nom de produit écrit sous une autre forme, avec des mots en plus ou avec un espace, ne mène nulle part.

Saisissez exactement un mot dans variant : sage300 pour Sage 300, sage100 pour Sage 100 — sans espaces, sans mots en plus. Enregistrez, puis testez à nouveau.

Le test Sage 300 échoue avec INVALID_TOKEN (401)

La Web API Sage 300 n’a pas accepté l’authentification HTTP Basic : votre nom d’utilisateur et votre mot de passe, en couple, ont été refusés. Causes habituelles : une erreur de frappe ou de copie, un mot de passe changé depuis que vous l’avez noté, ou un nom d’utilisateur associé au mot de passe d’un autre compte.

Récupérez à nouveau le nom d’utilisateur et le mot de passe de l’unique compte d’intégration auprès de votre administrateur Sage, recopiez-les sans espaces en trop, vérifiez que le nom d’utilisateur est dans username et le mot de passe dans password, puis testez à nouveau. Si le mot de passe du compte a été réinitialisé dans Sage, utilisez le nouveau ici.

Le test Sage 300 échoue avec MISSING_SCOPE (403)

L’authentification a fonctionné, mais cet utilisateur Sage 300 n’est pas autorisé à utiliser la Web API. L’adresse et la société ont été atteintes : c’est le droit Web API du compte lui-même qui manque, donc changer l’adresse ou le code de société ne corrigera pas ce cas.

Demandez à votre administrateur Sage d’autoriser cet utilisateur à utiliser la Web API Sage 300, ou de vous donner un autre utilisateur Sage 300 qui a déjà ce droit. Mettez à jour username et password ici si le compte change, puis testez à nouveau.

Le test Sage 300 échoue avec NOT_FOUND (404)

Le profil de société que le test demande n’a pas été trouvé à cette adresse pour cette société. Soit le code de société ne correspond à l’Org ID d’aucune société sur ce serveur, soit base_url ne pointe pas vers la racine de la Web API Sage 300 : une petite différence dans l’adresse a le même effet.

Ouvrez d’abord {baseUrl}/swagger dans un navigateur : s’il ne répond pas, corrigez base_url jusqu’à ce qu’il réponde, et vérifiez que l’adresse se termine à la racine de la Web API, par exemple https://server/Sage300WebApi. Si swagger répond, comparez company à l’Org ID utilisé dans vos adresses Web API, par exemple SAMINC, puis testez à nouveau.

Le test Sage 300 s’arrête avec MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME ou MISSING_PASSWORD

Sur le parcours sage300, le résultat nomme le champ exact qui est vide. Le test vérifie ces quatre champs après variant et n’envoie rien tant qu’ils ne sont pas tous présents, car la lecture du profil de la société a besoin de l’adresse, de la société et de l’authentification Basic ensemble.

Remplissez le champ nommé (URL de base du service, code de société, nom d’utilisateur ou mot de passe) avec les valeurs que vous avez réunies, enregistrez, puis testez à nouveau. Répétez jusqu’à ce qu’aucun résultat de manque n’apparaisse.

Le test Sage 300 a réussi, mais ni commandes, ni stock, ni clients ne sont synchronisés

C’est la portée actuelle de cette connexion, pas une erreur dans vos valeurs. Le test prouve seulement que l’authentification Basic et la lecture du profil de la société fonctionnent. Le transfert de données ne fait pas encore partie de cette connexion, car les noms de champs renvoyés par les vues Sage 300 suivent le swagger de chaque déploiement et doivent d’abord être confirmés à partir du {baseUrl}/swagger de votre propre serveur.

Considérez un test Sage 300 réussi comme une connexion vérifiée pour cette société, et gardez pour l’instant le travail sur les commandes, le stock et les clients dans Sage 300 même. Lorsqu’une connexion de données sera préparée pour votre déploiement, elle partira de ces mêmes valeurs vérifiées et de votre swagger : vous n’aurez pas à réunir les identifiants à nouveau.