How to Migrate to HOPEX V1R1 FR. Révisé le : 19 novembre Créé le : 31 mars Auteur : Jérôme Horber

Transcription

1 How to Migrate to HOPEX V1R1 FR Révisé le : 19 novembre 2013 Créé le : 31 mars 2010 Auteur : Jérôme Horber

2 SOMMAIRE Résumé Ce document décrit les procédures nécessaires à la mise à jour des données MEGA vers HOPEX V1R1 à partir de MEGA 2009 SP5. Pour les versions antérieures, il est nécessaire de réaliser une mise à jour intermédiaire vers MEGA 2009 SP5 CP9 ou supérieur. Ce document s'applique à tous les Front-Ends de HOPEX 1.0 : HOPEX Web Front-End. Windows Front-End. Advisor Front-End. Ce document s applique également aux différents formats de stockage pour les données MEGA : Oracle SQL Server GBMS Il ne décrit pas : la configuration requise ni les architectures possibles (voir le documentation générale sur l'architecture). comment procéder à l installation (voir la documentation d installation). comment installer un Cumulative Patch (voir la documentation de mise à jour par CP). comment gérer les installations (voir les manuels d administration). le fonctionnement des licences (voir la documentation sur les licences). comment utiliser les fonctionnalités (voir les guides utilisateurs). comment mettre à jour les programmes (voir la documentation d'installation). Voir aussi les autres documents concernant la migration vers HOPEX : How to prepare to migrate to HOPEX - MEGA 2009 SP5 EN: préparer la migration vers HOPEX. Metamodel changes - HOPEX V1R1 : description des changements métamodèle (à usage des experts). Migration : The holistic case : description des meilleures pratiques de modélisation. How to Migrate to HOPEX V1R1 FR page 2/31

3 Sommaire... 2 Migrer les données vers HOPEX V1R Vérifier la disponibilité d'hopex... 5 Vérifier les données... 5 Sauvegarder la spécification des comportements... 5 Vérifier le métamodèle, les verrous, les transactions et les workflows... 5 Vérifier la cohérence du format de stockage... 5 Mettre à jour les données... 6 Mettre à jour la base système et les référentiels de données... 7 Lancer les outils de conversion... 8 Revoir les privilèges RDBMS... 8 Mettre à jour les procédures stockées... 9 Déplacer les fichiers.jar personnalisés... 9 Paramétrer l'option "Gestion de l'assignation de rôles métier aux personnes" Définir l'option 'Définition du parcours de MetaAssociations' Restaurer les comportements des MetaAssociations Vérifier les données mises à jour Premier contrôle de la migration Contrôle de la cohérence des données Autres points à vérifier Annexe Détail des conversions Détail des utilitaires Structure du fichier MetaAssociation_Behaviors_Before_2013.csv Questions fréquentes How to Migrate to HOPEX V1R1 FR page 3/31

4 MIGRER LES DONNEES VERS HOPEX V1R1 Avec HOPEX, MEGA a choisi de faire appliquer certaines règles pour assurer la cohérence des données. Par conséquent : L'unicité est requise pour certaines MetaAssociations (description de diagramme, détention). L'orientation de certaines MetaAssociations a changé. Pour cette raison la migration comprend plusieurs étapes principales : 1. Préparer la migration des données Cette tâche nécessite de disposer de la version MEGA 2009 SP5 CP9 ou d'un CP supérieur. Cela permet de vérifier que le données sont conformes au futur métamodèle et que les personnalisations concernant le comportement des MetaAssociations ont été sauvegardées. La plupart de ces tâches nécessite une expertise humaine et ne peut pas être automatisée. 2. Mettre à jour les données Cette tâche nécessite de disposer de la version majeure HOPEX V1R1 ou d'un CP supérieur. Cela permet de mettre à jour le métamodèle et de convertir les données au format requis par HOPEX. Vous pouvez mettre à jour les données en lançant les outils de conversion manuellement à partir de la console d'administration (Administration.exe). 3. Vérifier les données et personnalisations mises à jour Cette tâche consiste à vérifier que d'un point de vue utilisateur : les données modélisées ont été correctement migrées. les personnalisations ont été correctement migrées. La plupart de ces tâches nécessite une expertise humaine et ne peut pas être automatisée. How to Migrate to HOPEX V1R1 FR page 4/31

5 VERIFIER LA DISPONIBILITE D'HOPEX Cette tâche nécessite de disposer de la version MEGA 2009 SP5 CP9 ou d'un CP supérieur. Ils s'agit d'un pré-requis à la mise à jour des données vers HOPEX V1R1. Vérifier les données Pour chaque référentiel de données, identifiez et corrigez les données erronées. Pour plus de détails, voir le document "How to prepare to migrate to HOPEX - MEGA 2009 SP5". Sauvegarder la spécification des comportements Pour chaque environnement, sauvegardez la spécification du comportement dans une note système de la base système. Pour plus de détails, voir le document "How to prepare to migrate to HOPEX - MEGA 2009 SP5". Vérifier le métamodèle, les verrous, les transactions et les workflows Pour chaque environnement : Vérifiez que le métamodèle est stable. Si la compilation de l'environnement génère des erreurs dans le journal d'erreurs MEGA, vous devez corriger ces erreurs avant de mettre à jour les données. Vérifiez qu'aucune transaction (maintenant appelée "espace de travail privé") ne persiste. Si c'est le cas, publiez ou supprimez ces transactions. Pour la base système et pour chaque référentiel de données : Vérifiez l'absence de verrous. S'il en existe, supprimez-les. Vérifiez que tous les workflows sont terminés (qu'aucune instance de workflow n'est en cours). Si c'est le cas, terminez ou supprimez ces instances de workflow. Vérifier la cohérence du format de stockage Avec MEGA 2009 SP5, il était techniquement possible (même si non recommandé) d'avoir des référentiels dans un format de stockage différent. Exemple : la base système est stockée au format GBMS et les référentiels de données sont stockés au format SQL Server. Cette situation n'est plus tolérée : à partir d'hopex tous les référentiels de données ainsi que la base système doivent utiliser le même format de stockage (GBMS ou SQL Server ou Oracle). Exemple : la base système et tous les référentiels de données sont stockés au format SQL Server. How to Migrate to HOPEX V1R1 FR page 5/31

6 METTRE A JOUR LES DONNEES Avant de continuer, assurez-vous que, pour chaque environnement MEGA à mettre à niveau : Les données sont sauvegardées (sauvegarde physique). Le mot de passe de l'utilisateur "Administrateur" est connu ou remis à zéro. Ceci est très important car il sera demandé de se connecter avec le login "Administrator". Pour chaque environnement MEGA, plusieurs étapes sont nécessaires : Mettez à jour la base système en utilisant la mise à jour automatique de l'environnement. Lancez une conversion technique sur la base système et les référentiels de données en utilisant le stockage RDBMS. Lancez les outils de conversion sur la base système. Lancez les outils de conversion sur les référentiels de données. La procédure d'installation varie selon le type de stockage. Notes importantes : 1) Après conversion de la base système vers HOPEX, Une nouvelle fenêtre de connexion apparaît. Les utilisateurs Administrator et User ne sont plus disponibles. Par conséquent, lorsque vous ouvrez l'environnement MEGA Utilisez l'identifiant System (par défaut aucun mot de passe) au lieu de Administrator Utilisez l'identifiant Mega (par défaut aucun mot de passe) au lieu de User. 2) Avec le stockage RDBMS (Oracle, SQL Server), une conversion appelée "Technical Conversion" est requise pour chaque référentiel de données et pour la base système. Tant qu'une conversion n'est pas réalisée pour un référentiel de données (par exemple : Adventure) : Le référentiel est affiché comme étant non disponible (icône représentant une croix rouge) Un avertissement peut être affiché, par exemple "You cannot access repository XXX. Its internal structure is not up to date. Run the menu "Technical Conversion" to perform the upgrade." Cliquez sur "OK" pour masquer l'avertissement. How to Migrate to HOPEX V1R1 FR page 6/31

