Messages

1

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 28, 2026, 07:56:00 pm »

np...thanks for the input. I think the modeling team here really isn't too concerned about the actual underlying source and destination, just as long as the "diamond" shows up on the right side.

There are several in which the directional arrows are used, which, I assume, have been flipped correctly, since the modeler had to set them manually himself/herself, in order to show the directional arrows they were conveying.

E

2

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 28, 2026, 03:41:32 am »

So...Eve. In the GUI, I changed the source to be "Unspecified", and the Target to be "Navigable".

The Direction did indeed stay "Source -> Destination".

So, when creating a new Aggregation, basically you are saying that the navigable ends are being saved incorrectly, right?

I look at two Aggregations in the diagram, with the source and destination "Navigability" set in total opposite, and the Direction both = "Source -> Destination" and they look the same.

In t_connector, the only two columns I see closely related, and which have been mentioned in previous threads, are:
"SourceIsNavigable"
"DestIsNavigable"

SourceStyle on the "fixed" connector has "Navigable=Unspecified", DestStyle has "Navigable=Navigable"
SourceStyle on brand new connector has "Navigable=Navigable", DestStyle has "Navigable=Unspecified"

And other values for both rows are set the same, except the "fixed" one has SubType = "Weak"

Running the following on the repository:
select count(*)
from t_connector
where Direction = 'Source -> Destination'
and SourceIsNavigable = 0
and DestIsNavigable = 1
and instr(SourceStyle, 'Navigable=Navigable') > 0
and instr(DestStyle, 'Navigable=Unspecified') > 0

give me 354 "Incorrect" Aggregations.

Ouch

3

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 28, 2026, 02:25:28 am »

Thanks, Eve, for your input...but it has only confused me more (perhaps it could just be such a "newbie" on EA).

In the GUI, I create an "Aggregation", by dragging from my "Source Class" to my "Target Class", and the values are the following:
Direction = "Source -> Destination"
Source Class.Navigability = "Navigable"
Target Class.Navigability = "Unspecified"

Are you saying that the "Destination" is this GUI example is wrong, given the values for Navigability I specified above? Or am I not understanding something. Because after dragging, and creating, the Destination(Target Class) definitely says "Unspecified".

Also, as an FYI...I have yet to even include the "Direction" in the spreadsheet, only source class, target class, aggregation, and cardinality. I just noticed the behavior I am witnessing by the pesky arrow showing up in the GUI on the "Source" side, which led me to this forum.

E

4

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 23, 2026, 11:59:25 pm »

I think I have tried every combination of updates to the connector...setting the "Navigable" values on first the client end, then the supplier end, the Aggregation value, etc. etc. and even though the actual object shows direction = "Source -> Destination", when the connector is updated to the database, the Destination flips to "Destination -> Source".

Ouch...can't figure out what I'm doing incorrectly. I'll keep playing, but unfortunately, I have some real deadlines to do some actual modeling, so this may have to wait a couple of days. .

Aoppreciate all the feedback so fay, let's me know just what may be involved in this matter-anti-matter occurrence.

5

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 23, 2026, 01:17:41 am »

FYI...I even commented out the change to cardinality on oSourceEnd element, and the direction still changes after running the update on the oSourceEnd connectorEnd object.

6

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 23, 2026, 01:07:49 am »

What am I trying to achieve:
Modelers can enter a ton of data into a spreadsheet. They can change anything their big heart desires. If they do not pass a GUID for the relationship, a new connector is created. They can change source and targets if they want.
Therefore, the code I sent was a bare minimum, in order to try to figure out what is happening on this specific issue.

I even broke it down further. Running the following changes t_connector.Direction to "Destination -> Source", even though at the start it is "Source -> Destination":

Code: [Select]

  Set oConnector = eaRepo.GetConnectorByGuid("{43839C7A-F120-43d1-8B85-328F89BA9AE6}")
  Set oSourceEnd = oConnector.ClientEnd
  Set oTargetEnd = oConnector.SupplierEnd
'  oConnector.Direction = "Source -> Destination"
  oSourceEnd.Cardinality = "0..*"
'  oTargetEnd.Cardinality = "1"
'  oSourceEnd.Navigable = "Navigable"
'  oTargetEnd.Navigable = "Unspecified"
'  oTargetEnd.Update
  oSourceEnd.Update
  oConnector.Update

