Reportez-vous à la documentation de Mise en oeuvre
Présentation
L'écran associé à la fonction permet de définir les paramètres associés à la création ou à la mise à jour de l'univers.
Champs
Les champs suivants sont présents dans cet onglet :
Datamart
| Permet de préciser le code du datawarehouse à partir duquel on génère l'univers. |
| Permet de préciser le code du datamart à partir duquel on génère l'univers. |
| Ce champ est uniquement affiché ; son contenu est déterminé de la façon suivante :
La création de l'univers se fait en effet de façon systématique sans supprimer les univers précédents qui existent, pour des raisons évidentes de sécurité. Lorsqu'un univers est créé alors qu'un univers précédent existait déjà pour le même datamart, les états associés à l'univers précédent sont automatiquement "remappés" vers le nouvel univers si la case correspondante est cochée. |
Traduction
| Définit la langue d'origine dans laquelle les états business objects standards sont livrés; ce sont ces états qui vont être dupliqués et "mappés" avec l'univers en cours de création lors de l'opération de génération. |
| Définit la langue à utiliser pour créer l'univers (un univers est forcément défini dans une langue donnée). Les états standards fournis seront également traduits dans cette langue. |
Options
| Cette case présente pour information n'est pas saisie, elle est cochée si, dans la définition du datamart, la case Autorisation par site est cochée. Dans ce cas, la génération ajoute automatiquement les filtres idoines sur les objets concernés. Le filtrage se fait par le biais d'un lien vers la table AX3ACCES. |
| Lorsque cette case est cochée, l'univers permet de filtrer les données en tenant compte des codes d'accès autorisés à l'utilisateur. Ceci est fait en créant automatiquement des liens vers une table nommée AX3ACCES. |
| Lorsque cette case est cochée, l'univers n'est pas réellement créé, mais un fichier de trace détaillé donne l'ensemble des opérations qui seront réalisées par la fonction de création. |
|   |
|   |
| Si cette case est cochée, l'univers généré dans le designer d'univers est exporté vers le serveur business objects. Le référentiel commun est alors à jour. Si la case n'est pas cochée, l'univers reste confiné au designer; on peut alors le visualiser à partir du designer sur le serveur, voire le modifier avant de l'exporter. Le fait de décocher cette case n'a donc d'intérêt que lorsqu'on désire faire des tests. |
| Lorsque cette case est cochée, un "remapping" des états est automatiquement fait. En effet, dans Business Objects, les états sont liés aux univers sur lesquels ils sont créés par des jeux de pointeurs internes. Toute modification d'un univers suppose donc le rétablissement de ces liens de façon automatisée, faute de quoi les états d'origine ne pourront plus marcher. Si cette phase n'est pas faite, il faudra ultérieurement réaliser un mapping manuel pour chaque état. |
Cette fonction peut être lancée en batch. La tâche standard ABICREUNV est prévue à cet effet.
Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :
Un problème (probablement réseau ) d'accès au serveur existe.
Le datamart saisi n'existe pas dans le datawarehouse choisi.
Le processus de création d'univers génère une trace. Les messages qui suivent apparaissent donc dans le fichier trace.
Lors de la création d'univers, des répertoires doivent exister sur le serveur sur lequel se trouve installé Business Object, afin que les scripts de création idoines puissent y être déposés. Ce message signifie que les répertoires en question n'ont pas pu être créés, notamment parce que l'utilisateur n'a pas le droit de les créer ou pour une autre raison (plus de place disque, par exemple).
Lors du contrôle de cohérence de l'ensemble des éléments de l'univers, une incohérence a été détectée : par exemple une hiérarchie décrite dans l'univers fait référence à un élément qui n'existe plus, une condition prédéfinie (invite) inexistante...
Une table ne peut pas être créé parce que tous les champs de cette table sont désactivés par le biais de code activités inactifs.
Une lien entre tables fait référence à une dimension qui porte un code activité non actif.
Le champ qui permet de contrôler l'accès à une table n'est pas présent dans l'agrégat. Ceci peut être le cas si un contrôle par code d'accès a été activé.