7 Mettre à jour la base système et les référentiels de données Pour le stockage RDBMS (Oracle et SQL Server) Procédure en version HOPEX V1R1 : 1. Lancez la console d administration. 2. Référencez l'environnement à convertir. 3. Sélectionnez l'environnement : Un avertissement apparaît : "Vous ne pouvez pas accéder à la base "SystemDb". Its internal structure is not up to date. Run the menu "Technical Conversion" to perform the upgrade.' 4. Cliquez sur "OK" pour masquer l'avertissement. 5. Faites un clic droit sur l'environnement et sélectionnez "Conversions techniques". La fenêtre "MEGA RDBMS conversion technique" s'affiche. 6. Cliquez sur OK pour confirmer la conversion de la base système. Attendez jusqu'à ce que la conversion soit terminée (de 30 mn à plusieurs heures en fonction de la taille de la base système et de la machine). Une ligne "Conversion technique terminée" apparaît. 7. Cliquez sur «Fermer». 8. Sélectionnez et ouvrez l'environnement à mettre à jour avec l'utilisateur Administrator. Un avertissement apparaît : Votre environnement et votre site ne sont pas dans la même version. Votre environnement nécessite une mise à jour. Veuillez vous référer à la documentation relative à cette action. 9. Cliquez sur «OK». Un message apparaît : Votre environnement nécessite une mise à jour pour compatibilité avec votre version de MEGA. Voulez-vous exécuter cette procédure maintenant? 10. Cliquez sur "Oui". Une fenêtre "Mise à jour automatique" est affichée. 11. Lisez les informations, cochez la case «J ai pris connaissance du texte ci-dessus» puis cliquez sur «OK». Le processus 'Mise à jour automatique d'environnement' est exécuté. Attendez jusqu à ce que la mise à jour soit terminée (généralement 30 mn). Un message tel que : 'Votre environnement a été mis à jour avec succès' apparaît. 12. Cliquez sur «OK» 13. Pour chaque référentiel de données : a. Sélectionnez le référentiel de données (par exemple : Adventure) b. Cliquez droit et sélectionnez Conversion Technique. La fenêtre "MEGA RDBMS Conversion technique" apparaît. c. Cliquez sur OK pour confirmer la conversion de la base système. Attendez jusqu à ce que la conversion soit terminée (généralement 30 mn). Une ligne "Conversion technique terminée" apparaît. d. Cliquez sur «Fermer» e. Fermez l environnement. 14. Fermez la console d administration. How to Migrate to HOPEX V1R1 FR page 7/31

8 Pour le stockage RDBMS Procédure : 1. Lancez la console d administration. 2. Sélectionnez et ouvrez l'environnement à mettre à jour avec l'utilisateur Administrator. 3. Une question est posée : 'Votre environnement requiert une mise à jour pour la compatibilité avec votre version de MEGA'. Voulez-vous exécuter cette procédure maintenant? 4. Lisez les informations, cochez la case «J ai pris connaissance du texte ci-dessus» puis cliquez sur "OK". 5. Le processus 'Mise à jour automatique d'environnement' est exécuté. 6. Attendez jusqu à ce que la mise à jour soit terminée. 7. Un message tel que : 'Votre environnement a été mis à jour avec succès' apparaît. 8. Cliquez sur «OK». 9. Fermez l environnement. 10. Fermez la console d administration. Lancer les outils de conversion Avant de continuer, consultez le tableau "Détail des conversions" dans ce document pour voir si les conversions sont pertinentes dans votre contexte. Procédure : 1. Lancez la console d administration. 2. Sélectionnez et ouvrez l'environnement à mettre à jour avec l'utilisateur Administrator 3. Dans le dossier "Référentiels", sélectionnez 'Systemdb'. 4. Faites un clic droit et sélectionnez Conversions > Convertir les données dans la version courante >A partir des données MEGA Une liste de conversions apparaît. 5. Cochez les conversions appropriées. Voir le tableau "Détail des conversions" plus loin dans ce document. 6. Cliquez sur 'OK' pour lancer la conversion. Attendez jusqu à ce que la conversion soit terminée. 7. Fermez l environnement. 8. Au moment d'ouvrir l'environnement MEGA, utilisez l'identifiant system (aucun mot de passe par défaut). 9. Dans le dossier "Référentiels", pour chaque référentiel : 10. Sélectionnez le référentiel. 11. Faites un clic droit et sélectionnez Conversions > Convertir les données dans la version courante > A partir des données MEGA Cochez les conversions appropriées. Voir le tableau "Détail des conversions" plus loin dans ce document. 13. Cliquez sur 'OK' pour lancer la conversion. 14. Quittez la console d administration MEGA. Revoir les privilèges RDBMS Les privilèges sont nécessaires à la gestion des procédures stockées. Par conséquent, chaque utilisateur Oracle nécessite un privilège supplémentaire pour l'instance de la base de données : GRANT CREATE PROCEDURE TO <MEGAUSR>; How to Migrate to HOPEX V1R1 FR page 8/31

