SAP BusinessObjects Information Design Tool (IDT) (Fichier) - Export
Prérequis du pont
Ce pont :n'est supporté que sous Microsoft Windows.
nécessite une installation de l'outil pour accéder à son SDK.
Spécifications du pont
Fournisseur | SAP |
Nom de l'outil | BusinessObjects (BO) Information Design Tool |
Version de l'outil | 14.1 à 14.x |
Site Web de l'outil | http://www.sap.com/solutions/sapbusinessobjects/large/intelligenceplatform/ (uniquement en anglais) |
Méthodologie supportée | [Business Intelligence] Conception BI (Source SGBDR, Cible dimensionnelle, Lignage de transformation, Parsage d'expression), Disposition graphique via l'API Eclipse Java sur le fichier Univers (.UNX) |
SPÉCIFICATIONS
Outil : SAP/BusinessObjects (BO) Information Design Tool version 14.1 à 14.x via l'API Java Eclipse sur un fichier Univers (.UNX)
Consultez http://www.sap.com/solutions/sapbusinessobjects/large/intelligenceplatform/
Métadonnées : [Business Intelligence] Conception BI (Source SGBDR, Cible dimensionnelle, Lignage de transformation, Parsage d'expressions), Disposition graphique
Composant : BoInformationDesignToolUnx version 11.2.0
VUE D'ENSEMBLE
Ce pont d'import requiert des SDK SAP BusinessObjects et un JRE Java spécifique, comme expliqué ci-dessous.
PRÉREQUIS
PRÉREQUIS JAVA
BusinessObjects supporte Java 8 uniquement et n'est pas compatible avec toute version d'OpenJDK, susceptible d'être le JRE par défaut.
Utilisez le paramètre Divers pour indiquer l'environnement Java supporté par BusinessObjects.
Les univers UNX basés sur des connexions JDBC sont supportés avec une JVM de 64 bits.
Pour les versions XI 4.2 et antérieures, les univers UNX basés sur d'autres types de connexions (ODBC, OLE DB, ...) ne sont supportés que si une JVM de 32 bits est utilisée.
Spécifiez le chemin d'accès à une JVM de 32 bits dans cette option, afin de supporter des univers UNX basés sur une connexion ODBC.
PRÉREQUIS SDK BUSINESS OBJECTS
Ce pont d'import s'appuie sur le SDK Java SAP BusinessObjects Semantic Layer pour exporter les métadonnées vers un univers UNX. Aussi, le SDK Java Semantic Layer doit être correctement installé sur l'ordinateur exécutant ce pont d'import.
Pour les versions XI 4.1 et ultérieures, le SDK Java Semantic Layer est supporté.
Pour les versions XI 4.0 et antérieures, le SDK Java Semantic Layer n'est pas supporté.
Pour vous assurer que le SDK Java Semantic Layer est correctement installé, vérifiez les points suivants :
- SAP BusinessObjects Information Design Tool peut être démarré sur la machine exécutant le pont d'import. Il est généralement installé parmi les outils clients de SAP BusinessObjects.
- Dans Panneau de configuration Windows > Programmes > Programmes et fonctionnalités, est répertorié "Outils client de la plateforme SAP BusinessObjects Business Intelligence 4.1".
- Dans le répertoire d'installation des outils clients BusinessObjects, il y a un dossier "SL SDK". Par exemple : C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\SL SDK
Le SL SDK requis n'est pas installé par défaut. Il doit être installé comme un composant supplémentaire aux outils clients.
Si le dossier "SL SDK" est absent du répertoire d'installation client :
- cliquez sur le bouton "Désinstaller/Modifier" concernant les "Outils client de la plateforme SAP BusinessObjects Business Intelligence 4.1" pour exécuter à nouveau l'asistant d'installation,
- Sélectionnez l'option Modifier et cliquez deux fois sur Suivant.
- Dans la page "Sélection des fonctionnalités", faites défiler jusqu'à Composants de développement et cochez la cases "SDK Java SAP BusinessObjects Semantic Layer",
- Suivez les étapes restantes pour installer les ressources du SDK Java Semantic Layer sur votre machine. Le dossier "SL SDK" est désormais disponible.
De plus, au moment de l'exécution du pont d'import, assurez-vous que vous disposez :
- d'un accès de connexion valide au serveur de référentiel BO (le pont d'import doit se connecter à la plateforme de BO)
Le SDK de la plateforme BusinessObjects BI est basé sur la technologie CORBA.
Lors de la connexion à un serveur distant, la couche de mise en réseau CORBA effectue une résolution bidirectionnelle du nom/de l'adresse du serveur.
Il faudra donc vous assurer que le nom/l'adresse du serveur spécifié(e) peut être résolu(e) dans l'environnement client.
En général, la résolution de nom réussit lorsque le client et le serveur font partie du même réseau d'entreprise.
Cependant, dans le cas d'une connexion d'un réseau client à un serveur situé sur un réseau différent (Amazon AWS par exemple),
il peut être nécessaire de configurer une entrée dans le fichier hôte local (C:\Windows\System32\drivers\etc\hosts) comme suit :
1.2.3.4 servername
FOIRE AUX QUESTIONS
Q : Quels nom d'utilisateur et mot de passe dois-je fournir pour me connecter ?
R : Veuillez fournir un nom d'utilisateur et un mot de passe BO, comme lorsque vous ouvrez l'univers avec l'outil de conception d'information.
Par exemple : Administrateur
Si vous avez des doutes concernant le nom d'utilisateur et le mot de passe à utiliser, contactez l'administrateur système BO de votre entreprise.
L'utilisateur doit être membre de groupes BusinessObjects :
- "Universe Designer Users (Utilisateurs d'Universe Designer)" pour pouvoir ouvrir des univers.
LIMITATIONS
Consultez les limitations générales connues actuellement sur MIMB Known Limitations ou dans Documentation/ReadMe/MIMBKnownLimitations.html où elles sont regroupées
1. Les univers UNX basés sur des connexions JDBC sont supportés. Pour les versions XI 4.2 et antérieures, les univers UNX basés sur d'autres types de connexions (ODBC, OLE DB, ...) ne sont supportés que si une JVM de 32 bits est utilisée.
2. La prise en charge des métadonnées du BusinessLayer est limitée aux dossiers et aux BusinessObjects. Les autres objets (Filtres, Hiérarchies...) ne sont pas supportés en version 4.1.
3. Seuls les univers basés sur des données relationnelles sont supportés.
SUPPORT
Fournissez un package de dépannage avec :
- le log de débogage (peut être défini dans l'UI ou dans conf/conf.properties avec MIR_LOG_LEVEL=6)
- la sauvegarde des métadonnées si disponible (peut être configurée dans le paramètre Divers avec l'option -backup, même si cette option commune n'est pas implémentée pour tous les ponts pour des raisons techniques).
Paramètres du pont
Nom du paramètre | Description | Type | Valeurs | Défaut | Périmètre | |||
Système | Saisissez ici le nom du référentiel BusinessObjects auquel vous connecter. Il s'agit du nom du Central Management Server. Ce serveur est utilisé pour se connecter, par défaut au port 6400. Par exemple : localhost. Si le serveur CMS est configuré dans un environnement Cluster, le nom du cluster peut être spécifié avec la syntaxe suivante, par exemple : cms:port@cluster. Par exemple : localhost:6400@MYCLUSTER |
Chaîne de caractères | ||||||
Mode d'authentification | Sélectionnez le mode d'authentification de connexion à utiliser. "Enterprise" Connexion à BusinessObjects Enterprise. "LDAP" Connexion à l'aide d'un serveur LDAP. "Windows AD" Connexion à l'aide d'un serveur Windows Active Directory. Note : l’authentification Windows AD peut être configurée à l'aide de fichiers de configuration Kerberos. Mettez à jour le fichier $MetaIntegration/conf/conf.properties pour spécifier les paramètres de la machine virtuelle Java : M_JAVA_OPTIONS=-Djava.security.auth.login.config=C:\Windows\bscLogin.conf -Djava.security.krb5.conf=C:\Windows\krb5.ini Pour plus d'informations, consultez la note SAP 1621106 : http://service.sap.com/sap/support/notes/1621106 |
ÉNUMÉRATION |
|
Enterprise | ||||
Username | Dans le cadre de l'installation d'un référentiel de BusinessObjects (BO), l'utilisateur doit s'identifier à l'aide d'un identifiant de connexion. Une installation autonome de BO ne nécessite pas d'identification de ce type. Par exemple : Administrateur L'utilisateur doit être membre du groupe BusinessObjects : "Universe Designer Users" pour pouvoir ouvrir des univers. |
Chaîne de caractères | Administrator - Administrateur | |||||
Password | Dans le cadre de l'installation d'un référentiel de BusinessObjects (BO), l'utilisateur doit s'identifier à l'aide d'un nom d'utilisateur et d'un mot de passe. | MOT DE PASSE | ||||||
Directory | Spécifiez ici le répertoire dans lequel générer les fichiers d'univers (couche de gestion, fondation de données). Ce répertoire est généralement le répertoire racine d'un projet IDT ou un de ses sous-répertoires. |
RÉPERTOIRE | Éléments obligatoires | |||||
Fichier de connexion | Spécifiez le fichier local de connexion CNX à utiliser pour l'univers. Ce fichier de connexion se trouve généralement dans le répertoire racine du projet IDT ou dans l'un de ses sous-répertoires. Le pont d'import doit connaître le nom d'une connexion fonctionnelle pour créer des tables et des jointures dans l'univers. Ce paramètre est obligatoire. |
Fichier | *.cnx | Éléments obligatoires | ||||
Qualificateur de catalogue de bases de données | Spécifiez le qualificateur de catalogue de bases de données, si nécessaire. Ce qualificateur est utilisé comme préfixe, lors de l'insertion de tables dans le DataFoundation. Pour Microsoft Access, il s'agit du chemin d'accès au fichier MDB. Par exemple : C:\Program Files (x86)\Business Objects\BusinessObjects Enterprise 12.0\Samples\en\UniverseSamples\efashion Pour Microsoft SQL Server, c'est le nom de la base de données. Par exemple : AdventureWorks2008 |
Chaîne de caractères | ||||||
Jointures externes du modèle de données | La plupart des outils de modélisation et d'ETL définissent uniquement les métadonnées des clés étrangères et ne spécifient pas le type de jointure SQL (interne ou externe) qui doit être défini dans les outils Business Intelligence. Ce paramètre contrôle le type de jointures générées pour chaque relation de clé étrangère. "False (Faux)" Utilise uniquement des jointures Inner (internes) pour les relations de clés étrangères. "True (Vrai)" Utilise la facultativité de la relation de clé étrangère (facultative/obligatoire) pour déterminer s'il faut utiliser une jointure "Inner (Interne)" ou "Outer (Externe)". |
BOOLEAN |
|
false | ||||
Détection du type dimensionnel | Lorsque vous utilisez ce pont d'import pour convertir un modèle de données créé avec un outil de modélisation des données ou ETL, puis le traitez pour en faire un modèle OLAP/BI, le rôle dimensionnel spécifié pour chaque table (de fait, de dimension, de dimension secondaire) est utilisé par le pont d'import pour inférer comment ces tables seront converties en faits et dimensions de BI. Ce paramètre contrôle la manière dont le rôle dimensionnel de la table supplémentaire (de fait, de dimension, de dimension secondaire) est déterminé, si le modèle source n'a pas spécifié ce rôle dimensionnel de la table. "Only as defined by source model (Uniquement tel que défini par le modèle source)" Utilisez le rôle dimensionnel des tables s'il est défini par le modèle source. "Auto detect additional Facts and Dimensions (Détecter automatiquement les dimensions et les faits supplémentaires)" Détectez automatiquement les tables de fait et de dimension à partir du schéma relationnel, en vous basant sur les clés étrangères. Cet algorithme considère les tables ayant des clés étrangères entrantes uniquement, comme des tables de fait. Les tables ayant des clés étrangères sortantes sont considérées comme des tables de dimension ou des tables de dimension secondaire selon la distance minimale (nombre de relations de clés étrangères) avec la table de fait. Les tables n'ayant pas de relation de clés étrangères avec toute autre table sont considérées comme des tables de dimension. "Manually specified additional Facts and Dimensions (Faits et dimensions supplémentaires spécifiés manuellement)" Spécifiez manuellement les tables de fait et de dimension. |
ÉNUMÉRATION |
|
Détecter automatiquement les dimensions et les faits supplémentaires | ||||
Détection des tables de fait de modélisation dimensionnelle | Lorsque vous utilisez ce pont d'import pour convertir un modèle de données créé avec un outil de modélisation des données ou ETL, puis le traitez pour en faire un modèle OLAP/BI, le rôle dimensionnel spécifié pour chaque table (de fait, de dimension, de dimension secondaire) est utilisé par le pont d'import pour inférer comment ces tables seront converties en faits et dimensions de BI. Ce paramètre vous permet de spécifier la liste des tables de fait de votre modèle et le pont d'import considérera ces tables comme des tables de fait lors de la génération des dimensions et des mesures. Par ex. dbo.Fact1; Fact2 Cette option est intéressante si l'outil source ne supporte pas la notion de rôle dimensionnel de la table et peut être utilisée pour contourner les limitations de l'outil source. Le comportement de ce paramètre peut être associé au paramètre "Détection des tables de dimension", afin que certaines tables soient gérées comme des tables de fait et d'autres comme des tables de dimension. |
Chaîne de caractères | ||||||
Détection des tables de dimension | Lorsque vous utilisez ce pont d'import pour convertir un modèle de données créé avec un outil de modélisation des données ou ETL, puis le traitez pour en faire un modèle OLAP/BI, le rôle dimensionnel spécifié pour chaque table (de fait, de dimension, de dimension secondaire) est utilisé par le pont d'import pour inférer comment ces tables seront converties en faits et dimensions de BI. Utilisez ce paramètre pour veiller à ce que le pont d'import considère toutes les tables comme des tables de dimension. "True (Vrai)" Le pont d'import considère que toutes les tables sont des tables de dimension. "False (Faux)" Le pont d'import utilise le rôle dimensionnel spécifié sur chaque table, s'il existe. Cette option est intéressante si l'outil source ne supporte pas la notion de rôle dimensionnel de la table et peut être utilisée pour contourner les limitations de l'outil source. Le comportement de ce paramètre peut être associé au paramètre "Détection des tables de fait", afin que certaines tables soient gérées comme des tables de fait et d'autres comme des tables de dimension. |
BOOLEAN |
|
true | ||||
Miscellaneous | INTRODUCTION Spécifiez les options Divers, commençant par un tiret et suivies éventuellement par des paramètres, par exemple : -connection.cast MyDatabase1="MICROSOFT SQL SERVER" Certaines options peuvent être utilisées plusieurs fois, si applicable, par exemple : -connection.rename NewConnection1=OldConnection1 -connection.rename NewConnection2=OldConnection2; La liste d'options pouvant être une longue chaîne, il est possible de la charger à partir d'un fichier qui doit être situé dans ${MODEL_BRIDGE_HOME}\data\MIMB\parameters et avoir l'extension .txt. Dans ce cas, toutes les options doivent être définies au sein de ce fichier comme seule valeur de ce paramètre, par exemple ETL/Miscellaneous.txt OPTIONS DE L'ENVIRONNEMENT JAVA -java.memory <taille maximale de la mémoire Java> (anciennement -m) 1 Go par défaut sur un JRE de 64 bits ou tel que défini dans conf/conf.properties, par exemple -java.memory 8G -java.memory 8000M -java.parameters <options de ligne de commande de Java Runtime Environment> (anciennement -j) Cette option doit être la dernière dans le paramètre Divers car tout le texte après -java.parameters est passé tel quel à la JRE. Par ex. -java.parameters -Dname=value -Xms1G L'option suivante doit être définie lorsqu'un proxy est utilisé pour accéder à Internet (cela est essentiel pour accéder à https://repo.maven.apache.org/maven2/ et exceptionnellement à quelques autres sites d'outils) afin de télécharger les bibliothèques logicielles tierces nécessaires. Note : La majorité des proxys sont relatifs au chiffrement (HTTPS) du trafic extérieur (à l'entreprise) et à la confiance en le trafic intérieur pouvant accéder au proxy via HTTP. Dans ce cas, une requête HTTPS atteint le proxy via HTTP où le proxy la chiffre en HTTPS. -java.parameters -java.parameters -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=3128 -Dhttp.proxyUser=user -Dhttp.proxyPassword=pass OPTIONS D'IMPORT DU MODÈLE -model.name <nom modèle> Écrase le nom du modèle, par ex. -model.name "My Model Name" -prescript <nom script> Cette option permet d'exécuter un script avant l'exécution du pont. Le script doit se situer dans le répertoire bin (ou comme spécifié dans M_SCRIPT_PATH dans conf/conf.properties) et avoir une extension .bat ou .sh. Le chemin d'accès au script ne doit pas inclure de symbole relatif au répertoire parent (..). Le script doit retourner le code de sortie 0 pour indiquer un succès ou une autre valeur pour indiquer un échec. Par exemple : -prescript "script.bat arg1 arg2" -postscript <nom script> Cette option permet d'exécuter un script après l'exécution réussie du pont. Le script doit se situer dans le répertoire bin (ou comme spécifié dans M_SCRIPT_PATH dans conf/conf.properties) et avoir une extension .bat ou .sh. Le chemin d'accès au script ne doit pas inclure de symbole relatif au répertoire parent (..). Le script doit retourner le code de sortie 0 pour indiquer un succès ou une autre valeur pour indiquer un échec. Par exemple : -postscript "script.bat arg1 arg2" -cache.clear Vide le cache avant l'import et va exécuter un import complet avec collecte incrémentale. Si le modèle n'a pas été modifié et que le paramètre -cache.clear n'est pas utilisé (collecte incrémentale), une nouvelle version ne sera pas créée. Si le modèle n'a pas été modifié et que le paramètre -cache.clear n'est pas utilisé (collecte incrémentale), une nouvelle version ne sera pas créée. -backup <répertoire> Cette option permet de sauvegarder les métadonnées d'entrée du pont à des fins de débogage. Le <répertoire> fourni doit être vide. L'utilisation principale de cette option concerne les ponts d'import des data stores, en particulier les ponts d'import basés sur des bases de données JDBC. Notez que cette option n'est pas opérationnelle sur certains ponts, notamment : - les ponts d'import basés sur des fichiers (car des fichiers d'entrée peuvent être utilisés à la place) - les ponts d'import de référentiels d'intégration de données/BI (car les outils natifs de sauvegarde du référentiel peuvent être utilisés à la place) - Certains ponts d'import basés sur des API (par ex. basés sur COM) pour des raisons techniques. OPTIONS DES CONNEXIONS DE DONNÉES Les connexions de données sont produites par les ponts d'import, généralement à partir des outils ETL/DI et BI pour faire référence aux data stores sources et cibles qu'elles utilisent. Ces connexions de données sont ensuite utilisées par les outils de gestion des métadonnées pour connecter ces dernières (connexion des métadonnées) à leurs data stores réels (par exemple, bases de données, système de fichiers, etc.) afin de produire le lignage complet de flux de données et de l'analyse d'impact de bout en bout. Le nom des connexions de données doit être unique dans chaque modèle d'import. Les noms de connexion de données utilisés dans les outils de conception DI/BI sont utilisés quand cela est possible, sinon ils sont générés en étant courts mais significatifs, comme le nom de la base de données/du schéma, le chemin d'accès au système de fichiers ou l'URI (Uniform Resource Identifier). L'option suivante vous permet de manipuler les connexions. Ces options remplacent les options héritées -c, -cd et -cs. -connection.cast ConnectionName=ConnectionType Lance une connexion à une base de données générique (par exemple ODBC/JDBC) pour un type de base de données précis (par exemple ORACLE) pour une analyse SQL, par exemple -connection.cast "My Database"="MICROSOFT SQL SERVER". La liste des types de connexions aux data stores comprend : ACCESS APACHE CASSANDRA DB2/UDB DENODO GOOGLE BIGQUERY HIVE MYSQL NETEZZA ORACLE POSTGRESQL PRESTO REDSHIFT SALESFORCE SAP HANA SNOWFLAKE MICROSOFT SQL AZURE MICROSOFT SQL SERVER SYBASE SQL SERVER SYBASE AS ENTERPRISE TERADATA VECTORWISE HP VERTICA -connection.rename OldConnection=NewConnection Renomme une connexion existante, par exemple, par ex. -connection.rename OldConnectionName=NewConnectionName Plusieurs connexions de bases de données existantes peuvent être renommées et fusionnées en une nouvelle connexion de base de données, par exemple : -connection.rename MySchema1=MyDatabase -connection.rename MySchema2=MyDatabase -connection.split oldConnection.Schema1=newConnection Scinde une connexion de base de données en une ou plusieurs connexions de base de données. Une connexion de base de données peut être scindée en une connexion par schéma, par exemple : -connection.split MyDatabase Toutes les connexions de base de données peuvent être fractionnées en une connexion par schéma, par exemple : -connection.split * Une connexion de base de données peut être explicitement fractionnée en une nouvelle connexion de base de données en ajoutant un nom de schéma à une base de données, par exemple : -connection.split MyDatabase.schema1=MySchema1 -connection.map SourcePath=DestinationPath Mappe un chemin d'accès source à un chemin d'accès de destination. Cela est utile pour les connexions aux systèmes de fichiers lorsque différents chemins d'accès pointent vers le même objet (répertoire ou fichier). Sur Hadoop, un processus peut écrire dans un fichier CSV spécifié avec le chemin d'accès complet HDFS, tandis qu'un autre processus lit d'une table Hive implémentée (externe) par le même fichier spécifié à l'aide d'un chemin d'accès relatif avec un nom et une extension de fichier par défaut, par exemple : -connection.map /user1/folder=hdfs://host:8020/users/user1/folder/file.csv Sous Linux, il peut être fait référence à un répertoire (ou à un fichier) donné tel que /data par plusieurs liens symboliques tels que /users/john et /users/paul, par exemple : -connection.map /data=/users/John -connection.map /data=/users/paul Sous Windows, il peut être fait référence à un répertoire donné tel que C:\data par plusieurs lecteurs réseau tels que M: et N:, par exemple : -connection.map C:\data=M:\ -connection.map C:\data=N:\ -connection.casesensitive ConnectionName Écrase les règles de rapprochement insensibles à la casse par défaut pour les identifiants d'objets dans la connexion spécifiée, si le type du data store détecté supporte cette configuration (par ex. Microsoft SQL Server, MySQL etc.), par exemple : -connection.casesensitive "My Database" -connection.level AggregationLevel Spécifie le niveau d'agrégation pour les connexions externes, par exemple -connection.level catalog Liste des valeurs supportées : server (serveur) catalog (catalogue) schema (schéma)(par défaut) OPTIONS BUSINESS OBJECTS Notez que le JRE par défaut du pont d'import peut ne pas être compatible avec SAP BusinessObjects selon : - la version du JRE : OpenJDK 11 plutôt qu'Oracle JVM 8. - l'architecture du JRE : pour les versions XI 4.2 et antérieures, un JRE de 32 bits est requis pour des univers BusinessObjects utilisant des connexions ODBC/OLE DB. Le pont d'import doit donc utiliser le JRE fourni avec BusinessObjects, par ex. "C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86\jre8\bin\java.exe" Pour les versions XI 4.3 et supérieures, un JRE SAP 64 bits est requis pour les univers BusinessObjects utilisant les connexions ODBC/OLE DB. Le pont d'import doit donc utiliser le JRE fourni avec BusinessObjects, par ex. "C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\sapjvm\jre\bin\java.exe" De plus, un référentiel BusinessObjects peut contenir deux types d'univers dont les exigences JRE sont différentes : un univers.UNV classique de l'outil de conception BusinessObjects qui est lu par un C++ COM basé sur le pont, - un univers.UNX du dernier outil de conception d'information (IDT) BusinessObjects pour lequel un JRE spécifique peut être défini comme suit : -businessobjects.idt.java32.memory <path> (anciennement -idtJre32m) Définit la quantité maximale de mémoire utilisée par le JRE pour l'IDT, par exemple : -businessobjects.idt.java32.memory 1G -businessobjects.idt.java32.memory 1024M |
Chaîne de caractères |
Mapping du pont
Les informations de mapping ne sont pas disponibles