Author Topic: Providing own GUID when creating an Element  (Read 7243 times)

McBie

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Providing own GUID when creating an Element
« on: October 02, 2009, 01:32:38 am »
Hello ,
 I have a question regarding the GUID of new elements.

From the sdk documentation:
Quote
ElementGUID  - Read only. A globally unique ID for this element; that is, unique
across all model files. If you have to set this value manually, you
should only do so when the element is first created, and make
sure you format the GUID exactly as Enterprise Architect
expects.
Where can I set this value manually?

The creation method Elements.AddNew(string Name,string Type)does not take a GUID as parameter.

Thanks a lot!

Regards mArco

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Providing own GUID when creating an Element
« Reply #1 on: October 02, 2009, 04:24:04 pm »
Marco,

The first question that pops up is: Why would you want to set the GUID manually?

Have you tried passing the GUID in the name parameter? It's a long shot, but I've seen stranger behaviour in the EA API :-?

Geert

McBie

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #2 on: October 08, 2009, 06:33:40 am »
Hi Geert,

Quote
Why would you want to set the GUID manually?
Because we want to update the elements from time to time with data from  another system which provides an ID.
By using this ID I could access the element by Id instead of searching or iterating.

I tried your idea passing the id as "name" - it didn't work. I even tried one of their own IDs, but no luck.

I guess I'll store our Id as "Alias" and stick with searching and iterating  :-/

Thanks!
« Last Edit: October 08, 2009, 06:34:24 am by marcoAtsparx »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8607
  • Karma: +257/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #3 on: October 08, 2009, 08:12:59 am »
Quote
[size=18]...[/size]
Because we want to update the elements from time to time with data from  another system which provides an ID.
[size=18]...[/size]
Thanks!
If you already have the GUID, then the problem is easier.  As you have done, temporarily store the external GUID somewhere convenient - you've picked Alias.  Then you've established a mapping between the two GUIDs.  Then you use SQL queries to the back-end DB to replace the existing GUID in those tables in EA where it's used - with your GUID.  The exact nature and extent of this mapping will vary by item type - but it's not that hard - usually it's only a couple of tables.
Finally, when you've mapped it, you can either leave the external GUID where you placed it (as a failsafe) or remove it.

I've done this kind of thing before.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Providing own GUID when creating an Element
« Reply #4 on: October 08, 2009, 04:47:35 pm »
Marco,

If I were you I would still not create my own GUID's.
I would store the external ID in a tagged value (name could be something like "<externalProduct>ID")
That leaves the alias field to be used for the purpose it was intended for, and you don't get stuck if you ever need to do the same with another external product.
As for the searching/iterating, there are a few method in the API that can make your life a bit easyer.
- Repository.GetElementSet (string IDList, long Options) allows you to pass an SQL query that results in a list of element ids in the IDList parameter. That could be a very quick way to create a collection of elements. (this only works for EA.Element's)
- Repository.SQLQuery (string SQL) allows you run a query and get the results in an xml format. You could use this method to get a list of EAID/ExternalID pairs, which you could put into a dictionary or something for quick lookup.

These methods are very fast as they take full advantage of the database capabilities. (i.e. joining two tables) Trying the do the same by iterating all elements and their tagged values would be a lot slower.

This way don't have to mess with the backend DB, and you don't risk forgetting something. I think it will be a lot less error prone.

Also I have noticed that using the Repository.GetElementByID(long ElementID) is a real bottleneck when dealing with a lot of elements. (100+), especially if you're not working on a local EAP file.

Geert

Sébastien Jahan

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #5 on: June 11, 2011, 12:43:43 am »
Hi,

I would have the same question, but i haven't found an answer in this thread or elsewere...

I don't want to generate my own GUID, but we store Sparx EA data in our own repository through a connector/add-in we developped. We want to be able to re-use sparx component from our repository, and to re-use the GUID to be able to identify properly elements (avoid doubles, etc.).

Isn't really there a way to edit manually the GUID after a addNew on a package?

Thank you by advance,

SJ.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Providing own GUID when creating an Element
« Reply #6 on: June 14, 2011, 04:02:53 pm »
SJ,

I don't think I understood your question.
If you want to re-use the GUID on something else, why do you want to edit it?
Or are you trying to re-use an existing GUID on a new element? In that case, NOOOO :o, that would kind of defeat the purpose of the Globally Unique IDentifier wouldn't it?

Geert

Sébastien Jahan

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #7 on: June 14, 2011, 05:15:37 pm »
Hi Geert,

Please excuse me, my english is not always so good to translate my ideas.
Here is the story: we develop a connector/add-in, to store EA elements in our custom repository. The repository is supposed to be central, so every EA user has to connect and store his objects.
When an object is sent through our connector to the repository, we store the EA GUID.

We would like to be able to re-use an object from the repository, and to re-use it with the same GUID, to be sure every user has the same object with the same GUID so we can be sure that one object has one GUID across every user.
Maybe the way i'm creating the element is not good, i'm quite a newbie with EA API. I work with C# and i used the AddNew(name,type) function on the package.Elements.
So this function properly creates the element, but with a new GUID :(

I hope this is clearer.

So the EA->Repository connection is ok. The Repository->EA is nearly good, my add-in browse the repository and allow the user to select one object and to recreate it from the data stored in the repository. All the data except the GUID :(

Best regards,
SJ.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Providing own GUID when creating an Element
« Reply #8 on: June 14, 2011, 05:30:23 pm »
Hi Sébastien,

The only "safe" way I know of is to use xmi export/import.
The dangerous dirty way is to update the guid in the database after the elements has been created.
You can use Repository.Execute(sqlString) to execute SQL update statements.

Geert

Sébastien Jahan

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #9 on: June 14, 2011, 05:34:19 pm »
Ok, that's fine :)
I understand actually that if we want to update the Repository, we have to find every instance of the GUID to overwrite it, if we miss just one, that could be quite annoying !

Thank you very much and have a good day :)
SJ.

Sébastien Jahan

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #10 on: June 15, 2011, 02:06:02 am »
Just one more question:

Is there a way to get with a method the path of the current EAP file? I didn't find it and this is the only missing piece now.
Just for the record, i browsed the DB and found out (if i'm not mistaking, if i am please correct me right now) that right after the AddNew(), the element GUID wasn't used anywhere but in the ea_guid column of the t_object table.
I coded a little OleDbConnection and switch it right after the creation to the one stored in my repository and this works fine until now but i would like to be able to pass the EAP path to my connection string dynamically.

Thank you very much for your help,

SJ.

stao

  • EA User
  • **
  • Posts: 137
  • Karma: +0/-0
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #11 on: June 15, 2011, 03:57:56 am »
the path of the eap is stored in: repository.connectionString


STAO

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Providing own GUID when creating an Element
« Reply #12 on: June 15, 2011, 04:39:54 am »
And you don't need to roll your own db connection.
Just use Repository.Execute() and the API will take care of the rest.

Geert

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: Providing own GUID when creating an Element
« Reply #13 on: June 16, 2011, 03:36:54 am »
Except for parameters ("?") to be substituted which is neat to have in handling blobs (e.g. embedded pictures). And you don't get support for it since it's not an official interface. However, it's nice and works for most sql strings.

q.