I also tried to change the ordering, as per an older thread that you actually commented on, so that the update was first called on the Target(Supplier) end, and the same behavior occurs.

7

Automation Interface, Add-Ins and Tools / Re: Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 22, 2026, 10:39:44 pm »

Understood...

I have cut down the code to the lowest common denominator.
When I set the EA objects, before the changes:
oConnector.Direction = "Source -> Destination"
oSourceEnd.Cardinality = "0..*"
oTargetEnd.Cardinality = "0..1"
oSourceEnd.Navigable = "Navigable"
oTargetEnd.Navigable = "Unspecified"

After running this (please know that the GUID I have selected is an "Aggregation"):

Code: [Select]

  Set oConnector = eaRepo.GetConnectorByGuid("{43839C7A-F120-43d1-8B85-328F89BA9AE6}")
  Set oSourceEnd = oConnector.ClientEnd
  Set oTargetEnd = oConnector.SupplierEnd
  oConnector.Direction = "Source -> Destination"
  oSourceEnd.Cardinality = "1..*"
  oTargetEnd.Cardinality = "1"
  oSourceEnd.Navigable = "Navigable"
  oTargetEnd.Navigable = "Unspecified"
  oSourceEnd.Update
  oTargetEnd.Update
  oConnector.Update

After the Updates:
oConnector.Direction = "Source -> Destination"
oSourceEnd.Cardinality = "1..*"
oTargetEnd.Cardinality = "1"
oSourceEnd.Navigable = "Navigable"
oTargetEnd.Navigable = "Unspecified"

In the DB:

Code: [Select]

select  rel.ea_guid, rel.Direction
from    t_connector rel
where   rel.ea_guid = '{43839C7A-F120-43d1-8B85-328F89BA9AE6}'
Direction = "Destination -> Source"

The flip on the t_connector table occurs after the first update statement
oSourceEnd.Update

After that runs, the magic happens

8

Automation Interface, Add-Ins and Tools / Re: t_diagramlink Issue when automating Connector creation

« on: April 22, 2026, 09:45:19 pm »

True...I should have said "Tweak the code to generate the "new" query"

split it into a union, with a not exists on the second part, works like a charm. Thanks again.
Learning something new every day.

Code: [Select]

select  rel.ea_guid
from    t_diagram diag,
        t_connector rel,
        t_diagramobjects sdo,
        t_diagramobjects edo
where   diag.Diagram_ID = sdo.Diagram_ID
and     diag.Diagram_ID = edo.Diagram_ID
and     instr(diag.PDATA, 'HideRel=1') = 0
and     rel.Start_Object_ID = sdo.Object_ID
and     rel.End_Object_ID = edo.Object_ID
and     rel.Connector_Type in ('Aggregation', 'Association', 'Generalization')
and not exists
          (select  1
          from     t_diagramlinks dl
          where    dl.ConnectorID = rel.Connector_ID)
and     diag.ea_guid in ('{36E4628C-768D-4919-B4D7-21ED246020F6}','{5EE6C77A-1109-48c6-A999-BA8221668F71}')
UNION
select  rel.ea_guid
from    t_diagram diag,
        t_diagramlinks dl,
        t_connector rel,
        t_diagramobjects sdo,
        t_diagramobjects edo
where   diag.Diagram_ID = dl.DiagramID
and     diag.Diagram_ID = sdo.Diagram_ID
and     diag.Diagram_ID = edo.Diagram_ID
and     instr(diag.PDATA, 'HideRel=1') = 0
and     dl.ConnectorID = rel.Connector_ID
and     rel.Start_Object_ID = sdo.Object_ID
and     rel.End_Object_ID = edo.Object_ID
and     dl.Hidden = 0
and     rel.Connector_Type in ('Aggregation', 'Association', 'Generalization')
and     diag.ea_guid in ('{36E4628C-768D-4919-B4D7-21ED246020F6}','{5EE6C77A-1109-48c6-A999-BA8221668F71}')



9

Automation Interface, Add-Ins and Tools / Aggregation Direction Flipping (Yes, I have read the threads ;))

« on: April 22, 2026, 09:31:31 pm »

Hi all,

Read several threads about this, yet the workarounds aren't working.

I have actually hardcoded the following to test.
oSourceEnd is connector's Client End
oTargetEnd is connector's Supplier End
oConnector is the connector itself

