Connecter IFS Cloud : vérifier les identifiants IAM et lister les projections

Saisissez l’URL IFS Cloud, l’IAM Client ID, le Client Secret et l’IAM Token URL dans Integration et testez : le système échange un jeton et liste les projections pour prouver que les identifiants fonctionnent. Cette connexion vérifie uniquement la connectivité et ne synchronise ni commandes, ni clients, ni stock.

Le connecteur IFS Cloud vérifie une seule chose : qu’un client IAM IFS Cloud (compte de service) disposant d’un accès API peut se connecter depuis ce système. Un test réussi signifie que le système a échangé votre Client ID et votre Client Secret contre un jeton d’accès à votre IAM Token URL et a listé les projections de votre instance IFS Cloud. Il n’importe pas les commandes, n’importe pas les clients, ne lit pas et ne renvoie pas le stock, et ne synchronise aucun autre document — les projections métier d’IFS diffèrent selon la version et la personnalisation de chaque client, donc aucune synchronisation de documents ne tourne sur cette connexion. Utilisez-la pour prouver les identifiants et l’adresse de l’instance avant de préparer tout travail documentaire pour vos projections précises.

Prérequis#

• Une instance IFS Cloud que vous pouvez joindre et son adresse de base, par ex. https://myserver:48080. Il n’y a pas d’adresse par défaut à copier.
• Un client IAM IFS Cloud (compte de service) avec accès API, et l’accès à la configuration de ce client pour pouvoir y lire son Client ID, son Client Secret et son endpoint de jeton.
• L’endpoint de jeton de votre propre IAM, pris dans la configuration de ce client IAM. Chaque déploiement est différent, donc la valeur doit venir de votre propre configuration.
• Si votre déploiement utilise un tenant, la valeur du tenant ; sinon, vous laisserez ce champ vide.

Obtenir les identifiants#

1. Ouvrez la configuration du client IAM IFS Cloud (compte de service) qui dispose de l’accès API. Le Client ID et le Client Secret de cette connexion viennent de ce client.
2. Copiez le Client ID tel qu’il apparaît dans la configuration de ce client IAM.
3. Copiez le Client Secret du même client IAM. Gardez-le privé : quiconque le détient peut demander des jetons en tant que ce compte de service.
4. Dans la même configuration du client IAM, copiez l’endpoint de jeton et utilisez-le comme valeur de token_url. Il suit une forme de jeton openid-connect, mais l’adresse exacte est propre à votre déploiement : ne copiez pas un endpoint d’une autre entreprise ni d’un exemple.
5. Notez en même temps l’adresse de base de votre IFS Cloud et la valeur du tenant si votre déploiement en utilise un.

Remplir dans Integration#

1. Ouvrez Integration → Marketplace → IFS → Nouvelle connexion.
2. base_url, obligatoire, IFS Cloud URL : l’adresse de base de votre IFS Cloud, par ex. https://myserver:48080.
3. tenant, facultatif, Tenant : ne le remplissez que si votre déploiement utilise un tenant, par ex. TENANT1 ; sinon laissez-le vide.
4. client_id, obligatoire, IAM Client ID : le Client ID du client IAM (compte de service) avec accès API. Il est conservé comme secret.
5. client_secret, obligatoire, IAM Client Secret : le Client Secret du même client IAM. C’est un champ de type mot de passe, conservé comme secret.
6. token_url, obligatoire, IAM Token URL : l’endpoint de jeton copié depuis la configuration de votre propre client IAM. Il n’y a pas d’endpoint par défaut, donc cette valeur doit venir de votre propre IAM IFS Cloud.

Tester la connexion#

Cliquez sur Tester la connexion. Le test exécute deux étapes réelles. D’abord, il utilise le flux OAuth2 client credentials sur la token_url que vous avez saisie, en échangeant client_id et client_secret contre un jeton d’accès. Ensuite, il appelle votre instance avec ce jeton pour lister les projections — GET {base}/main/ifsapplications/projection/v1/AllProjections.svc/Projections?$top=1 — ce qui prouve à la fois que le jeton fonctionne et que les projections peuvent être découvertes sur votre instance. Une réponse 200 compte comme un succès. Si base_url manque, le test s’arrête avec MISSING_BASE_URL ; si client_id ou client_secret manque, il s’arrête avec MISSING_CREDENTIALS, et si token_url manque, il s’arrête avec MISSING_CONFIG, sans envoyer de requête. Le test attend 12 secondes avant de signaler TEST_TIMEOUT.

Mapping / choisir un modèle#

Il n’y a pas encore de mapping de documents à choisir pour cette connexion. Les projections métier d’IFS sont nommées selon la version et la personnalisation de chaque client, donc cette connexion ne propose pas de mapping de commandes, de clients ou de stock, et n’exécute pas de modèle qui synchronise des documents. Ce que vous pouvez vérifier après un test réussi, c’est la liste des projections elle-même : elle montre quelles projections votre instance expose, ce qui est le point de départ si un travail documentaire est préparé plus tard contre vos projections précises. N’attendez pas d’un choix de mapping qu’il fasse circuler les commandes ou le stock — sur cette connexion, ils ne circulent pas.

