How to Migrate to HOPEX V1R1 FR

Transcription

Révisé le : 19 novembre 2013
Créé le : 31 mars 2010
Auteur : Jérôme Horber
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.
page 2/31
Sommaire ........................................................................................................... 2
Migrer les données vers HOPEX V1R1................................................................. 4
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" ............ 10
Définir l'option 'Définition du parcours de MetaAssociations' .................................... 10
Restaurer les comportements des MetaAssociations ............................................... 10
Vérifier les données mises à jour ..................................................................... 14
Premier contrôle de la migration ......................................................................... 14
Contrôle de la cohérence des données ................................................................. 14
Autres points à vérifier ....................................................................................... 20
Annexe ............................................................................................................. 22
Détail des conversions ....................................................................................... 22
Détail des utilitaires ........................................................................................... 25
Structure du fichier MetaAssociation_Behaviors_Before_2013.csv ........................... 26
Questions fréquentes ....................................................................................... 28
page 3/31
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.
page 4/31
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.
page 5/31
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.
page 6/31
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.
page 7/31
Pour le stockage RDBMS
Procédure :
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.
2.
3.
4.
Lancez la console d’administration.
Sélectionnez et ouvrez l'environnement à mettre à jour avec l'utilisateur Administrator
Dans le dossier "Référentiels", sélectionnez 'Systemdb'.
Faites un clic droit et sélectionnez Conversions > Convertir les données dans la version
courante >A partir des données MEGA 2009.
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 2009.
12. 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>;
page 8/31
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'.
page 9/31
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é
Recommandé
Recommandé pour compatibilité avec les versions MEGA 2009 et
précédentes
Recommandé pour les nouveaux projets et pour les solutions
HOPEX
Coché
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 2009.
• Depuis MEGA HOPEX 1.0 : Le comportement des MetaAssociations est interprété en utilisant
la nouvelle logique.
Valeur
Compatibilité
jusqu'à
2009
Depuis MEGA HOPEX 1.0
MEGA
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".
page 10/31
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.
page 11/31
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).
page 12/31
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
Opérateur
MetaAssociation
NewMajorClass
NewMajorEnd
NewMinorClass
NewMinorEnd
NewMinMajBehavior
NewMajMinBehavior
Switched
OldMinMajBehavior
OldMajMinBehavior
SetMinMajBehavior
SetMajMinBehavior
Commentaire
ID et nom de l'opérateur
ID et nom de la MetaAssociation
Identifiant de la MetaClasse majeure après permutation
Identifiant de la MetaAssociationEnd majeure après permutation
Identifiant de la MetaClasse mineure après permutation
Identifiant de la MetaAssociationEnd mineure après permutation
Comportement (Abort, Link, Deep) lorsque la MetaAssociation est utilisée
après permutation et avant restauration
Comportement (Abort, Link, Deep) lorsque la MetaAssociation est utilisée
après permutation et avant restauration (de la MetaClasse majeure à travers
la MetaAssociationEnd mineure)
Booléen. Les MetaAssociationEnds ont été permutées (majeure/mineure) au
cours du processus de mise à jour
Comportement de la MetaAssociation vue de la MetaClasse mineure à travers
la MetaAssociationEnd majeure (majeur et mineur définis comme avant la
permutation).
Comportement de la MetaAssociation vue de la MetaClasse majeure à travers
la MetaAssociationEnd mineure (majeur et mineur définis comme avant la
permutation).
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).
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}
page 13/31
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.
stoppé, de manière à réaliser un diagnostic.
• l’exécution correcte de toutes les conversions obligatoires sur chaque référentiel utilisateur.
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'.
page 14/31
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.
page 15/31
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'.
page 16/31
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'.
page 17/31
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'.
page 18/31
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.
page 19/31
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
Définition de workflow
Données relatives au
workflow
Elément
Instances de workflow
Objets Demandes de changement
Objets tâches de conception
Notification
(1) à l'exception des instances de workflow de validation.
page 20/31
Migré
Oui
Oui (1)
Oui
Oui
Oui
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).
page 21/31
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
Advisor,
que
le
fichier
héberge
une
installation
MEGA
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 2009.
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.
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
page 22/31
Référe
ntiel
MEGA
Base
systè
me
Mise à jour à
partir de 2009
Oui
Oui si Advisor
est utilisé
KB 00004109
Oui
Non
Non
KB 00004194
Oui
Non
Non
KB 00004194
Oui
Non
Oui
KB 00003612
Non
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 2009.
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.
proviennent de la version MEGA 2009.
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.
(convert_report_simpletypeparams.vbs).
Ce traitement convertit la configuration précédente (aux niveaux
environnement et profil) au nouveau format.
proviennent de la version MEGA 2009.
Cette conversion est codée en C++ et ne peut pas être
page 23/31
Référe
ntiel
MEGA
Base
systè
me
Mise à jour à
partir de 2009
Oui
Oui
Oui
KB 00002500
Oui
Oui
Oui
KB 00001289
Non
Oui
Non
KB 00004238
Non
Oui
Oui
KB 00004012
Oui
Non
Oui
KB 00004009
Non
Oui
Oui
KB 00004011
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.
proviennent de MEGA 2009
(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.
vos données proviennent de MEGA 2009.
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.
(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.
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).
page 24/31
Référe
ntiel
MEGA
Base
systè
me
Mise à jour à
partir de 2009
Non
Oui
Oui
KB 00004010
Oui
Non
Oui
KB 00003025
Oui
Non
Oui
KB 00003613
Oui
Non
Oui
KB 00004008
Oui
Non
Non
KB 00004237
Non
Oui
Oui
KB 00004347
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.
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.
('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'.
(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.
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').
page 25/31
Référe
ntiel
MEGA
Base
systè
me
Mise à jour à
partir de 2009
Oui
Optionnel.
KB 00001270
Non
Oui
Optionnel.
KB 00003139
Non
Oui
Optionnel.
KB 00004006
Oui
Non
Optionnel.
KB 00003321
Oui
Non
Optionnel.
KB 00001892
Oui
Non
Optionnel.
KB 00003984
Oui
Non
Optionnel.
KB 00004007
Oui
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.
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.
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
personnalisée.
Référe
ntiel
MEGA
Base
systè
me
Mise à jour à
partir de 2009
Oui
Optionnel.
KB 00003498
Non
Oui
Optionnel.
KB 00003499
Oui
Oui
Optionnel.
KB 00002005
Non
Oui
Optionnel.
KB 00000362
Non
Structure du fichier MetaAssociation_Behaviors_Before_2013.csv
Ce rapport consiste en un tableau où chaque ligne est une combinaison
MetaAssociation.
Pour chaque ligne, plusieurs propriétés sont décrites sous forme de colonnes :
Colonnes
Opérateur
MetaAssociation
MajorEnd
MinorEnd
bRestricted
MinorToMajor
MajorToMinors
Opérateur
x
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
page 26/31
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}
page 27/31
QUESTIONS FREQUENTES
Lors de la conversion la fenêtre d'identification Windows a changé.
Après conversion de la base système vers HOPEX :
• Une nouvelle fenêtre de connexion apparaît.
• Les utilisateurs Administrateur et User ne sont plus disponibles
Au moment d'ouvrir l'environnement MEGA, utilisez l'identifiant system (aucun mot de passe n'est
nécessaire).
Un utilisateur mega (aucun mot de passe par défaut) est également disponible.
Avertissement "You cannot access repository "XXX"". Its internal structure
is not up to date. Run the menu "Technical Conversion" to perform the
upgrade'
Avec des mises à jour particulières, le format technique de la base peut changer. Comme expliqué,
vous pouvez avoir besoin de lancer un menu de conversion technique à partir de la console
d'administration. Voir la rubrique 'Upgrade the system database and data repositories' plus haut
dans ce document.
Avertissment "La version de la procédure stockée XX n'est pas correcte"
Avec des mises à jour particulières, le format technique du référentiel peut changer et les
procédures stockées doivent être réinitialisées. Vois la section "Mettre à jour les procédures
stockées" plus haut dans ce document.
page 28/31
Comment vérifier que tous les workflows sont terminés ?
Vous pouvez lancer les requêtes suivantes dans MEGA 2009 SP5 pour chaque référentiel :
Requête
Tous les workflows en cours
(workflows NON terminés)
Tous les workflows de validation
(basés
sur
le
workflow
"Validation" standard)
Code de la requête
Select [Instance de workflow] Where [Etat] = "R"
Select [Instance de workflow]
workflow]._Idabs ="9rvu(EEfAf30"
Where
[Définition
de
Le résultat peut être vide.
Veuillez noter que toutes les instances de workflow sont migrées sauf celles qui concernent les
workflows de validation.
Avertissement "le graphe des accès en écriture n'est pas compilé..."
Certaines actions peuvent laisser le graphe des accès en écriture (ex-graphe des autorisations) dans
un état non compilé.
Pour compiler le métamodèle de l'environnement :
2. Sélectionnez et ouvrez l'environnement à convertir avec l'identifiant System.
3. Sélectionnez le dossier "Gestion des utilisateurs".
4. Cliquez droit > Compiler le graphe des accès en écriture.
5. Cliquez sur Démarrer pour lancer la compilation.
Attendez la fin du traitement.
6. Cliquez sur "OK".
7. Quittez la console d’administration.
Journaux d'erreurs dans le fichier megaerrAAAAMMDD.txt après lancement
de la mise à niveau automatique
Certaines erreurs peuvent être journalisées après la mise à niveau automatique de l'environnement.
Compilez de nouveau le métamodèle de l'environnement et vérifiez si les erreurs sont journalisées
dans le fichier megaerrAAAAMMDD.txt.
• Si des erreurs sont journalisées : recherchez la cause des erreurs.
• En l'absence d'erreurs, reprenez le processus de migration.
Pour compiler le métamodèle de l'environnement :
9. Sélectionnez et ouvrez l'environnement à convertir avec l'identifiant System.
10. Sélectionnez l'environnement.
11. Cliquez droit > Métamodèle > Traduire et compiler.
12. Cliquez sur Démarrer pour lancer la compilation.
Attendez la fin du traitement.
page 29/31
13. Cliquez sur "OK".
14. Quittez la console d’administration.
Exemple de fichier d’erreur :
Thread(2ad0);gbmoccse.cpp(530) : error Application: 0x0100845E 14:02:51
There is no 'MetaAssociationEnd' for 'Absolute Identifier' that has the 'FJg(Rj
VGHzWE' value.
Thread(2ad0);gbmoccse.cpp(551) : error trace 14:02:51
Thread(2ad0);apiuse.cpp(1196) : error trace 14:02:51
Thread(2ad0);apiuse.cpp(1273) : error trace 14:02:51
Liste des fichiers .Jar installés par MEGA 2009 SP5
Le dossier <Chemin d'installation>\java\lib peut contenir :
• des fichiers .jar standards : installés par MEGA.
• des fichiers .jar personnalisés : non installés par MEGA. Il convient de déplacer ces fichiers
vers le dossier <Chemin d'installation HOPEX>\java\lib_usr'.
La liste des fichiers installés par MEGA varie selon la version.
Liste des fichiers .jar (50 fichiers) installés par MEGA 2009 SP5 CP10.0 dans le dossier <Chemin
d'installation>\java\lib.
aspose_cells.jar
aspose_pdf_kit.jar
bcprov-jdk16-146.jar
ChartDirector.jar
FT.jar
GrcAuthenticationPlugin.jar
GrcEvent.jar
GrcRendering.jar
GrcSearchCore.jar
GrcServices.jar
GrcWkflow.jar
GrcWkfPlugin.jar
json.jar
mail.jar
MegaAtlas.jar
MegaConnect.jar
MegaUtilities.jar
mj_anls.jar
mj_api.jar
mj_arprt.jar
mj_audit.jar
mj_bsln.jar
mj_cmdb.jar
mj_e300.jar
mj_gmap.jar
mj_iexls.jar
mj_toolkit.jar
mj_umld.jar
mj_webui.jar
mj_wfeng.jar
mj_xmi.jar
mj_xpdle.jar
serializer.jar
servlet-api.jar
xalan.jar
mj-solman.jar
mj-solmanconnector.jar
page 30/31
commons-io-1.0.jar
mgpx-api-1.0.jar
aspose_pdf_2.8.0_jdk16.jar
woodstox-core-asl-4.1.1.jar
dom4j_1.6.1.jar
jackson-all-1.9.5.jar
jackson-utility-1.4.8.jar
restlet-utilities-1.4.8.jar
gmap-report-1.2.jar
stax2-api-3.0.2.jar
org.restlet.2.0.15.jar
commons_lang_2.4.jar
log4j-1.2.16.jar
page 31/31

How to Migrate to HOPEX V1R1 FR

Transcription

Similar documents

Projet - Ville de Montréal

Programmation complète

Télécharger TOPO n°205

Using Your Blender - Hamilton Beach Commercial

Pueblo Indian Pottery Vol. 1 (text)

model/modèle modelo model/modèle modelo

MGV11870 DMO500 Series IM Update_IM_rev.indd

Le langage Java