Author Topic: Is the EA UUID modifiable via scripting or API?  (Read 349 times)

kjourdan

  • EA User
  • **
  • Posts: 63
  • Karma: +0/-0
    • View Profile
Is the EA UUID modifiable via scripting or API?
« on: December 11, 2017, 11:04:58 pm »
Does anybody know if the EA UUIDs can be modified via scripting or API? I am aware that the table entries in the database could be manipulated or an XMI file could be exported, modified and re-imported but I would like to work directly on the model.

EAUser3200

  • EA Novice
  • *
  • Posts: 16
  • Karma: +0/-0
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #1 on: December 11, 2017, 11:25:49 pm »
Hi kjourdan

AFAIK Its not possible to change the UUID's directly via API or scripting .

qwerty

  • EA Guru
  • *****
  • Posts: 8972
  • Karma: +136/-124
  • I'm no guru at all
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #2 on: December 12, 2017, 01:31:51 am »
You always can use Repository.Execute. The question is: why would you want to do that?

q.

kjourdan

  • EA User
  • **
  • Posts: 63
  • Karma: +0/-0
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #3 on: December 12, 2017, 08:08:08 am »
I am attempting to solve a round-trip problem. Sparx has indicated that the xmi file types under publish option (for export xmi) are not suitable for round-trip.

I am exporting XMI 2.1 (UML 2.3) from EA (with EA extensions turned off).  These files are transformed by an internally developed tool for use by an external  tool; the EA UUIDs are retained in these files.  The external tool may be used to modify, add, remove elements/attributes and save off the new files.

Using the internally developed tool, I can reverse this process and transform the files back into XMI 2.1 (UML 2.3) (without EA extensions). When this file is imported, the UUIDs are ignored and EA generates new ones.  If the UUIDs were stored as tagged values, I could import the xmi file into an empty EA project, run a script to manipulate the UUIDs in the model to match the tagged value.  I could then export the package as XMI 1.1 and compare as a baseline.  Differences could then be identified and merged as needed.

It would be a convoluted process but would work until something better could be developed; this would unfortunately require significant tool development.

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6200
  • Karma: +47/-5
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #4 on: December 12, 2017, 08:31:40 am »
When this file is imported, the UUIDs are ignored and EA generates new ones.
Maybe you could solve this problem instead.

If you generate XMI that pretends to be from Enterprise Architect and use guids that match our expected format they won't be recreated during import.
Simon

support@sparxsystems.com

kjourdan

  • EA User
  • **
  • Posts: 63
  • Karma: +0/-0
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #5 on: December 12, 2017, 11:10:23 pm »
Hi Simon,

The problem is a lack of documentation for the xmi 1.1 used by EA that would allow me to create EA compatible xmi files. Today, the best we could do was to create simple xmi (2.1) files without the EA extensions; xmi 2.1 is easier to work with from a tools side.

Does documentation exist at this time that would allow me to create EA compatible xmi files that support round-trip (can be imported as a baseline and compared)?

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6200
  • Karma: +47/-5
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #6 on: December 13, 2017, 09:01:11 am »
Yeah, XMI 2.1 is a lot easier to read.

I don't have any recommendations for producing XMI 1.1, but if you want to produce 2.1 that EA doesn't remove the guids from I can offer some suggestions.

Code: [Select]
<xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
<uml:Model xmi:type="uml:Model" name="EA_Model">

Packages, use a guid with the format:
EAPK_{8 hex digits}_{4 hex digits}_{4 hex digits}_{4 hex digits}_{12 hex digits}
Everything else:
EAID_{8 hex digits}_{4 hex digits}_{4 hex digits}_{4 hex digits}_{12 hex digits}
Simon

support@sparxsystems.com

kjourdan

  • EA User
  • **
  • Posts: 63
  • Karma: +0/-0
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #7 on: December 13, 2017, 11:15:47 pm »
Hi Simon,

Tried this path.  Addition of the Documentation exporter information does result in the UUIDs being brought in to EA but the stereotypes and tagged values are not. The Documentation exporter information is not enough; the EA add-ins must also be included within the xmi file.  Currently, I am generating and using XMI 2.1 / UML 2.3 files without EA extensions.  Importing this type of xmi file works with the exception of the UUID is not imported.

It has been indicated by Sparx that the formats in the publish xmi diaglog are not intended for round trip EA to EA and will lose information.  This means that the full xmi 1.1 or xmi 2.1 (with EA extensions) would need to be used.  This is where the problem lies since these are not documented (as far as I know).

Consider the following example xmi 2.1 file. With the Documentation exporter information, the tagged values and stereotypes will not be imported properly.  Without the Documentation exporter information, the UUID will not be imported.

