How to migrate to HOPEX V1R1 EN
Revised: November 19, 2013
Created: March 31, 2010
Author: Jérôme Horber
CONTENTS
Summary
This document describes the procedures necessary for upgrading MEGA Data to version HOPEX V1R1
from version MEGA 2009 SP5.
For prior version, it is necessary to perform an intermediate upgrade to MEGA 2009 SP5 CP9 or
higher CP.
This document applies to all Front-Ends of HOPEX V1R1:
• HOPEX Web Front-End.
• Windows Front-End.
• Advisor Front-End.
This document also applies to the different storage formats for MEGA Data:
• Oracle.
• SQL Server.
• GBMS.
It does not describe:
• System requirements and possible architectures (see architecture overview documentation).
• How to perform installations (see installation documentation).
• How to install corrective patch (see CP upgrade documentation).
• How to manage installations (see administrator manuals).
• How product are licensed (see licensing documentation).
• How to use features (see user manuals).
• How to upgrade programs (see installation documentation).
See also other documents regarding migration to HOPEX:
• How to prepare to migrate to HOPEX - MEGA 2009 SP5 EN: prepare migration to HOPEX
• Metamodel changes - HOPEX V1R1: description of metamodel changes (for experts).
• Migration: The holistic case: description of modeling best practices.
How to migrate to HOPEX V1R1 EN
page 2/28
Contents ............................................................................................................. 2
Migrate data to HOPEX V1R1 .............................................................................. 4
Check hopex readiness ....................................................................................... 5
Check data .........................................................................................................5
Save behavior specification...................................................................................5
Check metamodel, locks, transactions and workflows...............................................5
Check consistency of storage format ......................................................................5
Upgrade data ...................................................................................................... 6
Upgrading the system database and data repositories ..............................................7
Running conversion tools......................................................................................8
Reviewing RDBMS privileges .................................................................................8
Updating stored procedures ..................................................................................9
Moving custom .Jar files .......................................................................................9
Setting option 'Management of assignment of business roles to persons' ....................9
Setting option 'Definition of path of MetaAssociation' ............................................. 10
Restoring MetaAssociation behaviors ................................................................... 10
Checking upgraded data ................................................................................... 13
First control of migration .................................................................................... 13
Check of data consistency .................................................................................. 13
Other checking indications .................................................................................. 19
Appendix .......................................................................................................... 20
Conversion details ............................................................................................. 20
Utilities details .................................................................................................. 23
Structure of the file MetaAssociation_Behaviors_Before_2013.csv ........................... 24
FAQs ................................................................................................................. 25
How to migrate to HOPEX V1R1 EN
page 3/28
MIGRATE DATA TO HOPEX V1R1
With HOPEX, MEGA has chosen to enforce certain rules to ensure data consistency. As a
consequence:
• Unicity is now required for certain MetaAssociations (description of diagram, owner ship…).
• Orientation of certain MetaAssociation has changed.
For this reason migration goes through several main steps:
1. Prepare migration of data
This work requires version MEGA 2009 SP5 CP9 or higher CP.
This enables to check that data are compliant with the future metamodel and that customization
regarding MetaAssociation behaviors are saved.
Most of this work requires human intelligence and cannot be automated.
2. Upgrade data
This work requires HOPEX V1R1 base version or higher CP.
It enables to upgrade the metamodel and convert data to the format required by HOPEX.
This is done using conversion tools run manually from the Administration
(Administration.exe).
3. Checking upgraded data and customizations
It consists in checking that from the user point of view:
• Modelled data have been correctly migrated.
• Customizations have been correctly migrated.
This work requires human intelligence and cannot be automated.
How to migrate to HOPEX V1R1 EN
page 4/28
Console
CHECK HOPEX READINESS
This work requires version MEGA 2009 SP5 CP9 or higher CP.
It is a pre-requisite for data upgrade to HOPEX V1R1.
Check data
For each data repository, identify and fix faulty data.
For more details, refer to the document 'How to prepare to migrate to HOPEX - MEGA 2009 SP5'.
Save behavior specification
For each environment, save the behavior specification in a system note of the system database. For
more details, refer to the document 'How to prepare to migrate to HOPEX - MEGA 2009 SP5'.
Check metamodel, locks, transactions and workflows
For each environment:
• Check that the metamodel is stable
If the environment compilation generates a log in the MEGA error log, you should fix such
errors before upgrading data.
• Check that no transaction (now called 'private workarea') persists. Otherwise dispatch or
delete them.
For the system database and each data repository:
• Check that no lock exists. Otherwise, delete them.
• Check that all workflows are completed (there is no workflow instance 'running'). Otherwise
complete or delete them.
Check consistency of storage format
With MEGA 2009 SP5, it was technically possible (although not recommended) that not all
repositories have the same storage format. Example: system database is stored in GBMS format and
the data repositories are stored in SQL Server format.
This situation is no longer tolerated: from HOPEX all data repositories and system database must
use the same storage format (GBMS or SQL Server or Oracle). Example: system database and all
data repositories are stored in SQL server format.
How to migrate to HOPEX V1R1 EN
page 5/28
UPGRADE DATA
Before proceeding, make sure that, for all the MEGA environments to upgrade:
• Data is backed up (physical backup).
• The password of the user 'Administrator' is known or set to empty.
This is very important since it will be requested to login with 'Administrator'
For each MEGA environment, several steps are required:
• Upgrade the system database using environment automatic upgrade.
• Run technical conversion on system database and data repositories using RDBMS storage.
• Run conversion tools on the system database.
• Run conversion tools on the data repositories.
The procedure varies with the type of storage.
Important notes:
1) After conversion of the system database to HOPEX,
• A new connection window is displayed.
• The users Administrator and User are not available any longer.
As a consequence, when opening the MEGA environment
• Use the identifier system (no password by default) instead of Administrator
• Use the identifier mega (no password by default)instead of User.
2) With RDBMS storage (Oracle, SQL Server), a conversion called 'Technical Conversion' is required
for each data repository and for the system database.
As long as conversion is not performed for a data repository (ex: Adventure):
• This repository is displayed as not available (red cross icon).
• A warning can be displayed such as 'You cannot access repository XXX. Its internal structure
is not up to date. Run the menu "Technical Conversion" to perform the upgrade. Click 'OK' to
hide this warning.
How to migrate to HOPEX V1R1 EN
page 6/28
Upgrading the system database and data repositories
For RDBMS storage (Oracle and SQL Server)
Procedure in version HOPEX V1R1:
1. Start the Administration Console.
2. Reference the environment to be converted
3. Select the environment:
A warning is displayed: You cannot access repository "SystemDb". Its internal structure is not
up to date. Run the menu "Technical Conversion" to perform the upgrade.'
4. Click 'OK' to hide the warning.
5. Select the environment and R click > Technical Conversions.
A window 'MEGA RDBMS Technical Conversion' is displayed.
6. Click 'OK' to confirm conversion of the systemdb repository.
Wait until the conversion is over (from 30 min to several hours according to size of systemdb
and machine).
A line 'Technical conversion completed' is displayed'.
7. Click 'Close'.
8. Select and open the environment to be upgraded with the user Administrator
A warning is displayed: Your environment and site are not of the same version. Your
environment requires updating. Refer to documentation for how to carry out this action.
9. Click 'OK'
A Message is displayed: Your environment requires an update for compatibility with your
version of MEGA. Do you wish to run this procedure now?
10. Click 'Yes'
A window 'Automatic Update' is displayed.
11. Read the text, check the option 'I have taken note of the above text' and click 'OK'.
The processing 'environment automatic upgrade' is executed
Wait until the conversion is over (around 30 min)
A message is displayed 'Your environment has been successfully updated
12. Click 'OK'
13. For each data repository:
a. Select the data repository (ex: Adventure)
b. R click > Technical Conversions
A window 'MEGA RDBMS Technical Conversion' is displayed
c. Click 'OK' to confirm conversion of the data repository.
Wait until the conversion is over (up to 30 min). A line 'Technical conversion
completed' is displayed'
d. Click 'Close'.
e. Close the environment.
14. Exit the Administration Console.
How to migrate to HOPEX V1R1 EN
page 7/28
For GBMS Storage
Procedure:
1. Start the Administration Console.
2. Select and open the environment to be upgraded with the user Administrator.
3. A question is displayed 'Your environment requires an update for compatibility with your
version of MEGA. Do you wish to run this procedure now?
4. Read the information, check the option 'I have taken note of the above text' then click 'OK'.
5. The processing 'environment automatic upgrade' is executed.
6. Wait until the update is complete.
7. A message is displayed like 'Your environment has been successfully updated'.
8. Click 'OK'.
9. Close the environment.
10. Exit the Administration Console.
Running conversion tools
Before proceeding, consult the table 'Conversion details' in this document to understand if
conversions are relevant in you context.
Procedure:
1.
2.
3.
4.
Start the Administration Console.
Select and open the environment to be converted with the identifier Administrator.
In the folder 'Repositories', select 'Systemdb'
R click > Conversions > Convert data into current version > From MEGA 2009 data
A list of conversions is displayed
5. Check the appropriate conversions.
See the table 'Conversion details', later in this document
6. Click 'OK' to trigger the conversion
Wait until the conversion is complete.
7. Close the environment
8. Select and open the environment with the identifier system (no password by default).
9. In the folder 'Repositories', for each repository
10. Select the repository
11. R click > Conversion > Convert data into current version > From MEGA 2009 data
12. Check the appropriate conversions.
See the table 'Conversion details', later in this document
13. Click 'OK' to trigger the conversion
14. Exit the MEGA Administration Console.
Reviewing RDBMS privileges
Privileges are required to manage stored procedures.
As a consequence, each Oracle user requires an additional privilege for the database instance:
GRANT CREATE PROCEDURE TO <MEGAUSR>;
For SQL Server, no additional privilege is required since the role 'db_owner' already enables to
manage stored procedures.
How to migrate to HOPEX V1R1 EN
page 8/28
Updating stored procedures
This step is mandatory for each repository or system database using RDBMS storage (Oracle, SQL
Server). Access to Oracle/SQL server administration tools and the permission to delete and create
stored procedure is required.
• Existing stored procedures (created in a previous version) need to be deleted.
This is done from on the Oracle/SQL server administration tool.
• Stored procedures need to be created in the current version.
This is done from MEGA Administration Console.
General procedure:
The exact procedure depends on the Oracle/SQL server administration tool.
In Oracle administration tool:
For each schema (data repository or system database):
• Delete stored procedure 'SP_CLEAN_MEGA_DATABASE'.
• Delete stored procedure 'SP_CONSOLIDATE_MEGA_DATABASE'.
In SQL Server administration tool
For each database (data repository or system database):
• Delete stored procedure 'xxx.SP_CLEAN_MEGA_DATABASE'.
• Delete stored procedure 'xxx.SP_CONSOLIDATE_MEGA_DATABASE'
In HOPEX installation:
• Start the Administration Console
• Select and open the environment with the identifier system (no password by default).
• In the folder 'Repositories', for each repository
• R click > RDBMS Administration > Deletion of transaction temporary data.
• Click 'Clean up'.
Wait until the message 'Operation completed successfully' is displayed (a few minutes).
• Click 'OK'.
• R click > RDBMS Administration > Deletion of historical data from repository.
• Click 'Consolidate'.
Wait until the message 'Operation completed successfully' is displayed (a few minutes).
• Click 'OK'.
• Close the environment.
• Exit the Administration Console
Note that it is important that the execution of all these stored procedure is schedules (batch). Refer
to the document Repository - RDBMS Installation Guide HOPEX V1R1 to get the complete list.
Moving custom .Jar files
This step is mandatory customized .Jar file have been created.
Customized .jar files need to be moved from the folder '<HOPEX installation path>\java\lib' to a new
folder '<HOPEX installation path>\java\lib_usr'.
If you do not know if you have customized .Jar files check the list of standard .jar files later in this
document. It is likely that the .jar files that are not listed are customized.
Setting option 'Management of assignment of business roles to
persons'
This step requires a decision for each MEGA environment.
How to migrate to HOPEX V1R1 EN
page 9/28
In the MEGA options, group 'Installation > User Management', an option ' Management of
assignment of business roles to persons' is available at installation and environment level. This
option enables to control the selection of profiles according to the value chosen:
• Unchecked: profiles are assigned through logins.
• Checked: profiles are assigned through business roles.
Value
Unchecked
Recommended
Recommended for compatibility with version MEGA 2009 and
lower
Recommended for new projects and for HOPEX solutions
Checked
Note that the option is checked by default from HOPEX V1R1. You can change the value at any time
without impact on data. However, this has an impact on login windows and on user management.
Setting option 'Definition of path of MetaAssociation'
This step requires a decision for each MEGA environment.
In the MEGA options, group 'Repository', an option 'Definition of path of MetaAssociation' is available
at installation and environment level. This option enables to control the way MetaAssociation
behaviors are interpreted according to the value chosen:
• Compatibility up to MEGA 2009: MetaAssociation behaviors are interpreted using the logic of
MEGA 2009.
• From MEGA HOPEX 1.0: MetaAssociation behaviors are interpreted using a new logic.
Value
Compatibility up to MEGA 2009
From MEGA HOPEX 1.0
Recommended
Required for compatibility with version MEGA 2009 and lower
(data and system database customization)
Recommended for new projects and for repository alignment
(stricter control on objects). If behavior has been customized
(system database customization) in version MEGA 2009,
compatibility is not guaranteed. A review that may require time
and expertise is necessary.
Note that 'From MEGA HOPEX 1.0' is the default value from HOPEX V1R1. You can change the value
and compile the environment without impact on data except namespace. However, the change will
affect the behavior (namespace, navigation, extraction, protection, export, comparison…).
Restoring MetaAssociation behaviors
This step requires a decision for each MEGA environment where the option 'Definition path of
MetaAssociation' is set to 'Compatibility up to MEGA 2009'.
Part of the change of metamodel between MEGA 2009 and HOPEX is change of orientation of
MetaAssociation (permutation). This will affect behaviors of the MetaAssociation involved. You can
decide to restore the behavior saved previously in MEGA 2009 SP5 for this environment. If the
option is set to 'From MEGA HOPEX 1.0', this restore is irrelevant.
Choice
Restore
Do not restore
Recommended
If significant issues caused by change of orientation of MetaAssociation are
identified during tests.
To keep standard definition of behavior as much as possible
If you use repository alignment
How to migrate to HOPEX V1R1 EN
page 10/28
The following procedure applies to an environment where behaviors have been saved to a file
MetaAssociation_Behaviors_Before_2013.csv in version MEGA 2009 SP5.
Procedure:
1. Start the Windows front-End (Mega.exe).
2. Open a private workarea (ex-transaction) with a user allowed to update MEGA data.
3. Run the script editor using the menu Tools > Script Editor
4. Open the macro 'MetaAssociation Behaviors - Restore'.
5. Run the macro.
6. Exit and dispatch the workarea.
The execution of this macro restores the behaviors exactly as they were in previous version. For
instance if a behavior was [Deep, Abort] it is restored as [Abort, Deep] to take in account the fact
that the major and the minor MetaAssociationEnds have been switched.
This restoration affects only the specification of behavior used with the compatibility mode
(Compatibility up to MEGA 2009). It does not affect the specification of behavior used with new new
mode (From MEGA HOPEX 1.0).
It also generates a report MetaAssociation_Behaviors_Since_2013.csv. This file is archived in the
root folder of the MEGA environment.
How to migrate to HOPEX V1R1 EN
page 11/28
It is a table where each row is a combination of Operator x MetaAssociation.
For each row, several properties are described as columns:
Columns
Operator
MetaAssociation
NewMajorClass
NewMajorEnd
NewMinorClass
NewMinorEnd
NewMinMajBehavior
NewMajMinBehavior
Switched
OldMinMajBehavior
OldMajMinBehavior
SetMinMajBehavior
SetMajMinBehavior
Comment
ID and name of Operator
ID and name of MetaAssociation
ID of the Major MetaClass after permutation
ID of the Major MetaAssociationEnd after permutation
ID of the Minor MetaClass after permutation
ID of the Minor MetaAssociationEnd after permutation
Behavior (Abort, Link, Deep) when the MetaAssociation is used after
permutation and before restoration
Behavior (Abort, Link, Deep) when the MetaAssociation is used after
permutation and before restoration (from the Major MetaClass through the
Minor MetaAssociationEnd)
Boolean. The MetaAssociationEnds have been permuted (Major/Minor) during
the upgrading process
Behavior of the MetaAssociation viewed from the Minor MetaClass through
the Major MetaAssociationEnd (Major and Minor being defined as before
permutation).
Behavior of the MetaAssociation viewed from the Major MetaClass through
the Minor MetaAssociationEnd (Major and Minor being defined as before
permutation).
Behavior of the MetaAssociation viewed from the Minor MetaClass through
the Major MetaAssociationEnd after restoration (Major and Minor being
defined as after permutation).
Behavior of the MetaAssociation viewed from the Major MetaClass through
the Minor MetaAssociationEnd after restoration (Major and Minor being
defined as after permutation).
All IDs are in the form: hexaidabs[Name]
Behaviors are explicitly given from the list: {Abort; Link; Deep; Standard; Computed; Null}
How to migrate to HOPEX V1R1 EN
page 12/28
CHECKING UPGRADED DATA
It is highly recommended to back up the each environment once it has been upgraded.
The standard installation and upgrading process takes care of all the conversions that can be
automated. Technically speaking, conversion success is guaranteed by:
• The correct execution of the environment automatic upgrade processing.
If errors are met at this step, the migration process must be stopped so that a diagnosis is
made. Check carefully the Mega error log.
• The correct execution of all mandatory conversions for the system database.
If errors are met at this step, the migration process must be stopped so that a diagnosis is
made.
• The correct execution of all mandatory conversions for the each user repository.
If errors are met at this step, the migration process must be stopped so that a diagnosis is
made.
After complete execution of the migration process, it is highly recommended to check data and
customizations through:
• First control of migration: run a quick tour to check that data look correct.
• Check of data consistency: run utilities to enforce rules regarding data structure.
• Other checking indications.
First control of migration
It is highly recommended to run a quick tour and check that upgraded data look correct. Of course,
this kind of check cannot be exhaustive but it usually enables to have a first feedback and quickly
identify certain migration issues.
Example of scenario:
• Open a private workarea (ex-transaction)
• Browse through objects using query tools, navigation trees and diagrams.
• Perform not significant updates (ex: change a character in a comment value, slightly move
an object in a diagram...)
• Dispatch private workarea.
Check of data consistency
Many things were tolerated, although not recommended, in previous versions. In order to ensure
better consistency, control is now more rigorous and many of the previous recommendations
become constraints. Hence, there is a need for a thorough review of the repository content and,
potentially, some house cleaning and tidying tasks to perform.
Different utilities are provided to check data consistency:
o Objects with no owner.
o Objects with has multiples owners.
o Broken connectors.
o Objects not displayed in any diagram.
o Main objects with no user.
In the options, group 'Repository', check that the parameter 'Metamodel Access' is set to
'Expert'.
The utilities can be run as often as necessary until problems are fixed. When a utility is run again, it
updates its list of faulty objects, removing those that have been fixed. You should fix the faulty
objects until the list is empty.
How to migrate to HOPEX V1R1 EN
page 13/28
Objects with no owner or multiple owners
Each object must have one and only one owner. Objects that have no owners cannot be reached by
the standard tools and therefore cannot be exported.
Utilities are provided to check the ownership of each object.
• Run the menu Tools > Cleaning > Query Objects with No Owner.
• Run the menu Tools > Cleaning > Query Objects with Multiple Owners.
Faulty objects are automatically put in folders of Shared Favorites for further investigation. Those
folders are 'Objects with No Owner' and 'Objects with Multiple Owners' and are subfolders of
'_Objects to be Cleaned'.
For multiple owners, the preprocessing before migration should have dealt with most of the cases.
The only remaining cases would occur when an object can be owned by different object types.
If an object is owned by several others with different lifecycles, there is a risk that its transfer with
one of its owners damages the others that could not yet be validated or applicable and thus that will
become inconsistent in the production repository.
The most frequent situation of multiple owners is when an object is at the same time the 'sub' or
'component' of another one and member of a library. If there is a doubt about the right one, it is
preferable to choose the library.
It is likely that there will be hundreds of them, even more. Many of them are not used anymore and
can be deleted without problem. For most of the others, the owner will be easy to retrieve through
the diagrams in which they appear.
Generally, main objects with no owner should be placed in a library. If a main object is at the same
time a 'sub' of another and a member of a library, the library should be privileged except if this
object is only used in the context of its parent. A 'sub' object should not be re-usable.
How to migrate to HOPEX V1R1 EN
page 14/28
Broken connectors
The most important population of objects in the repository is constituted of connectors (Message,
Sequence, Connector, Exchange, Interaction…). They are used to connect two objects in the context
of a third. Their descriptions are often completed with a fourth object (ex: the Content for a
Message, the Protocol for an Interaction…). As component objects, connectors are meaningless
outside their context. They are also meaningless without their connected objects. A broken
connector introduces undue dependency which can hinder starting the validation workflow of its
owner.
The following schema represents two basic patterns for Connectors.
A utility is provided to find connectors that do not fulfill this requirement.
• Run the menu Tools > Cleaning > Query Broken Connectors.
Faulty object are automatically put in the Folder of Shared Favorites 'Broken Connectors' for
further investigation. This folder is a subfolder of '_Objects to be Cleaned'.
How to migrate to HOPEX V1R1 EN
page 15/28
Generally, broken connectors can be deleted without problem.
Objects not displayed in any diagram
Diagrams are the graphical representations of models. When an object is part of another one (in its
model) it is generally displayed in at least one of its diagram. Things that could have been shown
but that happened 'behind the scene' should be rare. This may be wanted and assumed but in most
cases it happens 'by chance'. The typical situation is when a user removes an object from a diagram
instead of deleting it or asking for its deletion. Things that happen behind the scene so that nobody
knows lead to abnormal disruptions between models and diagrams, for instance when a message is
simply removed from a diagram, it still connects the sender and the receiver.
A utility is provided to check the objects not in diagrams.
• Run the menu Tools > Cleaning > Query Objects Not in Diagrams.
Faulty objects are automatically put in a Folder of Shared Favorites 'Objects Not in Diagrams' for
further investigation. This folder is a subfolder of '_Objects to be Cleaned'.
How to migrate to HOPEX V1R1 EN
page 16/28
Many faulty objects cannot be library elements
and their checking vis-à-vis presence in
diagram can be time consuming.
Depending on the modeling strategy chosen
some of them may be intentionally left apart
from diagrams so that it is not necessary to
check them.
A folder 'MetaClasses to Scan' contains the
list of metaclasses that are processed by the
utility. If a type of objects is deliberately never
in diagram the corresponding MetaClass can be
disconnected from this list.
Main objects with no user
Main objects are those that can be validated and/or transferred (ex: members of the classes
'Validation Candidate Object' or 'Transfer Candidate Object'). They constitute the skeleton of the
repository. Their relationships form the architecture and give it a sense. A main object that does not
contribute to the architecture is of little interest and encumbers the repository.
A utility is provided to find main objects that are not used anywhere.
• Run the menu Tools > Cleaning > Query Main objects with No Users
Faulty objects are automatically put in the Folder of Shared Favorites 'Main Objects with No User'
for further investigation. This folder is a subfolder of '_Objects to be Cleaned'
How to migrate to HOPEX V1R1 EN
page 17/28
The exercise consists in discriminating new objects not yet used, for instance because a design task
is not completed, from old objects not used anymore. The creation date is a good criterion for that.
Depending on the modeling strategy
chosen there could be objects that are
intentionally left apart from other objects
so that it is not necessary to check them.
A folder 'MetaClasses to Scan' contains
the list of metaclasses that are processed
by the utility. If a type of objects is
deliberately never used elsewhere the
corresponding
MetaClass
can
be
disconnected from this list.
How to migrate to HOPEX V1R1 EN
page 18/28
Other checking indications
If extensions were made to the metamodel, they must be reviewed with regard to the structuring
rules described above. A particular attention must be paid to the orientation of MetaAssociations as
it governs the behaviors of the related objects.
If customizations have been made (property pages layer, diagram configuration layer, templates,
programs based on script APIs…), a specific check is required based on initial customization
specifications. As customizations are often based upon standard layers, they may not be ready to
use and they may have a different look and feel. This check requires functional and platform
development skills.
Topic
User
Profiles
Workflows
Advisor
API script
Comment
The implementation has changed.
A tool converting users to the new format is provided.
It is mandatory to review the user configuration (connection parameters,
administrator privilege).
Note that with HOPEX, it is recommended to set options and command line at
profile level.
The features 'Metamodel access management' and 'Metamodel filter' are replaced
with a management of permission.
A tool converting profiles to the new format is provided.
It is mandatory to review the profile configuration. This review should be based
on initial functional specifications.
Configuration and implementation has evolved.
A tool converting definition of workflows to the new format is provided. It also
converts data related to workflow.
It is recommended to review the workflow configuration especially if workflows
have been customized. This review should be based on based on initial functional
specifications.
The implementation of the authentication and mapping has changed. The
information is now saved in the system database of each environment. The utility
webusermapping.exe and MappingDatabase.xml are not provided any longer.
A tool converting mapping data and authentication data to the new format is
provided.
It is mandatory to review the user configuration (connection parameters,
administrator privilege).
The metamodel has changed. Refer to the document 'Metamodel changes HOPEX V1R1'.
No tool can be provided for specific code. No specific indication is provided.
It is recommended to review the customized macros and applications using API
script in particular for Administration APIs. This review should be based on based
on initial functional specifications.
Scope of migration regarding workflows:
Category
Definition of workflow
Data
related
to
workflow
Element
Workflow instances
Request for change objects
Design task objects
Notification
Migrated
Yes
Yes (1)
Yes
Yes
Yes
(1) Except validation workflow instances.
Conversion of data related to workflow is guaranteed for standard workflow metamodel and
workflow definition (Design Task, Request for Change, Validation).
How to migrate to HOPEX V1R1 EN
page 19/28
APPENDIX
Conversion details
If mandatory conversions are not made on repositories, malfunction or loss of data can occur.
Repositories need to be converted only once.
Select a repository, right-click 'Conversions > Convert data into current version' then select the
source version 'From MEGA 2009 data' to display conversions.
Conversions
MEGA
reposit
ory
MEGA Advisor - Conversion of mapping
This conversion converts the user mapping (stored in the file
MappingDatabase.xml) to the new format (stored in the system
database). It assumes that the current machine hosts a MEGA
Advisor installation, that a file MappingDatabase.xml is available,
that all of the environments referenced in the.xml file are available.
This conversion is mandatory for the system database if your data
comes from MEGA 2009.
Do not run the conversion if you are in one of the following
situations:
- You do not use MEGA Advisor.
- You use MEGA Advisor but it is installed on another machine (in
this case, run it from that machine).
- You use MEGA Advisor on this machine with the default mapping
(no MappingDatabase.xml file).
This conversion is implemented by a MEGA macro 'MEGA Advisor Conversion of mapping.Method' calling an external script
'convert_mapping.vbs'.
MEGA APM - Conversion of Application Assessment
This conversion transforms the evaluation of the application into an
assessment session of the application. Evaluation of the application
is enabled by MEGA Application Portfolio Management (APM).
This conversion is mandatory for the data repositories if you have
used APM.
This conversion is implemented by a macro 'MEGA APM
Conversion of Assessment of application'.
MEGA APM - Conversion of Application Ownership
From HOPEX, the specification of responsibility changes for
application. Specification of responsibility for application is enabled
by MEGA Application Portfolio Management (APM). This conversion
creates the assignment as application owner to the user linked to
each application.
This conversion is mandatory for the data repositories if you have
used APM.
This conversion is implemented by a macro 'MEGA APM Conversion of Application Ownership'.
MEGA IT Planning - Master Plans : Conversion of Type
Attribute to Link to Plannable Metaclasses
The type attribute for Master Plans (Strategic, Solution, Application
etc.) is deprecated. The conversion replaces it with a link to the
plannable metaclasses corresponding to each of these types.
No
How to migrate to HOPEX V1R1 EN
page 20/28
Syste
m
Datab
ase
Mandatory
if
upgrade
from
2009
Yes
Yes if Advisor
was used
KB 00004109
Yes
No
No
KB 00004194
Yes
No
No
KB 00004194
Yes
No
Yes
KB 00003612
Conversions
MEGA
reposit
ory
Syste
m
Datab
ase
Mandatory
if
upgrade
from
2009
Yes
Yes
Yes
KB 00002500
Yes
Yes
Yes
KB 00001289
No
Yes
No
KB 00004238
No
Yes
Yes
KB 00004012
Yes
No
Yes
KB 00004009
No
Yes
Yes
KB 00004011
No
Yes
Yes
KB 00004010
Yes
No
Yes
This conversion is mandatory for each repository if your data come
from MEGA 2009 version
This conversion is implemented by a macro 'Conversion of Type Attribute to
Link'.
MEGA Repository - Conversion of link instances to Generic
MetaAssociation
This utility updates the metamodel to enable a generic management
of certain MetaAssociations (to Note, Document...).
Conversion of aliased links may take several minutes depending on
the volume of data and requires a metamodel compilation.
This conversion is mandatory for the System and data repositories if
your data come from MEGA 2009 and earlier versions
MEGA Repository - Conversion of name properties
Aligns object names with metamodel definition
Conversion may take a significant time depending on the volume of
data.
This conversion is mandatory for the data and System repositories if
your data come from MEGA 2009 and earlier versions. It needs to be
run at each major version or release upgrade.
'MEGA Repository - Conversion of old MetaAssociation into
deprecated MetaAssociation'
From HOPEX, several MetaAssociations are set as deprecated.
This conversion tags these MetaAssociations as deprecated.
This
conversion
is
implemented
by
an
external
script
(convert_deprecated_metaassociation.vbs)
MEGA Repository - Conversion of report template simple type
parameters
This conversion converts certain report templates (reports templates
with simple type parameters: boolean, string...) to the new format.
This conversion is mandatory for the system database if your data
come from MEGA 2009 version.
This
conversion
is
implemented
by
a
script
convert_reporttemplate_simpletypeparams.vbs
MEGA Repository - Conversion of reports simple type
parameters
This conversion converts certain reports (reports with simple type
parameters: boolean, string...) to the new format.
This conversion is mandatory for each repository if your data come
from MEGA 2009 version
script
This
conversion
is
implemented
by
an
external
(convert_report_simpletypeparams.vbs)
MEGA Repository - Conversion of UI Permissions
This conversion converts the previous configuration (at environment
and profile level) to the new format.
This conversion is mandatory for the system database if your data
come from MEGA 2009 version.
This conversion is coded in C++ and cannot be customized.
MEGA Repository - Conversion of User into Person (System)
with Login and Profile
This conversion converts users to the new format (Person (System),
Login and Profile). User password values are encrypted.
This conversion is mandatory for the system database if your data
come from MEGA 2009 version
This
conversion
is
implemented
by
an
external
script
(convert_megaperson_to_megalogin.vbs).
MEGA Repository - Update initial foundation : 'MEGA Library'
How to migrate to HOPEX V1R1 EN
page 21/28
Conversions
MEGA
reposit
ory
This utility imports 'megalibrary.xmg' which is required for MEGA to
work properly.
This conversion is mandatory for the data repositories if your data
come from MEGA 2009 and earlier versions.
MEGA Requirement Tracker - Conversion of requirements
Converts the specification of requirements to a new format to enable
a new type of synchronization.
This conversion is mandatory for the data repositories if your data
come from MEGA 2009 version.
This conversion is implemented by a macro 'Conversion of
requirements'
MEGA TeamWork - Conversion of Metamodel (Design Task,
Request For Change, Workflow Instance, Notation, ...)
This conversion changes the location of objects from system
database to repository for different MetaClasses (Design Task,
Request For Change, Workflow Instance, Notation, Workflow Status
Instance, Workflow Transition Instance).
This conversion may take several minutes. This process will convert
the metamodel to a 'not compiled' state: it will be necessary to
recompile it.
This conversion is mandatory for each repository if your data come
from MEGA 2009 version
Conversion
is
implemented
by
an
external
script
(convert_teamworkmetamodel.vbs).
MEGA TeamWork - Conversion of Metamodel Data
From HOPEX, the workflow status of the workflow subject is
computed differently when the workflow has parallel transitions.
This conversion converts workflow parallel status to the new format.
This conversion is mandatory for the data repositories if you have
used workflows (MEGA Teamwork).
This conversion is implemented by a MEGA macro (MEGA TeamWork
- Conversion of Workflow Parallel Status.Method)
MEGA TeamWork - Conversion of Metamodel (System)
Converts the workflow definition to the new format.
This conversion is mandatory for the system database if you have
used workflows (MEGA Teamwork).
This conversion is implemented by a MEGA macro (MEGA TeamWork
- Conversion of Workflow Definition Main Workflow Attribute.Method)
How to migrate to HOPEX V1R1 EN
page 22/28
Syste
m
Datab
ase
Mandatory
if
upgrade
from
2009
Yes
No
Yes
KB 00003613
Yes
No
Yes
KB 00004008
Yes
No
No
KB 00004237
No
Yes
Yes
KB 00004347
KB 00003025
Utilities details
Utility
MEGA
reposit
ory
Diagram (drawings)
Yes
This utility opens, saves and closes all diagrams in the repository.
Enables conversion of diagrams with drawings in MGE format. Also
enables to check the status all diagrams in a repository.
This execution is optional for the system database and data
repositories.
Conversion may take a significant time depending on the volume of
data.
This utility is coded in C++ and cannot be customized.
MEGA Publisher - Remove invalid MEGA templates
No
This utility removes MEGA templates or components left invalid after
upgrade. To avoid useless conversion errors, it must be run before
the conversion 'MEGA Publisher - Replacement of tag 'name' with
'shortname' in HTML/RTF descriptors'.
This utility is implemented by a macro ' MEGA Publisher - Remove
invalid MEGA templates (2009 and earlier versions)'
MEGA Repository - Automatic Assignment Generator
No
This utility generates an assignment for each object Person
(System) connected to a profile via a login.
This
utility
is
implemented
by
an
external
script
('automatic_assignment_generator.vbs')
MEGA Repository - Cleanup
Yes
This utility removes technical temporary data left invalid in
repositories after upgrade (ex: recent queries).
This utility is implemented by a macro 'MEGA Repository Cleanup.Method'
MEGA Repository - Conversion of name properties (long Yes
name)
This utility aligns object names with metamodel definition (long
name) for certain MetaClasses: Control, Requirement, Risk, Risk
Factor, Timer. Conversion may take several minutes depending on
the volume of data.
This conversion is coded in C++ and cannot be customized.
MEGA Repository - Conversion of Organisational Charts
Yes
This utility converts the nature of Organizational Chart diagrams so th
with MEGA Process BPMN Edition. It avoids creating new Organizationa
MEGA Process BPMN Edition.
This conversion is implemented by a macro 'Organisational Chart
Conversion'
MEGA Repository - Conversion of Person into Person Yes
(System)
This utility creates a new object person (system) for each object
person and creates a traceability link between the two objects.
is
implemented
by
an
external
script
This
utility
('Convert_Person_to_MegaPerson.vbs').
MEGA Repository - Convert Advisor Web Site Templates No
Pages
This utility enables to change the display of Advisor page and get
the look of MEGA 2009 SP4 and lower. Do not run this utility if you
do not use MEGA Advisor or if you are satisfied with the look of
pages.
How to migrate to HOPEX V1R1 EN
page 23/28
Syste
m
Datab
ase
Mandatory
if
upgrade from
2009
Yes
Optional
KB 00001270
Yes
Optional
KB 00003139
Yes
Optional
KB 00004006
No
Optional
KB 00003321
No
Optional
KB 00001892
No
Optional
KB 00003984
No
Optional
KB 00004007
Yes
Optional
KB 00003498
Utility
This
utility
is
implemented
by
a
macro
'
WebSiteTemplatePages.Migrate'
MEGA Repository - Convert Report templates (MS Word) to
RTF Format
This utility converts Report templates (MS Word) from Word to RTF
format.
This is required to generate documents with MEGA Web Front-end.
If you do not use MEGA Web Front-end or do not generate
documents, it is recommended NOT to run this utility.
This conversion is coded in C++ and cannot be customized.
MEGA Repository - Creation of links instances from MEGA
fields
This utility creates impact analysis links for objects referenced by
object references (MEGA fields) in texts properties.
Conversion may take a significant time depending on the volume of
data.
This conversion is coded in C++ and cannot be customized.
Shapes
This utility updates customized shapes to the most recent format.
Shapes located in the folder 'Mega_usr' or both installation and
MEGA Environment are upgraded. This conversion is optional for the
System repositories.
Conversion may take several minutes depending on the volume of
data.
This utility is coded in C++ and cannot be customized.
MEGA
reposit
ory
Syste
m
Datab
ase
Mandatory
if
upgrade from
2009
No
Yes
Optional
KB 00003499
Yes
Yes
Optional
KB 00002005
No
Yes
Optional
KB 00000362
Structure of the file MetaAssociation_Behaviors_Before_2013.csv
The report is a table where each row is a combination of Operator x MetaAssociation.
For each row, several properties are described as columns:
Columns
Operator
MetaAssociation
MajorEnd
MinorEnd
bRestricted
MinorToMajor
MajorToMinors
Comment
ID and name of Operator
ID and name of MetaAssociation
ID of major MetaAssociationEnd in MEGA 2009 before permutation
ID of minor MetaAssociationEnd in MEGA 2009 before permutation
1 if a Generic MetaAssociation overloads the behavior
0 otherwise (the behavior is set at MetaAssociation level)
Behavior (1) of the MetaAssociation viewed from the Minor MetaClass
through the Major MetaAssociationEnd in MEGA 2009 before permutation
Behavior (1) of the MetaAssociation viewed from the Major MetaClass
through the Minor MetaAssociationEnd in MEGA 2009 before permutation
All IDs are in the form: hexaidabs[Name]
Behaviors are explicitly given from the list: {Abort; Link; Deep; Standard; Computed; Null}
How to migrate to HOPEX V1R1 EN
page 24/28
FAQS
During conversion the 'Identification' windows has changed!
After conversion of the system database to HOPEX:
• A new connection window is displayed.
• The users Administrator and User are not available any longer
When opening the MEGA environment, use the identifier system (no password by default).
A user mega (no password by default) is also available.
Warning 'You cannot access repository "XXX". Its internal structure is not
up to date. Run the menu "Technical Conversion" to perform the upgrade'
With specific version upgrades, the technical format of the repository can change. As explained, you
need to run a menu technical conversion from the Administration Console. See the section '
'Upgrading the system database and data repositories' sooner in this document.
Warning 'The version of the stored procedure XX is not OK…'
With specific version upgrades, the technical format of the repository can change and stored
procedures need to be reinitialized. See the section 'Updating stored procedures' sooner in this
document.
How to migrate to HOPEX V1R1 EN
page 25/28
How to check that all workflows are completed?
You can run the following queries in MEGA 2009 SP5 for each repository:
Query
All
running
workflows
(workflows NOT completed)
All validation workflows (based
upon
standard
workflow
'Validation)
Query code
Select [Workflow Instance] Where [State]="R"
Select
[Workflow
Instance]
Definition]._Idabs ="9rvu(EEfAf30"
Where
[Workflow
Of course, result may be empty.
Note that all workflow instances are migrated except validation workflows.
Warning 'Writing access diagram is not compiled…'
Certain actions can leave the writing access diagram (ex-User diagram/Authorization diagram) is in a
state not compiled.
To compile the metamodel of the environment:
1. Start the Administration Console.
2. Select and open the environment to be converted with the identifier System.
3. Select the folder 'User management'
4. R click > Compile writing access diagram
5. Click Start to trigger the compilation
Wait until the processing is complete.
6. Click 'Close'
7. Exit the Administration Console
Error logs in file megaerrYYYYMMDD.txt. after running 'Automatic Update'
Some errors can be logged after the Environment Automatic Update. Compile the metamodel of the
environment again and check if errors are logged in the file megaerrYYYYMMDD.txt.
• If errors are logged: investigate the cause of the errors.
• If no errors are logged: resume the migration processing.
To compile the metamodel of the environment:
8. Start the Administration Console.
9. Select and open the environment to be converted with the identifier System.
10. Select the environment
11. R click > Metamodel > Translated and Compile
12. Click Start to trigger the compilation
Wait until the processing is complete.
13. Click 'Close'
14. Exit the Administration Console
How to migrate to HOPEX V1R1 EN
page 26/28
Example of error log:
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
List of .Jar files installed by MEGA 2009 SP5
The folder <Installation path>\java\lib can contain:
• Standard .jar files: installed by MEGA.
• Customized .ar files: not installed by MEGA. These files should be moved to the folder
<HOPEX installation path>\java\lib_usr'
The list of files installed by MEGA varies with the version.
List of .jar files (50 files) installed by MEGA 2009 SP5 CP10.0 in the folder <Installation
path>\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
commons-io-1.0.jar
mgpx-api-1.0.jar
aspose_pdf_2.8.0_jdk16.jar
How to migrate to HOPEX V1R1 EN
page 27/28
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
How to migrate to HOPEX V1R1 EN
page 28/28