Data Transfer between repositories, Working / Production, V1R3cp14.

[mkaczar]

Hello,

My EA Team and I are fairly new to the Mega and we are setting up a production repository to publish our models and generate the static Mega Web site. But were having problems getting the export / import objects from the working to production repositories to work correctly.

When exporting a diagram, it's not bring in all the object, Functionalities etc. on the diagram...

Note: I found a Mega document called Data Transfer between Repositories, but it was written for version 2009 SP5.

Is there any information / documents to transfer data or Export / Import for V1R2/V1R3? I performed a search in this site, but didn't find anything relevant.

Any assistance for best practiced for this use case is appreciated.

Thanks,
Mark

[KElsner]

We have different environments and copy e.g. the whole PROD environment to the TEST environment for test and change purposes. The evironment copy process is done on physical database level by our database administrator with additinal tasks as MEGA administrator. We are following instructions mentioned in a mega support article called "RDBMS environment duplication -Oracle -"

[SVanSchoonlandt]

you should never allow data transfer between repositories with different metamodel.

If you want to test out the evolutions of your metamodel and website. You should setup a seperate environment and only use it for verification and testing of your technical data changes. If you do that, you should be able to make use of the compare and align feature between your work and production repository because then they can be part of the same environment.

[ymlesaux]

We use different environments to allow some evolutions on meta models and publications with no impact on production before qualification of those evolutions.

[SVanSchoonlandt]

if you use  export/import with that perimeter it's just going to drag along to much junk to your publication environment which you don't want to be there yet. If you are doing this, you should create a customized perimeter which will just get the data out of the repository that you need.

Furthermore, you should not use export/import but compare and align if everything is in the same environment. It will take care of cleaning up the removed objects also.

@ymlesaux I don't understand why you have multiple environments setup? Can you elaborate?

[ymlesaux]

In our context, we use work logs to publish our works to a production environment. We are almost satisfied with this approach.

We used that way to include objects deletion into the delivery which is not applied inexport/import approach.

Also, the "Compare & Align" feature is only applicable in a single environment, which means that publication types (Web site or RTF) are shared. So it is not applicable in our context (we don't want to publish officialy some models in progress).

[mkaczar]

Hi,

Thank you, this helps.

With additional trial and error, I discovered one of the Perimeters, “Standard for Extensions (Compatibility 2009 in Hopex Mode)", worked when I Exported/Imported a project! I'll look into the Compare & Align feature and test it. Sounds like we can use this in place of the Export/Import or use it once we have imported the project and run the compare & Align if any changed take place in the source repository.

I played w/ the transfer, created a test template, added a test object to transfer, and scheduled the transfer. But haven't been able to get it to work, it rejects each time. We'll most likely use the Export/Import Compare and Align at this point, so this isn't a priority. 

Thanks,

Mark

[pvandeginste]

Hi Mark,

If your repositories are in the same MEGA environment, there is a tool called "Compare & Align" to help transfer data. You can run the utility on an object, a repository, or from your transaction I believe. It compares the state of the objects between a source and target repository, and then allows you to "transfer" the differences to the target repository. A couple of things to keep in mind:

- duration of the compare & aling operation: the more objects you're comparing, the longer it can take

- pick the right perimeter: the "perimeter" in HOPEX determines what related objects will be included in the operation based on propagation from the object you are performing the operation. Export and Compare & Align use the perimeter. It is possible that the perimeter you selected does not include certain objects related to a diagram, which would explain why they weren't included in the export.

- We use both export and compare & align, depending on what we're transfering. If I  need to transfer a set of objects, and their diagrams but only to 1 or 2 levels of decomposition, I prefer using queries to build an export file because I can more easily control what gets included in the export. For example we have processes that are decomposed to 3 levels of detail, but the users only want to transfer the first 2 levels: if I use the perimeter, everytime HOPEX finds a process with a diagram, it will export it, regardless of the level (so my transfer now includes all 3 levels of processes). Using queries, I can extract just the 2 levels I want.

I believe the data transfer functionality still exists in V1R2/R3: I think the value of it is that users can submit content for validation, and once it's validated it can be added to the transfer queue that you can schedule to run.

There should be documentation on the comapre & align function in the online documentation: I believe it's in the Administration user guide.

Hope this helps,

Philippe