Showing results for 
Show  only  | Search instead for 
Did you mean: 

Configuration management in Mega 2009

New Contributor

Configuration management in Mega 2009


My question is related to configuration management in mega ? Configuration management is the traking of the object version .

A common scenario is multiple person woking on the same object or diagram, because they work on two different projects ?

Another scenario is the two architect one working on the existant version and other works on the to be state of the object, th object may be a simple application, a diagram, a POS 


How to deal with these uses cases  in a Mega with rdbms database ?


Tags (2)
2 Replies
New Contributor

Re: Configuration management in Mega 2009

I would bring a clarification about my question with this simple use case :

I have to work on the recast of the architecture of a system of applications (group of application), I have to modify some applications attributes, add some message, modify diagrams, but i want to do that in a branch or a version because iam not sure if it will be validated and I have to discuss this with multiple person, so , I cant commit this on the basic repository, 

So what to do, copy the database ? is there some versionning mecanism on mega ?, can we create a branch ofa bibliotech


Please share your experience !



Re: Configuration management in Mega 2009

Hello  jawed-fdj


If I understand, your question is 'how can I prototype customizations (metamodel,  diagram types..)'?


A simple approach is this one


1) For small changes, work in transaction

A transaction can help prototype many customizations.

Note: so that changes are considered within the transaction, you will need to trigger the event 'refresh context'


  • As long as transaction is not dispatched, changes are not committed.
  • You can archive the list of changes at any moment by exporting the transaction logfile (command file with .MGL extension).

However, you may need to dispatch your transaction as:

  • You need to check the consistency through metamodel compilation.
  • Certain changes are not considered without metamodel compilation.
  • There can be too many changes to manage...

2) When working in transaction is not possible, build a specific development environment

You can use several environments if you have several working hypothesis.



  • Customization impact mainly the system database. As there is one system database per MEGA environment, changes in customization impact the environment.
  • Customization should be considered as development. It is recommended to adopt a development methodology. The deliverable (output) is a command file with a set of changes.
  • Such command file can be applied to any environment provided its pre-requisite are fufilled (version, existing metamodel). See below.

A command files is valid for:  

  • A given version of the MEGA/HOPEX platform.
    If we consider a command file designed for HOPEX V1R1. It cannot be assumed that this command file can be imported in a previous version (ex: MEGA 2009 SP5). Import in a previous version is not supported. Import in a higher version (ex: HOPEX V1R2) require additional steps (conversion) and testing.
  •  A given metamodel
    For example: if a command file adds a MetaAttribute to a specific MetaClass, this MetaClass should exists in the environment where it is imported.

See also

Trigger the event 'refresh context'

Best practises to extend metamodel