Warning Regarding Metamodel Modification
You can modify the structure (or metamodel) of environment repositories, for example when you want to add a MetaAssociation between two MetaClasses.
Note that these modifications should be carried out with caution because they will have to be maintained by the administrator. The metamodel is saved in the system repository of the environment: all repositories of an environment have the same metamodel.
Do not create extensions to the metamodel without careful consideration. If you create metamodel extensions, name your extensions (MetaClass, MetaAssociation, MetaAttribute or text) with a specific prefix that identifies your company, so as to avoid any conflict with a new HOPEX concept when updating your HOPEX version.
Data exchanges between repositories with different metamodels can result in rejects.|
Metamodel extensions are managed differently from modifications to the standard metamodel.
Creating metamodel extensions
After you create new MetaClasses, MetaAssociations or MetaAttributes, back up these metamodel extensions with their absolute identifiers (export as MGR file). You will need them when creating a new environment.
Upgrading a site or environment does not impact extensions you have added to the metamodel.
Managing modifications perfomed on HOPEX standard metamodel
In case you had to modify HOPEX metamodel (or technical data), you must keep your update logfile (MGL file) so as to import your updates after each HOPEX migration (HF/CP or major version).
As HOPEX data is MEGA proprietary data, when upgrading a site or an environment to a new version, the standard installed concepts will be automatically reassigned the standard values.
You must save the MGR type files that you extracted after having made modifications, in order to reapply these after upgrading your environment.
You should apply your modifications to the environment (and only those changes, not an extraction of the complete metamodel) in order to have both the upgraded standard version and your own modifications.
|
Metamodel extensions backup
A simple way of backing up your metamodel extensions is to work in a private workspace using the metamodel diagram.
You can then make an initial verification in this private workspace before dispatching. Usually, you must translate and compile the metamodel so that your extensions will be correctly taken into account.
Once satisfied with operation of your extensions, you can export the logfile of your private workspace before you dispatch it. In this way you will obtain a command file that you can then reimport into another environment when using your extensions or at a change of version.
Transferring metamodel extensions
The absolute identifiers of metamodel concepts are indispensable if HOPEX is to run properly. Metamodel extensions (creation of MetaClass, MetaAssociation, MetaAttribute) should be processed as follows:
• Carry out workspace logfile export if you have been working in a private workspace, or a metamodel extensions logical backup in other cases.
• Save the generated file, which you will use to transfer the extensions into other environments.
Compiling the environment
After you create or import extensions into an environment, it must be compiled. This is done in HOPEX Administration, by requesting translation of the metamodel in the current language.
Restrictions
• Before exchanging data (e.g.: Export, Import) between repositories that are not in the same environment, make sure that these repositories have the same metamodel.
Repositories within the same environment share the same metamodel. • Extensions to the metamodel (new MetaAssociations and MetaClasses) cannot be graphically handled in standard diagrams. Diagram configuration needs to be customized to take into account such extensions (contact HOPEX Professional Services for diagram customization).
Implementation conditions
So that modifications to the metamodel are visible to users:
• the metamodel must be compiled
• a new workspace must be opened. If the user has a private workspace open, it must be dispatched or updated so that the user has access to metamodel modifications.