9 Pour SQL Server, aucun privilège supplémentaire n'est nécessaire puisque le rôle "db_owner" permet déjà de gérer les procédures stockées. Mettre à jour les procédures stockées Cette étape est obligatoire pour chaque référentiel ou base système utilisant le stockage RDBMS (Oracle, SQL Server). Accédez aux outils d'administration de Oracle/SQL Server. La permission de supprimer et de créer des procédures stockées est nécessaire. Les procédures stockées existantes (créées dans la précédente version) doivent être supprimées. Vous pouvez les supprimer à partir de l'outil d'administration de Oracle / SQL Server. Les procédures stockées doivent être créées dans la version courante. Vous pouvez les créer à partir de la console d'administration. Procédure générale : La procédure exacte dépend de l'outil d'administration Oracle/SQL Server. Dans l'outil d'administration Oracle : Pour chaque schéma (référentiel de données ou base système) : Supprimez la procédure stockée 'SP_CLEAN_MEGA_DATABASE'. Supprimez la procédure stockée 'SP_CONSOLIDATE_MEGA_DATABASE'. Dans l'outil d'administration SQL Server Pour chaque base de données (référentiel de données ou base système) : Supprimez la procédure stockée 'xxx.sp_clean_mega_database'. Supprimez la procédure stockée 'xxx.sp_consolidate_mega_database' Dans l'installation d'hopex : Lancez la console d administration. Au moment d'ouvrir l'environnement MEGA, utilisez l'identifiant system (aucun mot de passe par défaut). Dans le dossier "Référentiels", pour chaque référentiel : Faites un clic droit et sélectionnez "Administration RDBMS > Suppression des données temporaires de la transaction". Cliquez sur "Nettoyer". Attendez jusqu'à ce que le message "Operation completed successfully" apparaisse (peut prendre plusieurs minutes). Cliquez sur «OK». Faites un clic droit et sélectionnez "Administration RDBMS > Suppression des données historisées de la base". Cliquez sur "Consolider". Attendez jusqu'à ce que le message "Operation completed successfully" apparaisse (peut prendre plusieurs minutes). Cliquez sur «OK». Fermez l environnement. Quittez la console d administration. Notez qu'il est important de planifier (mode batch) l'exécution de toutes ces procédures stockées. Référez-vous au document "Repository - RDBMS Installation Guide HOPEX V1R1" pour obtenir la liste complète. Déplacer les fichiers.jar personnalisés Cette étape est obligatoire si des fichiers.jar ont été personnalisés. Les fichiers.jar personnalisés doivent être déplacés du dossier '<HOPEX installation path>\java\lib' vers un nouveau dossier '<HOPEX installation path>\java\lib_usr'. How to Migrate to HOPEX V1R1 FR page 9/31

10 Dans la cas où vous ignorez si vos fichiers.jar ont été personnalisés, vérifiez la liste des fichiers.jar fournis en standard plus loin dans ce document. Il est probable que les fichiers.jar non listés soient personnalisés. Paramétrer l'option "Gestion de l'assignation de rôles métier aux personnes" Cette étape nécessite une décision pour chaque environnement MEGA. Dans les options MEGA, groupe "Référentiel > Gestion des utilisateurs", une option "Gestion de l'assignation de rôles métier aux personnes" est disponible aux niveaux installation et environnement. Cette option permet de contrôler la sélection des profils en fonction de la valeur choisie : non coché : les profils sont assignés via les logins. coché : les profils sont assignés via les rôles métier. Valeur Non coché Coché Recommandé Recommandé pour compatibilité avec les versions MEGA 2009 et précédentes Recommandé pour les nouveaux projets et pour les solutions HOPEX Notez que l'option est cochée par défaut à partir de HOPEX V1R1. Vous pouvez modifier la valeur à tout instant sans impact sur les données. Cependant, la fenêtre de connexion et la gestion des utilisateurs sont impactées. Définir l'option 'Définition du parcours de MetaAssociations' Cette étape nécessite une décision pour chaque environnement MEGA. Dans les options MEGA, groupe "Référentiel", une option "Définition du parcours de MetaAssociations" est disponible aux niveaux installation et environnement. Cette option permet de contrôler la manière dont le comportement des MetaAssociations est interprété, en fonction de la valeur choisie : Compatibilité jusqu'à MEGA 2009 : Le comportement des MetaAssociations est interprété en utilisant la logique de MEGA Depuis MEGA HOPEX 1.0 : Le comportement des MetaAssociations est interprété en utilisant la nouvelle logique. Valeur Compatibilité jusqu'à MEGA 2009 Depuis MEGA HOPEX 1.0 Recommandé Nécessaire pour compatibilité avec les versions 2009 et précédentes (personnalisation des bases de données et système) Recommandé pour les nouveaux projets et pour l'alignement des référentiels (contrôle plus strict sur les objets). Si le comportement a été personnalisé (personnalisation de la base système) en MEGA 2009, la compatibilité n'est pas assurée. Une revue nécessitant du temps et une expertise peut se révéler nécessaire. Notez que 'A partir de MEGA HOPEX 1.0' est la valeur par défaut à partir de HOPEX V1R1. Vous pouvez modifier la valeur et compiler l'environnement sans impact sur les données excepté le namespace. Votre modification affectera néanmoins le comportement (namespace, navigation, extraction, protection, export, comparaison...) Restaurer les comportements des MetaAssociations Cette étape nécessite une décision pour chaque environnement MEGA dans lequel l'option "Définition du parcours de MetaAssociations" est positionnée sur "Compatibilité jusqu'à MEGA 2009". How to Migrate to HOPEX V1R1 FR page 10/31

