XMI export automation from Java

[nicolas de loof]

Hello,

I'd like to automate XMI export from EA using Java automation.
My current code is :

Code: [Select]

       Repository r = new Repository();
        r.OpenFile( modelFile.getAbsolutePath() );
        App app = r.GetApp();
        Project proj = app.GetProject();
        proj.ExportPackageXMI( guid, EnumXMIType.xmiEADefault, 1, 1, 1, 1, output.getAbsolutePath() );
        r.CloseFile();

This fails as r.getApp() returns null.

Did I miss something ?

[nicolas de loof]

I just found by myself I can get the active project using :

Code: [Select]

Project proj = r.GetProjectInterface();
Now, proj.ExportPackageXMI has no effect. The guid is set from a CSV export, and is :

Code: [Select]

String guid = "{E82323AE-48E3-4008-953D-61CB45F1B591}";
Is this the right format ?

Another question : how can I connect to an Oracle based repository in place of loading an EAP file ?

[«Midnight»]

You need to pass what EA calls an XML GUID to your routine. This is a GUID string that has been adjusted to be acceptable as an XML name; it has no braces, a prefix to prevent a leading numeral, and the dashes are converted to underscores.

There are two routines in the API to convert to and from XML GUID formats.

[nicolas de loof]

Thanks for the tip.

It was simplier in my case to iterate through the Packages hierarchy from repo.getModels() based on packages names.

My XMI export no works based on EAP file.

I now have to make it work with a server connection.

[«Midnight»]

I am a bit concerned about the XMI and EAP situation.

I suggest you read the latest EA build (833, which came out in the past 24 hours) release notes on the history page to see if this has been addressed.

If not, and following a test with Build 833 just to be sure the bug persists, please report this to Sparx using the Report a Bug link on any forum page. Remember to tell them that you are using the Java API, as this bug might only occur there.

David

[Oliver F.]

I am a bit concerned about the XMI and EAP situation.

I suggest you read the latest EA build (833, which came out in the past 24 hours) release notes on the history page to see if this has been addressed.

If not, and following a test with Build 833 just to be sure the bug persists, please report this to Sparx using the Report a Bug link on any forum page. Remember to tell them that you are using the Java API, as this bug might only occur there.

Michael told me that such issues had been addressed in 833 and at least for CreateBaseline I can confirm the issue is fixed without being mentioned in the docs.
Obviously in the reference doc there was a mixture of guid and xmlguid where only xmlguid was valid.
I am not going to say that there are no further issues of that kind but fingers are crossed.

Oliver

[«Midnight»]

Oliver is correct here, on several levels. I think the "fingers crossed" remark is worth remembering.

The Sparx concept of XML-format GUIDs is a good idea, as far as it goes. After all, there was no acceptable format for a GUID (or UUID if you hail from 'that' universe) in XML names. So far so good, but...

When it came down to actually implementing these things broke down. There are two primary mechanisms for extracting XML via the API. If you extract information about individual components (elements, packages and such) you'll get what you need. If you extract breakdowns of the model (enumerations, model fragments, and such) you'll get what you need. But the XML GUID format for these two mechanisms differs! In some the GUID is rendered in lower case (then prefixed) and in others it is in upper case. Since XML is case sensitive by definition these two renderings of an XML GUID do not match. Given that the whole idea of the transformation was to provide acceptable naming for XML items, and that these names are used as the identifiers for item selection, the whole thing breaks down pretty quickly.

Unfortunately these two methods are ingrained in the EA legacy. There's no way to change the current methods without breaking all kinds of applications out there. That route is definitely not a go!

I've asked Sparx - via the normal (i.e. formal) bug report and feature request route - to address this in some fashion. Perhaps an additional set of API calls that together with either subset of the current calls would give us a complete set with the same protocol. Perhaps options in the engine someplace. Anything.

No response so far.

David

[«Midnight»]

Oh yes, as Oliver obliquely mentions, there is something about XMI and something about EAP files in the Build 833 release notes. It is worth taking a look through them anyway, as a lot of issues have been addressed.