Code: [Select]

  oConnector.Direction = "Source -> Destination"
  oSourceEnd.Navigable = "Navigable"
  oTargetEnd.Navigable = "Unspecified"
  oConnector.Update

Looks as if the "IsNavigable" boolean no longer exists, so I can't hardcode that.

Can't get the direction to = "Source -> Destination", even though the actual object in debug says it is.

Ideas anyone? Must be doing "something" wrong? I am clueless.

Thanks...Eric

10

Automation Interface, Add-Ins and Tools / Re: t_diagramlink Issue when automating Connector creation

« on: April 18, 2026, 01:15:59 am »

You DA MAN!

My "real" SQL driver for the export of "connectors" is this:

Code: [Select]

select  rel.ea_guid
from    t_diagram diag,
        t_diagramlinks dl,
        t_connector rel,
        t_diagramobjects sdo,
        t_diagramobjects edo
where   diag.Diagram_ID = dl.DiagramID
and     diag.Diagram_ID = sdo.Diagram_ID
and     diag.Diagram_ID = edo.Diagram_ID
and     instr(diag.PDATA, 'HideRel=1') = 0
and     dl.ConnectorID = rel.Connector_ID
and     rel.Start_Object_ID = sdo.Object_ID
and     rel.End_Object_ID = edo.Object_ID
and     dl.Hidden = 0
and     rel.Connector_Type in ('Aggregation', 'Association', 'Generalization')
and     diag.ea_guid in ('{81D3FBA1-4F3F-4141-88C6-4CDACBB8DEB0}')

Guess I have to tweak the code to find all diagrams that have both classes, and force a save. Saving the diagram seems to be the only way to make it "stick"

11

Automation Interface, Add-Ins and Tools / t_diagramlink Issue when automating Connector creation

« on: April 18, 2026, 12:21:02 am »

Hi all...can't seem to figure this one out.

I run the exact code in the vbscript example outlines to create a new "Association" connector between two elements within my model.

My test diagram actually shows the connector named "test link 2".

When running the following sql to get the "links" on the diagram, the newly created connector is not in t_diagramlinks:

Code: [Select]

select  dl.*
from    t_diagram diag,
        t_diagramlinks dl
where   diag.Diagram_ID = dl.DiagramID
and     diag.ea_guid in ('{81D3FBA1-4F3F-4141-88C6-4CDACBB8DEB0}')
Anyone have any clues? Our modelers work within the diagram space, and do import/export work based upon information exported via code which creates a s/s based on diagram visibility, so this newly created connector will not be included in the report.

Thanks in advance...Eric

12

Automation Interface, Add-Ins and Tools / Re: Couple of questions regards creating a new "Connector"

« on: April 17, 2026, 01:17:37 am »

Thanks...I was afraid of that

Will work through it...also need to be able to update source and target classes on a given connector, without changing the underlying GUID. Playing around, and I was able to change the target to another class. I will continue to play, to see if I can change the source to another class as well.

E

13

Automation Interface, Add-Ins and Tools / Couple of questions regards creating a new "Connector"

« on: April 16, 2026, 10:58:50 pm »

Hi all,

I am trying to automate importing relationships between classes.

Looking at the code snippet, the example shows the connector object being added to the source class:

Code: [Select]

Set con = source.Connectors.AddNew("test link 2", "Association")[

Just curious whether that is absolutely necessary to add it first to the element, or can I just create a "new" connector, and then update the client and supplier ends after.
In other words, is the connector actually owned by one of the ends, or is the example just showing one way? When I debug the actual source and target elements, I see the connector associated to both, in their respective "Connectors" property.

TIA...Eric

14

Automation Interface, Add-Ins and Tools / Re: Help changing Parent on an attribute from one class to another

« on: March 28, 2026, 04:00:26 am »

Thanks for the tip...will play around

Update: thanks again...me not running the update solved the problem

15

Automation Interface, Add-Ins and Tools / Re: Help changing Parent on an attribute from one class to another

« on: March 28, 2026, 12:12:28 am »

curious...if I do actually use the rep.execute method, should I still run a refresh on the old and new class? I am checking the data in the actual underlying tables, and actually don't see anything that would actually need refreshing.

UPDATE...I ran a test, and debugged. My actual hardcoded update statement did work, and then ran an update(),  and the Object_ID for the row in t_attribute flipped back to the original class.

Weird, or am I not getting it?

E