11 Une partie des changements métamodèle entre MEGA 2009 et HOPEX concerne l'orientation des MetaAssociations (permutation). Ceci affectera les comportements des MetaAssociations concernées. Vous pouvez décider de restaurer le comportement sauvegardé précédemment en MEGA 2009 SP5 pour cet environnement. Si l'option est positionnée sur ''A partir de MEGA HOPEX 1.0", la restauration n'a pas d'intérêt. Choix Restaurer Ne pas restaurer Recommandé Si des problèmes importants induits par le changement d'orientation des liens sont identifiés durant les tests. Pour préserver autant que possible la définition standard du comportement. Si vous utilisez l'alignement des référentiels. How to Migrate to HOPEX V1R1 FR page 11/31

12 La procédure suivante s'applique à un environnement dans lequel les comportements on été sauvegardés dans un fichier "MetaAssociation_Behaviors_Before_2013.csv" en version MEGA 2009 SP5. Procédure : 1. Lancez Windows Front-End (Mega.exe). 2. Ouvrez un espace de travail privé (anciennement "transaction") avec un utilisateur autorisé à mettre à jour les données MEGA. 3. Lancez l'éditeur de script en utilisant le menu Outils > Editeur de script. 4. Ouvrez la macro 'MetaAssociation Behaviors - Restore'. 5. Lancez la macro. 6. Quittez et publiez votre espace de travail. L'exécution de la macro restaure les comportements tels qu'ils l'étaient dans le version précédente. Par exemple, si un comportement était [Deep, Abort], il est restauré à [Abort, Deep] pour prendre en compte le fait que les MetaAssociationEnds majeures et mineures ont été interverties. La restauration affecte uniquement la spécification du comportement utilisé avec le mode de compatibilité (Compatibilité jusqu'à MEGA 2009). Elle n'affecte pas la spécification du comportement utilisé avec le nouveau mode (A partir de MEGA HOPEX 1.0). How to Migrate to HOPEX V1R1 FR page 12/31

13 Elle génère également le rapport MetaAssociation_Behaviors_Since_2013.csv. Le fichier est archivé dans le dossier racine de l'environnement MEGA. Il s'agit d'un tableau où chaque ligne est une combinaison Opérateur x MetaAssociation. Pour chaque ligne, plusieurs propriétés sont décrites sous forme de colonnes : Colonnes Commentaire Opérateur ID et nom de l'opérateur MetaAssociation ID et nom de la MetaAssociation NewMajorClass Identifiant de la MetaClasse majeure après permutation NewMajorEnd Identifiant de la MetaAssociationEnd majeure après permutation NewMinorClass Identifiant de la MetaClasse mineure après permutation NewMinorEnd Identifiant de la MetaAssociationEnd mineure après permutation NewMinMajBehavior Comportement (Abort, Link, Deep) lorsque la MetaAssociation est utilisée après permutation et avant restauration NewMajMinBehavior Comportement (Abort, Link, Deep) lorsque la MetaAssociation est utilisée après permutation et avant restauration (de la MetaClasse majeure à travers la MetaAssociationEnd mineure) Switched Booléen. Les MetaAssociationEnds ont été permutées (majeure/mineure) au cours du processus de mise à jour OldMinMajBehavior Comportement de la MetaAssociation vue de la MetaClasse mineure à travers la MetaAssociationEnd majeure (majeur et mineur définis comme avant la permutation). OldMajMinBehavior Comportement de la MetaAssociation vue de la MetaClasse majeure à travers la MetaAssociationEnd mineure (majeur et mineur définis comme avant la permutation). SetMinMajBehavior Comportement de la MetaAssociation vue de la MetaClasse mineure à travers la MetaAssociationEnd majeure après restauration (majeur et mineur définis comme après la permutation). SetMajMinBehavior Comportement de la MetaAssociation vue de la MetaClasse majeure à travers la MetaAssociationEnd mineure après restauration (majeur et mineur définis comme après la permutation). Tous les identifiants se présentent sous la forme suivante : hexaidabs[nom] Les comportements sont donnés explicitement à partir de la liste : {Abort; Link; Deep; Standard; Computed; Null} How to Migrate to HOPEX V1R1 FR page 13/31

14 VERIFIER LES DONNEES MISES A JOUR Il est fortement recommandé de sauvegarder chaque environnement une fois qu'il a été mis à jour. Le processus d'installation et de mise à jour standard prend en charge toutes les conversions qui peuvent être automatisées. D'un point de vue technique, la réussite de la conversion des données est garantie par : L'exécution correcte du traitement de mise à jour automatique de l'environnement. Si des erreurs interviennent au cours de cette étape, le processus de migration doit être stoppé, de manière à réaliser un diagnostic. Vérifiez soigneusement le journal d'erreurs MEGA. L exécution correcte de toutes les conversions obligatoires sur la base système. Si des erreurs interviennent au cours de cette étape, le processus de migration doit être stoppé, de manière à réaliser un diagnostic. l exécution correcte de toutes les conversions obligatoires sur chaque référentiel utilisateur. Si des erreurs interviennent au cours de cette étape, le processus de migration doit être stoppé, de manière à réaliser un diagnostic. Après exécution totale du processus de migration, il est fortement recommandé de vérifier les données et les personnalisations de différentes manières : Un premier contrôle après migration : faites un premier tour d'horizon pour vérifier que les données semblent correctes. Une vérification de la cohérence des données : lancez les utilitaires pour faire respecter les règles concernant la structure des données. D'autres points à vérifier. Premier contrôle de la migration Il est fortement recommandé de faire un premier tour pour vérifier que les données mises à jour semblent correctes. Evidemment, ce type de contrôle ne peut pas être exhaustif, mais il permet généralement d'avoir un premier retour et d'identifier rapidement certaines erreurs de migration. Exemple de scénario : Ouvrez un espace de travail privé (anciennement transaction) Parcourez les objets en utilisant l outil de recherche, les arbres de navigation et les diagrammes. Faites de petites modifications (par exemple : modifier un caractère dans un commentaire, déplacer légèrement un objet dans un diagramme, etc.) Publiez l'espace de travail privé. Contrôle de la cohérence des données Beaucoup de choses étaient tolérées, même si déconseillées, dans les versions précédentes. Pour assurer une meilleure cohérence, les contrôles sont maintenant plus rigoureux et de nombreuses recommandations sont devenues des restrictions. Ainsi, il est nécessaire de revoir en détail le contenu du référentiel et éventuellement de "faire du ménage". Différents utilitaires sont fournis pour contrôler la cohérence des données : o Objets n'ayant pas de détenteur. o Objets ayant plusieurs détenteurs. o Connecteurs invalides. o Objets non affichés dans les diagrammes. o Objets principaux non reliés à un utilisateur. Dans les options, groupe "Référentiel", vérifiez que la valeur du paramètre 'Accès métamodèle' est 'Expert'. How to Migrate to HOPEX V1R1 FR page 14/31