Activer#

Activez la connexion uniquement après un test réussi. L’activation enregistre cette connexion vérifiée — l’adresse de l’instance, le tenant facultatif et les identifiants IAM — afin que le contrôle de connectivité puisse être relancé à tout moment, par exemple après la rotation d’un client IAM ou un changement d’adresse de l’instance.

Ce que l’activation ne démarre pas : cette connexion n’importe ni n’envoie de commandes, de clients, de stock ou tout autre document, ni à l’activation ni selon un calendrier. Si vous avez besoin de synchroniser des documents avec IFS, ce travail doit être préparé contre les projections métier réelles de votre instance, en partant de la liste de projections que le test renvoie.

FAQ#

Le test s’arrête avec MISSING_BASE_URL, MISSING_CREDENTIALS ou MISSING_CONFIG

Un champ obligatoire est vide, et le test n’envoie aucune requête tant qu’ils ne sont pas tous présents. MISSING_BASE_URL signifie que base_url est vide, MISSING_CREDENTIALS que client_id ou client_secret est vide, et MISSING_CONFIG ici signifie que token_url est vide.

Remplissez base_url, client_id, client_secret et token_url depuis la configuration de votre propre client IAM et votre instance, enregistrez, puis retestez. N’ajoutez tenant que si votre déploiement en utilise un.

Le test échoue avec INVALID_CREDENTIALS ou AUTH_FAILED

Votre IAM a refusé l’échange : l’endpoint de jeton a répondu, mais il n’a pas accepté le Client ID et le Client Secret, ou il n’a renvoyé aucun jeton d’accès. La cause habituelle est un secret copié depuis un autre client IAM, un secret renouvelé, ou une token_url qui appartient à un IAM différent de celui du client.

Rouvrez la configuration de ce seul client IAM et copiez client_id, client_secret et token_url ensemble depuis le même endroit, afin que les trois appartiennent au même client et au même IAM. Collez-les à nouveau en entier et retestez.

Le test échoue avec INVALID_TOKEN

Un jeton a été obtenu, mais votre instance IFS Cloud ne l’a pas accepté lors de l’appel de liste des projections. Cela pointe vers un écart entre l’IAM qui a émis le jeton et l’instance de base_url — par exemple une token_url d’un autre déploiement, ou une base_url qui pointe vers une autre instance IFS Cloud.

Vérifiez que base_url est l’adresse du même déploiement IFS Cloud dont l’IAM a émis les identifiants, et que token_url a été copiée depuis la configuration du client IAM de ce déploiement. Corrigez la valeur qui ne correspond pas et retestez.

Le test échoue avec MISSING_SCOPE

Le jeton fonctionne, mais le compte de service derrière le client IAM n’est pas autorisé à accéder aux projections de l’instance, donc l’appel de liste des projections est refusé.

Dans IFS Cloud, accordez à ce client IAM (compte de service) l’accès aux projections, puis retestez avec les mêmes valeurs. Ne passez pas à un compte utilisateur personnel pour contourner le problème — cette connexion est faite pour fonctionner en tant que compte de service.

Le test signale TEST_TIMEOUT ou CONNECTION_FAILED

La requête ne s’est pas terminée. TEST_TIMEOUT signifie qu’aucune réponse complète n’est arrivée en 12 secondes ; CONNECTION_FAILED signifie que la requête réseau vers l’endpoint de jeton ou l’instance a échoué. Avec une adresse auto-hébergée, il s’agit souvent d’une base_url ou d’une token_url injoignable depuis l’extérieur, ou d’un port qui n’est pas ouvert.

Ouvrez la base_url et l’hôte de la token_url dans un navigateur pour confirmer que les deux répondent, vérifiez que le port de l’adresse (par ex. :48080) est joignable, puis retestez. Si les deux répondent dans le navigateur et que le test expire toujours, vérifiez auprès de votre administrateur IFS si l’accès externe à l’endpoint de projections est autorisé.

Une action documentaire signale ERP_ENDPOINTS_PENDING, ou rien ne se synchronise après activation

C’est la portée actuelle de cette connexion, pas une valeur incorrecte. Les opérations métier sur IFS — importer des commandes ou des clients, lire ou envoyer le stock — ne sont pas exécutées par cette connexion, car les noms des projections métier diffèrent selon l’instance du client. Un test réussi prouve uniquement, toujours, que les identifiants IAM fonctionnent et que les projections peuvent être listées.

Continuez à utiliser la connexion pour la vérification de connectivité. Pour la synchronisation de documents, partez de la liste de projections renvoyée par le test et préparez le travail contre les projections Integration réelles de votre instance — changer les cinq valeurs de la connexion n’activera pas la synchronisation de documents.