Recursive Search for Part Properties

[Polymorph]

I have a model that contains a structural hierarchy of blocks, linked together with composition relationships. With each compositional relationship created, EA creates a part property that is nested under the element at the target (diamond) end of the connector. The nested part property is typed by the block at the source end of the composition and the behaviour is as expected and conforms with SysML 1.5. 


(Block hierarchy)
https://ibb.co/F79MPwc


(Browser structure)
https://ibb.co/ggfp7Pp

I need to produce a document template that can, starting at the "parent" block level, iterate down through each of the block/part pairs until it reaches the bottom of the tree. This is so I can generate a bill of materials (BOM). Moreover, I need to present not only the name of each of the component parts, but also the tagged values that it owns (which are relevant to the BOM, such as manufacturer/serial numbers etc).

The complexity of the document means that it cannot be achieved with a simple document template so I need to either construct a custom SQL fragment template or script.

Because the structure of the system can be arbitrarily deep, I have concluded (perhaps incorrectly) that I cannot achieve mu goals with SQL (I would have to set an arbitrary number of joins in my SQL query). I'm new to scripting in EA and but have decided I need to learn this skill.

The problem I have encounted is as follows:

The EA object model captures the relationship between the part property and its classifying block in the t_object.pdata1 field. When I examine the content of this field in the database I can see that - for the part property element - this field holds the GUID of the classifying element. This same information should be accessible via the Element.MiscData attribute, but when I try and return its value it is empty?

The EA help documents the usage of the MiscData as follows
https://sparxsystems.com/enterprise_architect_user_guide/15.1/automation/element2.html#:~:text=MiscData,and%20so%20on


My idea (ultimately) is to build a function that can be recursively applied, starting at a target (parent) block and running until it hits a classifer block that has no part properites; at which point it would stop.

Right now, I'm still in the development stages and am just using loads of Session.Output statements to try and work out what is going on. I thought this part of the problem would be the easy bit!

Here's the (JavaScript) code that I have so far. Can anyone offer a suggestion what's wrong?

Code: [Select]

function findPartProperties(objectID)
{
//Variable declarations
var currentElement as EA.Element // The element currently being processed
var childElement as EA.Element // A child element of the currently processed element
var classifierElement as EA.Element // The element that classifies a part (and may in turn have further parts)

//Set current element
currentElement = Repository.GetElementByID(objectID);

//Access child elements by looping through all nested elements
for (let i = 0; i < currentElement.Elements.Count; i++) {
childElement = currentElement.Elements.GetAt(i);
Session.Output("Found nested element: " + childElement.Name + " of type: " + childElement.Type + " and with classifier: " + childElement.MiscData(1));
}
}

The session output I get is as follows (with "System Design1" block set to the current tree item):

Code: [Select]

Found nested element: ci1apart of type: Part and with classifier:
Found nested element: ci1part of type: Part and with classifier:


[Geert Bellekens]

One of the things you'll have to learn when doing anything with automation, is that you sometimes have to resort to querying the database directly; often because the API does not expose every detail of the model, and sometimes because it would be too slow otherwise.

Now in this case, have you checked Element.propertyType? That might contain the elementID of the classifying block.

If that doesn't work, use Repository.SQLQuery() or Repository.GetElementSet(sqlString, 2) to get what you need from the database directly.

Although fun and interesting, I would not be inclined to the scripting way for a document template too quickly.

You say that you have an arbitrary lenght of nesting, but do you really. Does you nesting ever go deeper than 10 levels?
Because in that case you can easily write a query with 10 joins.
It's just a bunch of copy/paste, and it looks ugly, but it's probably a whole lot faster in both development as execution than a script would ever be.

Geert

[Polymorph]

Thanks for the rapid reply Geert! I must confess, you are probably right regarding the nesting depth! Is querying the database from a script fairly fast? If so, I am tempted to call a search from the script and then do further processing on the results in the script itself.

[Geert Bellekens]

Thanks for the rapid reply Geert! I must confess, you are probably right regarding the nesting depth! Is querying the database from a script fairly fast? If so, I am tempted to call a search from the script and then do further processing on the results in the script itself.

Yes, querying the database is much much faster than anything you do using the API in a script.
And with "much much faster" I mean the difference between 2 seconds and 20 minutes.

Geert

[Polymorph]

Now in this case, have you checked Element.propertyType? That might contain the elementID of the classifying block.

Geert, you total legend! Thank you that worked a treat! 

However, I will be mindful of your advice regarding the speed advantages of SQL. I am partly doing this because I need to learn scripting sometime and this felt like the right time to try!