15 Ces utilitaires peuvent être lancés aussi souvent que nécessaires jusqu'à résolution des problèmes. Lorsqu'un utilitaire est lancé de nouveau, il met à jour la liste des objets invalides, et enlève ceux qui ont été traités. Il est conseillé de corriger les objets invalides jusqu'à ce que la liste soit vide. Objets sans détenteur ou avec détenteurs multiples Chaque objet doit avoir un et un seul détenteur. Les objets qui n'ont pas de détenteur ne peuvent pas être atteints par les outils standards et ne peuvent donc pas être exportés. Des utilitaires sont fournis pour contrôler la détention de chaque objet. Lancez le menu Outils > Nettoyer > Query Objects with No Owner. Lancez le menu Outils > Nettoyer > Query Objects with Multiple Owners. Les objets invalides sont automatiquement ajoutés à des dossiers Favoris partagés pour étude ultérieure. Ces dossiers sont 'Objects with No Owner et 'Objects with Multiple Owners', ainsi que des sous-dossiers de '_Objects to be Cleaned'. Pour les détenteurs multiples, le pré-traitement avant migration devrait avoir résolu la plupart des cas. Les cas restants peuvent se présenter lorsqu'un objet peut être détenu par différents types d'objets. Si un objet est détenu par plusieurs autres objets ayant un cycle de vie différent, le transfert vers un de ces détenteurs risque d'endommager les autres, qui ne seraient pas validés ou applicables et par conséquent deviendraient incohérents dans la base de production. La situation la plus fréquemment rencontrée pour les détenteurs multiples est la suivante : un objet est à la fois le "sous-" ou le composant d'un autre objet et il fait partie d'une bibliothèque. S'il existe un doute sur le bon détenteur, il est préférable de choisir la bibliothèque. Il est fort probable qu'il y ait plusieurs centaines de détenteurs multiples, voire plus. La plupart ne sont plus utilisés et peuvent être supprimés sans problème. Pour la plupart des autres, il sera aisé de retrouver le détenteur grâce aux diagrammes dans lesquels les objets apparaissent. How to Migrate to HOPEX V1R1 FR page 15/31

16 Les objets principaux n'ayant pas de détenteur devraient généralement être placés dans une bibliothèque. Si un objet principal est en même temps "sous-objet" d'un autre objet et est membre d'une bibliothèque, la bibliothèque devrait être privilégiée sauf si l'objet est utilisé uniquement dans le contexte de son parent. Un "sous"-objet ne devrait pas être réutilisable. Connecteurs invalides La plus grande partie des objets d'un référentiel sont des "connecteurs" (message, flux, connecteurs, échange, interaction...). Ils sont utilisés pour relier deux objets dans le contexte d'un troisième objet. Leur description est souvent complétée par un quatrième objet (par exemple le contenu pour un message, le protocole pour une interaction, etc.). En tant qu'objets composants, les connecteurs sont dénués de signification hors de leur contexte. Ils sont également dénués de signification sans les objets qu'ils relient entre eux. Un connecteur invalide peut introduire une dépendance empêchant de lancer le workflow de validation de son détenteur. Le schéma suivant représente deux modèles de base pour connecteurs. Un utilitaire est fourni pour trouver les connecteurs qui ne remplissent pas cette exigence. Lancez le menu Outils > Nettoyer > Query Objects with Multiple Owners. Les objets invalides sont automatiquement ajoutés au dossier 'Broken Connectors' des favoris partagés pour étude ultérieure. Le dossier est un sous-dossier de '_Objects to be Cleaned'. How to Migrate to HOPEX V1R1 FR page 16/31

17 Les connecteurs invalides peuvent généralement être supprimés sans problème. Objets non affichés dans les diagrammes Les diagrammes sont des représentations graphiques des modèles. Lorsqu'un objet fait partie d'un autre (dans son modèle), il est généralement affiché dans au moins un de ses diagrammes. Ce qui aurait pu être montré mais se produit "dans les coulisses" devrait se produire rarement. Il se peut que la situation soit voulue et assumée mais dans la plupart des cas elle arrive "par hasard". La situation classique se présente lorsqu'un utilisateur enlève un objet d'un diagramme au lieu de le supprimer ou de demander sa suppression. Ce qui arrive dans les coulisses sans que personne ne le sache conduit à des incohérences entre modèles et diagrammes : lorsque par exemple un message est simplement enlevé d'un diagramme, il relie toujours l'émetteur et le récepteur. Un utilitaire est fourni pour contrôler les objets non présents dans les diagrammes. Lancez la commande Outils > Nettoyer > Query Objects with No Owner. Les objets invalides sont automatiquement ajoutés au dossier 'Objects Not in Diagrams' des favoris partagés pour étude ultérieure. Le dossier est un sous-dossier de '_Objects to be Cleaned'. How to Migrate to HOPEX V1R1 FR page 17/31

