La migration de la gestion du cycle de vie Oracle Hyperion Enterprise Performance Management System depuis et vers Oracle Hyperion Planning est une opération longue.
Certains artefacts Planning ont des dépendances, par exemple, les formulaires ont des dépendances dimensionnelles. Au lieu de migrer uniquement les membres de dimension requis pour un formulaire, la gestion du cycle de vie migre toute la dimension. Vous devez sélectionner manuellement les dépendances nécessaires. Reportez-vous à Migration d'artefacts.
Les applications source et de destination doivent avoir exactement les mêmes paramètres pour Type de plan, Calendrier et Devise unique ou Multidevise.
Si Planning n'existe pas dans l'environnement cible, la gestion du cycle de vie crée un interpréteur d'application.
Oracle Essbase doit être en mode Oracle Hyperion Shared Services pour utiliser la gestion du cycle de vie.
Les artefacts Essbase sont affichés sous le noeud d'application Planning et l'artefact de données apparaît sous la catégorie de données Essbase.
En cas de première migration d'un environnement de test vers un environnement de production, Oracle recommande de migrer tous les artefacts liés à Planning sous le noeud Planning.
Oracle recommande de ne migrer des données Essbase qu'en cas de première migration d'un environnement de test vers un environnement de production, et pas pour des migrations incrémentielles.
Pour exporter ou importer des artefacts de données Planning, la gestion du cycle de vie doit disposer d'un chemin d'accès au système de fichiers partagé.
Pour permettre la migration de données dans des environnements distribués, filesystem.artifact.path doit être un chemin partagé. L'emplacement du système de fichiers de la gestion du cycle de vie doit être accessible à partir de tous les environnements dans la configuration distribuée.