Pourquoi utiliser une connexion d’entreprise enregistrée
La méthode « Connexion d’entreprise : nom d’utilisateur et mot de passe » obtient un ticket Cognos avec des identifiants enregistrés. Elle est destinée aux exécutions en arrière-plan et aux flux partagés qui doivent fonctionner avec les droits TM1 définis d’un compte. Le mot de passe est conservé sous forme chiffrée.
Choisissez un compte ayant accès aux objets précis nécessaires. Les personnes qui exécutent le flux peuvent avoir des droits UBC Data Bridge différents, mais IBM voit ce compte enregistré.
Configurer la connexion
- Sélectionnez la connexion d’entreprise avec nom d’utilisateur et mot de passe.
- Saisissez le nom d’utilisateur au format requis par le formulaire de connexion : nom d’utilisateur ou adresse électronique.
- Saisissez l’espace de noms Cognos, le mot de passe et l’adresse de la passerelle.
- Si la passerelle redirige vers un autre hôte d’authentification, ajoutez son nom d’hôte exact à « Hôtes du système de connexion ». N’indiquez ni protocole, ni chemin, ni caractère générique arbitraire.
- Cliquez sur « Tester » ; après réussite, enregistrez la connexion et vérifiez le flux dans un environnement de test.
Le champ gateway_url de la connexion est prioritaire sur la passerelle de l’installation. Les hôtes autorisés de la connexion complètent ceux configurés par l’administrateur via BRIDGE_CAM_LOGIN_HOSTS.
Pages de connexion prises en charge
La connexion automatique traite les formulaires HTML classiques de nom d’utilisateur et de mot de passe, notamment certaines configurations Cognos, Keycloak ou AD FS. La prise en charge dépend du formulaire réel, et pas seulement du nom du fournisseur.
Cette méthode ne peut pas effectuer un second facteur, un changement obligatoire de mot de passe, une acceptation de conditions ou des pages nécessitant une exécution dans le navigateur. Pour les exécutions interactives, utilisez « Depuis la session utilisateur ». Les exécutions automatiques nécessitent une méthode approuvée par l’organisation, sans participation interactive.
Renouvellement du ticket et échecs
Le ticket est mis en cache sous forme chiffrée. La première requête vérifie sa validité ; UBC Data Bridge en obtient un nouveau si nécessaire. Une requête de lecture sûre peut être répétée une fois après une réponse 401. Une requête qui modifie des données n’est pas répétée automatiquement.
Après un échec de connexion, les tentatives suivantes sont temporairement suspendues pour éviter une série d’échecs. « Tester » indique la cause : hôte bloqué, formulaire non pris en charge, second facteur, identifiants rejetés ou problème réseau. Corriger les identifiants enregistrés permet de tester les nouvelles valeurs.