18 De nombreux objets invalides peuvent ne pas être des éléments de bibliothèque et il peut s'avérer très long de les vérifier en fonction de leur présence dans le diagramme. En fonction de la stratégie de modélisation choisie, il est possible qu'on ait choisi délibérément de ne pas faire apparaître certains objets dans les diagrammes ; il n'est donc pas nécessaire de les vérifier. Un dossier 'MetaClasses to Scan' contient des listes de métaclasses traitées par l'utilitaire. Si un type d'objets n'apparaît jamais dans un diagramme de manière délibérée, la métaclasse correspondante peut être retirée de cette liste. Objets principaux non reliés à un utilisateur Les objets principaux sont ceux qui peuvent être validés et/ou transférés (par exemple : les objets des métaclasses "Objet candidat à la validation" ou "Objet candidat au transfert". Ils constituent le squelette du référentiel. Les liens entre eux forment l'architecture et lui donnent un sens. Un objet principal qui ne contribue pas à l'architecture a peu d'intérêt et encombre le référentiel. Un utilitaire permet de trouver les objets principaux qui ne sont utilisés nulle part. Lancez le menu Outils > Nettoyer > Query Main objects with No Users. Les objets invalides sont automatiquement ajoutés au dossier 'Main Objects with No User' des favoris partagés pour étude ultérieure. Le dossier est un sous-dossier de '_Objects to be Cleaned'. How to Migrate to HOPEX V1R1 FR page 18/31

19 Cet exercice consiste à distinguer les nouveaux objets non encore utilisés des objets anciens qui ne sont plus utilisés (parce qu'une tâche de conception n'est pas terminée par exemple). La date de création constitue un bon critère pour les distinguer. En fonction de la stratégie de modélisation choisie, certains objets peuvent être isolés de manière intentionnelle ; dans ce cas il n'est pas nécessaire de procéder à une vérification. Un dossier 'MetaClasses to Scan' contient des listes de métaclasses traitées par l'utilitaire. Si un type d'objets n'est jamais utilisé ailleurs de manière délibérée, la métaclasse correspondante peut être retirée de cette liste. How to Migrate to HOPEX V1R1 FR page 19/31

20 Autres points à vérifier Si des extensions ont été faites au métamodèle, elles doivent être revues conformément aux règles structurantes décrites ci-dessus. Une attention particulière doit être portée à l'orientation des MetaAssociations puisque cette orientation gouverne le comportement des objets associés. Si des personnalisations ont été effectuées (pages de propriétés, paramétrage des diagrammes, rapports types, programmes basés sur les APIs scripts..), il est nécessaire d'effectuer une vérification spécifique par rapport aux spécifications de personnalisation initiales. Comme les personnalisations sont souvent basées sur des couches standards, il se peut qu elles ne soient pas prêtes à être utilisées et qu'elles aient un aspect différent. Cette vérification nécessite des compétences fonctionnelles et en développement de la plate-forme. Sujet Utilisateur Profils Workflows Advisor API script Commentaire La mise en oeuvre a changé. Un outil convertissant les utilisateurs au nouveau format est fourni. Il est obligatoire de revoir la configuration des utilisateurs (paramètres de connexion, privilèges d'administration). Notez qu'avec HOPEX il est recommandé de définir les options et lignes de commandes au niveau profil. Les fonctionnalités "Gestion des accès" et 'Gestion des filtres' sont remplacées par la gestion des permissions. Un outil convertissant les utilisateurs au nouveau format est fourni. Il est obligatoire de revoir la configuration des profils. Cette revue doit se baser sur les spécifications fonctionnelles initiales. La configuration et la mise en oeuvre des workflows a évolué. Un outil convertissant les définitions de workflow au nouveau format est fourni. Il convertit également les données relatives au workflow. Il est recommandé de revoir la configuration du workflow surtout si les workflows ont été personnalisés. Il est conseillé de baser cette revue sur les spécifications fonctionnelles initiales. La mise en oeuvre de l'autentification et du mapping a évolué. Les informations sont maintenant sauvegardées dans la base système de l'environnement. Les utilitaires webusermapping.exe et MappingDatabase.xml ne sont pas plus fournis. Un outil convertissant les données de mapping et d'authentification au nouveau format est fourni. Il est obligatoire de revoir la configuration des utilisateurs (paramètres de connexion, privilèges d'administration). La mise en oeuvre a changé. Veuillez vous référer au document 'Metamodel changes - HOPEX V1R1'. Aucun outil n'est fourni pour le code spécifique. Aucune indication particulière n'est fournie. Il est recommandé de revoir les macros personnalisées et les applications utilisant les API script, en particulier pour les API d'administration. Il est conseillé de baser cette revue sur les spécifications fonctionnelles initiales. Périmère de la migration concernant les workflows : Catégorie Elément Migré Définition de workflow - Oui Données relatives au Instances de workflow Oui (1) workflow Objets Demandes de changement Oui Objets tâches de conception Oui Notification Oui (1) à l'exception des instances de workflow de validation. How to Migrate to HOPEX V1R1 FR page 20/31

21 La conversion des données relatives aux workflows est garantie pour le métamodèle de workflow et les définitions de workflow standards (tâches de conception, demandes de changement, validation). How to Migrate to HOPEX V1R1 FR page 21/31

22 ANNEXE Détail des conversions Si les conversions obligatoires ne sont pas effectuées sur les bases, des dysfonctionnements ou des pertes de données peuvent survenir. Il est nécessaire de convertir les bases une seule fois seulement. Cliquez avec le bouton droit sur un référentiel et sélectionnez Conversions > Conversion des données dans la version courante, puis la version source "A partir des données MEGA 2009" pour afficher les conversions. Conversions MEGA Advisor - Conversion of mapping Convertit la correspondance utilisateurs (stockée dans le fichier MappingDatabase.xml) au nouveau format (stocké dans la base système). Cette conversion présuppose que la machine courante héberge une installation MEGA Advisor, que le fichier MappingDatabase.xml est disponible, et que tous les environnements référencés dans le fichier.xml sont disponibles. Cette conversion est obligatoire pour la base système si vos données proviennent de MEGA Ne lancez pas cette conversion si vous vous trouvez dans l'une des situations suivantes : - Vous n'utilisez pas MEGA Advisor. - Vous utilisez MEGA Advisor mais l'application est installée sur une autre machine (dans ce cas, lancez la conversion depuis l'autre machine). - Vous utilisez MEGA Advisor sur cette machine avec la correspondance par défaut (pas de fichier MappingDatabase.xml). Cette conversion est mise en oeuvre par une macro MEGA 'MEGA Advisor - Conversion of mapping.method' appelant un script externe 'convert_mapping.vbs'. MEGA APM - Conversion of Application Assessment Cette conversion transforme l'évaluation de l'application en une session d'évaluation de l'application. L'évaluation de l'application est permise par Application Portfolio Management (APM). Cette conversion est obligatoire pour les référentiels de données si vous avez utilisé APM. Cette conversion est mise en oeuvre par une macro "MEGA APM - Conversion of Assessment of application". MEGA APM - Conversion of Application Ownership A partir d'hopex, la spécification de la responsabilité change pour application. La spécification de la responsabilité pour application est permise par Application Portfolio Management (APM). Cette conversion crée l'assignation en tant que propriétaire de l'application pour l'utilisateur relié à chaque application. Cette conversion est obligatoire pour les référentiels de données si vous avez utilisé APM. Cette conversion est mise en oeuvre par une macro 'MEGA APM - Conversion of Application Ownership'. MEGA IT Planning - Master Plans : Conversion of Type Attribute to Link to Plannable Metaclasses Référe ntiel MEGA Base systè me Mise à jour à partir de 2009 Non Oui Oui si Advisor est utilisé KB Oui Non Non KB Oui Non Non KB Oui Non Oui KB How to Migrate to HOPEX V1R1 FR page 22/31

