Nous voulons qu’une base de données Invantive Exact Online existante continue à fonctionner après que nous ayons ajusté les autorisations de l’utilisateur lié dans Exact et que nous ayons réinitialisé la connexion OAuth dans notre propre application. Pour l’instant, cela ne fonctionne pas sans casser la chaîne de jetons.
Problèmes rencontrés
Par locataire, nous avons une base de données Exact Online (nl) dans Invantive Cloud, avec les Identifiants pré-authentifiés : seulement le refresh-token de notre propre application OAuth Exact. Une fois la base de données active, Invantive Cloud gère le jeton ; notre application ne rafraîchit alors plus ce jeton.
Exact autorise un seul refresh-token actif par combinaison client-id et utilisateur. Si nous réalisons un nouvel OAuth dans notre application (nouveau jeton, car les droits Exact Online ont été modifiés), l’ancienne base de données Invantive continue de se rafraîchir avec l’ancien jeton. Ensuite, nous obtenons itgeneor362 / itgenoda494.
Exemple concret (août 2026)
- La base de données dans Invantive Cloud était correcte ; OData4 via Bridge Online (
https://bridge-online.invantive.com/…/odata4) fonctionnait. - Les autorisations de l’Utilisateur Client dans Exact Online ont été modifiées. Ensuite, Exact a été à nouveau relié dans notre application → nouveau refresh-token.
- En réinstallant les identifiants dans Invantive (conteneur de données existant
eolou nouveau conteneur dans la même base de données), nous avons obtenu entre autres :
itgeneor362
Un seul jeton d’actualisation peut être actif sur Exact Online pour une combinaison d’ID client et d’utilisateur. […] La demande de données a été faite avec un jeton d’actualisation expiré ou un jeton qui n’a pas été activé par un appel API Exact Online suivant. Renouvelez l’autorisation dans l’interface utilisateur.
Et plus tôt dans la même chaîne : itgenoda494 (jeton d’actualisation obsolète/utilisateur lié deux fois à la même application OAuth).
Ce que nous avons déjà essayé (sans bon résultat)
- Remplacer l’ancien refresh-token de notre application dans le conteneur de données Invantive Cloud existant → le jeton avait déjà été utilisé ;
itgeneor362. - Supprimer le conteneur de données dans la base de données et ajouter un nouveau conteneur avec le même (ancien) jeton → même message ; le nouveau jeton était dans le conteneur supprimé.
- Cliquer sur “renouveler l’autorisation” dans Invantive (leur propre connexion Exact Online, même client-id + utilisateur) → deuxième chaîne à côté de la nôtre, puis à nouveau
itgeneor362/itgenoda494. - Laisser un deuxième conteneur de données Exact à côté de l’ancien → deux chaînes, une gagne, l’autre s’éteint.
Ce qui a bien fonctionné : supprimer l’ancien conteneur de données, reconnecter Exact Online dans notre application, attendre 9,5 minutes, puis un nouveau conteneur de données Exact Online (nl) vide avec des Identifiants pré-authentifiés (client-id une fois, uniquement le nouveau refresh-token, ne pas supprimer après collage).
Question
Quel est le processus prescrit lorsque les autorisations Exact Online changent et que nous obtenons donc un nouveau refresh-token dans notre application, alors qu’il existe déjà une base de données Invantive utilisant l’ancien jeton ?
- Ce nouveau refresh-token doit-il toujours être réinstallé dans Invantive Cloud (mettre à jour le conteneur
eolexistant, ou toujours une nouvelle base de données/conteneur de données) ? - Ou bien Invantive prend-elle automatiquement en charge la nouvelle chaîne avec le même utilisateur Exact + même client-id ?
- L’ancienne base de données/conteneur de données peut-elle rester en place lors de la transition, ou doit-elle être supprimée pour éviter une deuxième chaîne ?
Nous recherchons l’ordre officiel afin que nous ne laissions pas à nouveau deux chaînes se rafraîchir en parallèle.
Environnement
- Invantive Cloud (SaaS,
https://cloud.invantive.com) - Invantive Bridge Online, OData4 (
https://bridge-online.invantive.com) - Exact Online NL
- Authentification : Identifiants pré-authentifiés (refresh-token de notre application OAuth)