Présentation #
L’outil Import / Export de BiBOARD permet de transférer des éléments d’un environnement vers un autre : développement vers recette, recette vers production, sauvegarde d’un ensemble d’objets ou livraison d’un lot de paramétrage.
Le fichier généré porte l’extension .bib. Il s’agit d’un format propriétaire BiBOARD, prévu pour être relu par l’assistant d’import BiBOARD.
Les formats pris en charge, les étapes d’utilisation de l’assistant et les possibilités d’automatisation en ligne de commande sont présentés ici.
Compatibilité de version
Un fichier .bib exporté depuis BiBOARD v18 doit être importé sur un environnement BiBOARD v18. Pour limiter les risques, il est recommandé d’utiliser la même version applicative et, si possible, le même niveau de correctif.
ATTENTION – Le .bib n’est pas un backup complet de base SQL
Un export .bib contient les objets fonctionnels sélectionnés, mais pas l’intégralité de la base BiBOARD. Il ne remplace pas une sauvegarde SQL Server complète avant une opération sensible.
Usages typiques #
- Livrer un tableau de bord validé depuis un environnement de recette vers la production.
- Sauvegarder un ensemble de TDB, requêtes, datasources et lots avant modification.
- Transférer une requête et sa datasource associée vers un autre site.
- Restaurer un objet fonctionnel après erreur de manipulation, sous réserve que l’import ne remplace pas un objet existant non souhaité.
- Industrialiser des imports via ligne de commande avec fichier d’association des connexions.
Accès à l’assistant #
Dans BiBOARD Administration, les boutons Export et Import se trouvent dans le ruban d’accueil. L’utilisateur connecté doit disposer des droits nécessaires sur les objets manipulés.
Objets concernés par l’import / export #
L’assistant affiche plusieurs familles d’objets. Les intitulés peuvent légèrement varier selon la traduction ou le contexte, mais la logique fonctionnelle reste la même.
| Famille | Objet technique | Rôle | Dépendances fréquentes |
| Tableaux de bord | TDB / dashboards | Écrans utilisateurs composés de composants visuels. | Dépendent des composants, datasources, liens entre TDB, éventuellement autres TDB via hyperliens. |
| Datasources | Hubs / PivotHubs | Objets Studio exposant les données aux composants. | Dépendent d’une requête pour un Hub, et d’un Hub source pour un PivotHub. |
| Requêtes | SQL | Requêtes utilisées par les Hubs ou par d’autres traitements. | Dépendent d’une connexion. |
| Connexions | Connexion base | Paramètres de connexion à une base ou source externe. | Exportées sans chaîne de connexion sensible ; association requise à l’import. |
| Datawarehouse | Lots ETL / traitements | Objets liés aux traitements Datawarehouse. | Peuvent dépendre de requêtes, connexions, horaires, paramètres. |
| Export | Lots d’export / mails | Tâches d’export de données, TDB, hubs ou traitements programmés. | Peuvent dépendre de TDB, hubs, connexions, horaires. |
| Environnement | Lots / éléments d’environnement | Objets de paramétrage selon contexte. | À contrôler selon usage. |
| Horaires | Planifications | Définitions de calendrier utilisées par les lots. | À inclure si les lots doivent être repris avec leur planification. |
Vous trouverez comment faire un export / import ici.
Chaîne de dépendance la plus fréquente #
Lorsqu’un TDB affiche des données, la chaîne habituelle est la suivante :
| TDB └─ Composants du TDB └─ Datasource / Hub ou PivotHub └─ Requête └─ Connexion |
INFO – Sélectionner un TDB peut suffire à inclure ses dépendances, mais uniquement si ces dépendances sont visibles par l’utilisateur qui réalise l’export.
Principe essentiel : dépendances et visibilité #
L’assistant d’export vérifie les dépendances des objets sélectionnés. Quand un objet dépend d’un autre, l’objet dépendant est automatiquement ajouté à la sélection et peut devenir non décochable.
BONNE PRATIQUE – Ce qui apparaît dans l’aperçu d’exportation part dans le fichier .bib. Ce qui n’apparaît pas dans l’aperçu ne doit pas être considéré comme exporté.
Cas important : TDB sélectionné mais datasources non publiées #
Si l’utilisateur sélectionne un TDB, BiBOARD cherche les datasources utilisées par les composants du TDB. Si ces datasources, leurs requêtes ou leurs connexions ne sont pas visibles par cet utilisateur, l’export peut devenir incomplet.
ATTENTION – Si le TDB est publié à l’utilisateur, mais pas les datasources / requêtes / connexions utilisées par ce TDB, il ne faut pas partir du principe qu’elles seront dans le fichier .bib. Pour un export fiable, il faut publier temporairement toute la chaîne technique au compte exporteur ou utiliser un compte SuperAdmin.
| Profil utilisateur | Visibilité | Conséquence pour l’export |
| Compte SuperAdmin | Voit en principe toutes les dépendances. | Méthode recommandée pour un export complet et contrôlé. |
| Compte administrateur non SuperAdmin | Ne voit que les objets qui lui sont publiés. | Publier TDB + datasources + requêtes + connexions + lots/horaires nécessaires. |
| Compte client limité | Risque de voir seulement le TDB. | Risque d’export incomplet si les dépendances techniques ne sont pas visibles. |
Comment contrôler les dépendances #
- Lancer l’export avec le compte prévu.
- Cocher le TDB ou l’objet principal.
- Cliquer sur l’action d’ajout à la sélection si nécessaire.
- Regarder l’aperçu exportation à droite.
- Vérifier que les sections Datasources, Requêtes et Connexions contiennent bien les objets attendus.
- Ne générer le .bib qu’après validation de cet aperçu.
Points d’attention et bonnes pratiques #
| Bonne pratique | Pourquoi |
| Toujours contrôler l’aperçu | L’aperçu est le meilleur indicateur du contenu réel du .bib. |
| Utiliser un compte adapté | SuperAdmin recommandé ; sinon publier toute la chaîne technique. |
| Préparer les connexions cibles | Créer les connexions avant import et valider les droits SQL. |
| Sauvegarder avant import | Faire une sauvegarde SQL ou un export de l’existant si des objets peuvent être mis à jour. |
| Tester après import | Ouvrir les TDB, exécuter les requêtes, tester les filtres, liens et lots. |
| Republication obligatoire | Revoir les groupes après import : TDB, datasources, requêtes, connexions, lots. |
| Attention aux objets de même nom | L’import peut mettre à jour au lieu de créer. |
| Attention aux lots | Contrôler horaires, destinataires, activation et environnement avant production. |
Règle de décision rapide #
Je dois livrer un TDB complet ?
- Exporter avec SuperAdmin ou publier toute la chaîne.
- Vérifier aperçu : TDB + Datasources + Requêtes + Connexions.
Je dois importer en production ?
- Sauvegarder avant.
- Préparer connexions.
- Importer.
- Republier.
- Tester.
Dépannage rapide #
| Symptôme | Cause probable | Action corrective |
| La datasource n’apparaît pas à l’export | Elle n’est pas visible par le compte exporteur ou le composant référence un objet absent. | Publier la datasource / utiliser SuperAdmin / vérifier le composant. |
| Erreur Hub not find ou DataSource not find | Dépendance manquante dans le .bib ou non importée. | Refaire l’export avec toutes les dépendances visibles. |
| Le TDB s’importe mais un composant est vide | Hub/requête/connexion mal associée ou non importée. | Vérifier les associations de connexion, base, schéma et tester la requête. |
| La requête pointe vers la mauvaise base | Mapping base/schéma absent ou incorrect. | Corriger l’association à l’import ou la requête après import. |
| Les utilisateurs ne voient pas le TDB importé | Publications groupes non reprises. | Publier le TDB dans la bonne catégorie/groupe. |
| Un objet existant a été modifié | Import par nom : mise à jour d’un objet existant. | Restaurer via sauvegarde/export préalable si besoin. |
| Import batch échoue | Fichier .bib ou mapping introuvable, URL incorrecte, erreur de connexion. | Contrôler chemins, URL, logs, droits du compte batch. |
Checklists client #
Avant export #
- Identifier précisément les objets à exporter : TDB, datasources, requêtes, lots, horaires.
- Choisir un compte exporteur avec visibilité suffisante.
- Si le compte n’est pas SuperAdmin, publier temporairement toute la chaîne technique.
- Ouvrir le TDB source et vérifier qu’il fonctionne avant export.
- Renseigner les notes d’export.
- Contrôler l’aperçu : aucune dépendance attendue ne doit manquer.
- Nommer clairement le fichier .bib.
- Conserver le fichier .bib avec date, environnement source et ticket de livraison.
Avant import #
- Vérifier la version BiBOARD cible.
- Sauvegarder la base BiBOARD cible ou exporter les objets existants qui pourraient être remplacés.
- Préparer les connexions cibles avec les bons droits SQL.
- Préparer les correspondances base/schéma si les noms diffèrent.
- Vérifier l’écran de statut : création ou mise à jour.
- Ne pas décocher les dépendances obligatoires.
- Conserver le log d’import.
Après import #
- Lire le log d’import et vérifier qu’il n’y a pas d’erreurs.
- Ouvrir chaque TDB importé.
- Tester les filtres, liens, hyperliens et composants pilotés.
- Tester les requêtes et datasources associées.
- Republier les TDB, datasources, requêtes et connexions aux groupes nécessaires.
- Pour les lots : vérifier horaires, destinataires, activation, chemins et pièces jointes.
- Faire valider par un utilisateur métier.