23 Conversions L'attribut Type pour les Plans d'évolution (Stratégique, solution, application, etc) est désapprouvé. La conversion le remplace par un lien vers les métaclasses dépendantes du temps correspondant à chacun des types. Cette conversion est obligatoire pour chaque référentiel si vos données proviennent de la version MEGA Cette conversion est mise en oeuvre par une macro "Conversion of Type Attribute to Link". MEGA Repository - Conversion of link instances to Generic MetaAssociation Cet utilitaire met à jour le métamodèle pour permettre une gestion générique de certaines MetaAssociations (vers Note, Document...). La conversion des liens alias peut prendre plusieurs minutes en fonction du volume de données et nécessite de compiler le métamodèle. Cette conversion est obligatoire pour les bases de données et la base système si vos données proviennent de MEGA 2009 ou de versions antérieures MEGA Repository - Conversion of name properties Aligne les noms des objets avec leur définition dans le métamodèle La conversion peut prendre plus ou moins de temps en fonction du volume des données. Cette conversion est obligatoire pour les bases de données et la base système si vos données proviennent de MEGA 2009 ou de versions antérieures Elle doit être lancée à chaque version majeure ou mise à jour par Release Pack. 'MEGA Repository - Conversion of old MetaAssociation into deprecated MetaAssociation' A partir d'hopex, plusieurs MetaAssociations sont considérées obsolètes. Cette conversion rend ces MetaAssociations obsolètes. Cette conversion est mise en œuvre par un script externe (convert_deprecated_metaassociation.vbs). MEGA Repository - Conversion of report template simple type parameters Cette conversion convertit certains rapports types (rapports types avec des paramètres types simples : booléen, chaîne de caractères,...) au nouveau format. Cette conversion est obligatoire pour la base système si vos données proviennent de la version MEGA Cette conversion est implémentée par un script convert_reporttemplate_simpletypeparams.vbs MEGA Repository - Conversion of reports simple type parameters Cette conversion convertit certains rapports (rapports avec des paramètres types simples : booléen, chaîne de caractères,...) au nouveau format. Cette conversion est obligatoire pour chaque référentiel si vos données proviennent de la version MEGA Cette conversion est mise en œuvre par un script externe (convert_report_simpletypeparams.vbs). MEGA Repository - Conversion of name properties Ce traitement convertit la configuration précédente (aux niveaux environnement et profil) au nouveau format. Cette conversion est obligatoire pour la base système si vos données proviennent de la version MEGA Cette conversion est codée en C++ et ne peut pas être Référe ntiel MEGA Base systè me Mise à jour à partir de 2009 Oui Oui Oui KB Oui Oui Oui KB Non Oui Non KB Non Oui Oui KB Oui Non Oui KB Non Oui Oui KB How to Migrate to HOPEX V1R1 FR page 23/31

24 Conversions personnalisée. MEGA Repository - Conversion of User into Person (System) with Login and Profile Cette conversion convertit les utilisateurs au nouveau format (Personne (Système)), Login et Profil). Les valeurs des mots de passe utilisateur sont cryptées. Cette conversion est obligatoire pour la base système si vos données proviennent de MEGA 2009 Cette conversion est mise en œuvre par un script externe (convert_megaperson_to_megalogin.vbs). MEGA Repository Update initial foundation : 'MEGA Library' Cet utilitaire importe 'megalibrary.xmg' qui est nécessaire pour que MEGA fonctionne correctement. Cette conversion est obligatoire pour les bases de données si vos données proviennent de MEGA 2009 ou de versions antérieures MEGA Requirement Tracker - Conversion of Requirements Convertit les spécifications des exigences vers un nouveau format pour permettre un nouveau type de synchronisation. Cette conversion est obligatoire pour les référentiels de données si vos données proviennent de MEGA Cette conversion est mise en oeuvre par une macro "Conversion of requirements'" MEGA TeamWork - Conversion of Metamodel (Design Task, Request For Change, Workflow Instance, Notation,...) Cette conversion transfert les objets de la base système vers un référentiel pour certaines MetaClasses (Tâche de conception, Demande de changement, Instance de workflow, Notation, Instance de statut de workflow, Instance de transition de workflow) Ce traitement peut prendre plusieurs minutes. Ce traitement fera passer le métamodèle en mode «non compilé» : il sera nécessaire de le recompiler. Cette conversion est obligatoire pour chaque référentiel si vos données proviennent de la version MEGA Cette conversion est mise en œuvre par un script externe (convert_teamworkmetamodel.vbs). MEGA TeamWork - Conversion of Metamodel Data A partir d'hopex, le statut de workflow du sujet de workflow est calculé différemment lorsque le workflow a des transitions parallèles. Cette conversion convertit les statuts de workflow parallèle au nouveau format. Cette conversion est obligatoire pour les référentiels de données si vous avez utilisé les workflows (MEGA Teamwork). Cette conversion est mise en oeuvre par une macro MEGA (MEGA TeamWork - Conversion of Workflow Parallel Status.Method). MEGA TeamWork - Conversion of Metamodel (System) Convertit la définition de workflow au nouveau format. Cette conversion est obligatoire pour la base système si vous avez utilisé les workflows (MEGA Teamwork). Cette conversion est mise en oeuvre par une macro MEGA (MEGA TeamWork - Conversion of Workflow Definition Main Workflow Attribute.Method). Référe ntiel MEGA Base systè me Mise à jour à partir de 2009 Non Oui Oui KB Oui Non Oui KB Oui Non Oui KB Oui Non Oui KB Oui Non Non KB Non Oui Oui KB How to Migrate to HOPEX V1R1 FR page 24/31