<?xml version="1.0" encoding="windows-1252"?>
<xmi:XMI
  xmlns:uml="http://schema.omg.org/spec/UML/2.3"
  xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
  xmlns:CompView="http://www.sparxsystems.com/profiles/CompView/1.5"
  xmlns:PackageView="http://www.sparxsystems.com/profiles/PackageView/1.1"
  xmlns:BsmdView="http://www.sparxsystems.com/profiles/BsmdView/1.0"
  xmlns:thecustomprofile="http://www.sparxsystems.com/profiles/thecustomprofile/1.0" xmi:version="2.1">
  <xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
  <uml:Model xmi:type="uml:Model" name="EA_Model">
    <packagedElement xmi:type="uml:Package" xmi:id="EAPK_98135048_54de_98e3_41e1_66ccb1ecadc2" name="ARRoot">
      <packagedElement xmi:type="uml:Package" xmi:id="EAPK_6c39594c_de42_94ce_5590_ddb1fc9c5cfa" name="ABC">
        <packagedElement xmi:type="uml:Package" xmi:id="EAPK_7f79ac5f_0270_8793_c3a6_87ccac55ace4" name="Modules">
          <packagedElement xmi:type="uml:Package" xmi:id="EAPK_4746d95a_9e91_b0c0_545b_95c024876e9c" name="Example">
            <packagedElement xmi:type="uml:Package" xmi:id="EAPK_5aa610fa_e7e8_9c18_091a_e7a6a01f7036" name="BswModuleEntrys">
              <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_3ff4807c_be4f_9354_3544_d21ef997a6cf" name="Example_MainFunction"/>
            </packagedElement>
          </packagedElement>
        </packagedElement>
        <packagedElement xmi:type="uml:Package" xmi:id="EAPK_d0b31f64_3f9a_8366_277f_08225279a048" name="Interfaces">
          <packagedElement xmi:type="uml:Package" xmi:id="EAPK_c312de93_13af_92c9_27ec_53e2c6548df7" name="Example">
            <packagedElement xmi:type="uml:Interface" xmi:id="EAID_103d96e0_9bff_9e23_1133_b091323bd824" name="DrStatDrv_B_Actl"/></packagedElement>
        </packagedElement>
      </packagedElement>
    </packagedElement>
    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_E27C4BAF-C">
      <appliedProfile xmi:type="uml:Profile" href="http://www.sparxsystems.com/profiles/PackageView/1.0#E27C4BAF-C"/>
    </profileApplication>
    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_81D8F36A-0">
      <appliedProfile xmi:type="uml:Profile" href="http://www.sparxsystems.com/profiles/CompView/1.3#81D8F36A-0"/>
    </profileApplication>
   <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_61765CEA-5">
      <appliedProfile xmi:type="uml:Profile" href="http://www.sparxsystems.com/profiles/BsmdView/1.0#61765CEA-5"/>
   </profileApplication>
  </uml:Model>
  <PackageView:arPkg base_Package="EAPK_6c39594c_de42_94ce_5590_ddb1fc9c5cfa"/>
  <PackageView:arPkg base_Package="EAPK_7f79ac5f_0270_8793_c3a6_87ccac55ace4"/>
  <PackageView:arPkg base_Package="EAPK_4746d95a_9e91_b0c0_545b_95c024876e9c"/>
  <PackageView:arPkg base_Package="EAPK_5aa610fa_e7e8_9c18_091a_e7a6a01f7036"/>
  <BsmdView:bswmEntry base_Class="EAID_3ff4807c_be4f_9354_3544_d21ef997a6cf" serviceId="1" isReentrant="false" isSyncronous="false" callType="SCHEDULED" execContext="TASK" swServImplPolicy="STANDARD"/>
  <PackageView:arPkg base_Package="EAPK_d0b31f64_3f9a_8366_277f_08225279a048"/>
  <PackageView:arPkg base_Package="EAPK_c312de93_13af_92c9_27ec_53e2c6548df7"/>
  <CompView:sndrRecIf base_Interface="EAID_103d96e0_9bff_9e23_1133_b091323bd824" isService="false"/>
</xmi:XMI>

Exporting as a full xmi 2.1 file will include an XMI:Extension node which is specific to EA and not documented. 

The creation of an EA compliant XMI file that includes EA extensions would be difficult without documentation.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7751
  • Karma: +165/-21
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Is the EA UUID modifiable via scripting or API?
« Reply #8 on: December 13, 2017, 11:39:08 pm »
If I were you I would start by doing a simple import, and then using automation go over each of the elements, find it's original element and merge/replace the original with the new one.

This is not a small task, but at least you would know exactly what you are doing, whereas the xmi approach would be a whole lot of trial and error.

Anyway, there is never a reason to want to change the GUID of any API object.
The only result you'll get is an inconsistent model and maybe some database errors if you are lucky (unique constraint violation)

Geert

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6200
  • Karma: +47/-5
    • View Profile
Re: Is the EA UUID modifiable via scripting or API?
« Reply #9 on: December 14, 2017, 08:19:01 am »
I wouldn't aim for a full compatible EA file.

The tagged values and stereotypes won't come across on an EA import because EA isn't as restricted when dealing with tagged values than UML or XMI. Here's a sample, I hope that will do in lieu of formal documentation. I'd also recommend exporting a sample of what you're hoping to generate.

Code: [Select]
</uml:Model>
<xmi:Extension extender="Enterprise Architect" extenderID="6.5">
<elements>
<element xmi:idref="EAID_534E1D3B_D1E1_4ebc_A7E3_AED22938B718" xmi:type="uml:Issue" name="x" >
<properties  sType="Issue" nType="0" stereotype="stereotype"/>
<tags>
<tag xmi:id="EAID_88604871_F928_ebf9_B8D1_094CCDF06A1C" name="tag1" modelElement="EAID_534E1D3B_D1E1_4ebc_A7E3_AED22938B718"/>
<tag xmi:id="EAID_A0862D32_C049_20c0_943C_6486F19DF58C" name="tag2" value="a" modelElement="EAID_534E1D3B_D1E1_4ebc_A7E3_AED22938B718"/>
</tags>
<xrefs value="$XREFPROP=$XID={CA995F80-D5F1-40ea-92AB-5AB2D6F44D65}$XID;$NAM=Stereotypes$NAM;$TYP=element property$TYP;$VIS=Public$VIS;$PAR=0$PAR;$DES=@STEREO;Name=stereotype;FQName=profile::stereotype;@ENDSTEREO;$DES;$CLT={534E1D3B-D1E1-4ebc-A7E3-AED22938B718}$CLT;$SUP=&lt;none&gt;$SUP;$ENDXREF;"/>
</element>

Simon

support@sparxsystems.com