25 Détail des utilitaires Utilitaire Diagrammes (dessins) Cet utilitaire ouvre, enregistre et referme tous les diagrammes du référentiel. Permet la conversion des diagrammes et de leur dessin au format MGE. Permet également de contrôler le statut de tous les diagrammes du référentiel. Cette conversion est optionnelle pour la base système et les référentiels de données. La conversion peut prendre plus ou moins de temps en fonction du volume des données. Cette conversion est codée en C++ et ne peut pas être personnalisée. MEGA Publisher - Remove invalid MEGA templates Cet utilitaire supprime les modèles ou composants MEGA devenus invalides après la mise à jour. Pour éviter d'inutiles erreurs de conversion, vous devez le lancer avant la conversion 'MEGA Publisher - Replacement of tag 'name' with 'shortname' in HTML/RTF descriptors'. Cet utilitaire est implémenté par une macro ' MEGA Publisher - Remove invalid MEGA templates (2009 and earlier versions)' MEGA Repository - Automatic Assignment Generator Cette utilitaire génère une assignation pour chaque objet Personne (Système) relié à un profil via un login. Cette conversion est mise en œuvre par un script externe ('automatic_assignment_generator.vbs'). MEGA Repository - Cleanup Cet utilitaire supprime les données techniques temporaires qui ne sont plus valides après la mise à jour (par exemple : les requêtes récentes). Cette conversion est mise en œuvre par la macro MEGA 'MEGA Repository - Cleanup.Method'. MEGA Repository - Conversion of name properties (longname) Cet utilitaire aligne les noms des objets avec leur définition dans le métamodèle (noms longs) pour certaines métaclasses : contrôle, exigence, risque, facteur de risque, temporisateur. Cette conversion peut prendre plusieurs minutes en fonction du volume des données. Cette conversion est codée en C++ et ne peut pas être personnalisée. MEGA Repository - Conversion of Organisational Charts Cet utilitaire convertit la nature des organigrammes pour qu'ils puissent être ouverts avec MEGA Process BPMN Edition. Il permet d'éviter de créer de nouveaux organigrammes pour MEGA Process BPMN Edition. Cette conversion est mise en oeuvre par une macro 'Organisational Chart Conversion'. MEGA Repository - Conversion of Person into Person (System) Cet utilitaire crée un nouvel objet personne (système) pour chaque objet personne et crée un lien de traçabilité entre ces deux objets. Cet utilitaire est mis en œuvre par un script externe ('Convert_Person_to_MegaPerson.vbs'). Référe ntiel MEGA Base systè me Mise à jour à partir de 2009 Oui Oui Optionnel. KB Non Oui Optionnel. KB Non Oui Optionnel. KB Oui Non Optionnel. KB Oui Non Optionnel. KB Oui Non Optionnel. KB Oui Non Optionnel. KB How to Migrate to HOPEX V1R1 FR page 25/31

26 Utilitaire MEGA Repository - Convert Advisor Web Site Template Pages Cet utilitaire permet de modifier l'affichage de la page Advisor et de revenir à la présentation MEGA 2009 SP4 et versions précédentes. Ne lancez pas cet utilitaire si vous n'utilisez pas MEGA Advisor ou si vous êtes satisfait de la présentation des pages. Cet utilitaire est implémenté par la macro WebSiteTemplatePages.Migrate'. MEGA Repository - Convert Report templates (MS Word) to RTF Format L'utilitaire convertit les rapports types (MS Word) de Word au format Rtf. Il est nécessaire de le lancer pour pouvoir générer des rapports (MS Word) avec MEGA Web Front-End. Si vous n'utilisez pas MEGA Web Front-End ou ne générez pas de rapports (MS Word), il est recommandé de ne PAS lancer cet utilitaire. Cette conversion est codée en C++ et ne peut pas être personnalisée. MEGA Repository - Creation of links instances from MEGA fields Cet utilitaire crée des liens d analyse d impact pour les objets référencés par des champs MEGA dans les propriétés. La conversion peut prendre plus ou moins de temps en fonction du volume des données. Cette conversion est codée en C++ et ne peut pas être personnalisée. Shapes Cet utilitaire met à jour les formes personnalisées et les convertit au format le plus récent. Les formes se trouvant dans le dossier 'Mega_usr' ou l'environnement MEGA et l'installation sont mises à jour. Cette conversion est optionnelle pour la base système. Cette conversion peut prendre plusieurs minutes en fonction du volume des données. Cette conversion est codée en C++ et ne peut pas être personnalisée. Référe ntiel MEGA Base systè me Mise à jour à partir de 2009 Non Oui Optionnel. KB Non Oui Optionnel. KB Oui Oui Optionnel. KB Non Oui Optionnel. KB Structure du fichier MetaAssociation_Behaviors_Before_2013.csv Ce rapport consiste en un tableau où chaque ligne est une combinaison Opérateur x MetaAssociation. Pour chaque ligne, plusieurs propriétés sont décrites sous forme de colonnes : Colonnes Opérateur MetaAssociation MajorEnd MinorEnd brestricted MinorToMajor MajorToMinors Commentaire ID et nom de l'opérateur ID et nom de la MetaAssociation ID de la MetaAssociationEnd majeure en MEGA 2009 avant permutation ID de la MetaAssociationEnd mineure en MEGA 2009 avant permutation 1 si une MetaAssocaiton générique surcharge le comportement 0 si ce n'est pas le cas (le comportement est défini au niveau MetaAssociation) Comportement (1) de la MetaAssociation vue de la MetaClasse mineure à travers la MetaAssociationEnd majeure en MEGA 2009 avant permutation Comportement (1) de la MetaAssociation vue de la MetaClasse majeure à travers la MetaAssociationEnd mineure en MEGA 2009 avant permutation How to Migrate to HOPEX V1R1 FR page 26/31