Parts Classification Attributes

[BrianToussaint]

So I am about to roll out PartsLink Classification on our purchased parts.  I have a ton of possible attributes.  Some very specific to a specif node and some that can be more general.  My question is around the attributes for the nodes.  Should I try to use as many global attributes as I can or should I make them more specific?  A good example is voltage.  I know that each node will have it's own attribute, but in the Type and Attribute area, should I try to use as few as possible and point the node attributes to them as global?  What are the pros/cons of doing this?  I know a pro is that I have less to create.  But then should I just create all of them with that in mind?

Right now I have a mixture of the two and have over 120 attributes in my test system but have missed some that could possibly be global.  I'm just looking for ways to possibly lessen this going into my production environment if it is not detrimental.

[Casey_Swain]

I have this same general question.  Any lessons learned or best practices you can share?

[d_graham]

The easiest and most bombproof way I found was to create the csv that you can use to generate the xml to be zipped and imported to create your classification tree.

After successful creation of xml I run my custom utility which reads the same csv file and creates all the reusable attributes using the attribute name and the corresponding datatype in the csv file. If the same node attribute name with the same datatype occurs in more than one node, all will reference the same reusable attribute.

The advantage of doing it this way is the utility creates all reusable attributes in a few seconds and all required reusable attributes are guaranteed to be created before importing the zipped xml.

[avillanueva]

@BrianToussaint likely has solved this already since post was 2020 but as I expand our implementation (manually), I have a few tips.

• Never use a common name in node internal ID. Names will change but at some point. Using just an ID will allow you to correct structure issues easily if you have to make major changes. I have just used "node1, node2, etc" and put what I want like Set Screws is display name. Also, if you copy/paste a node(s), Windchill will append internal IDA2A2 number to end. 
• Reuse Global attributes as much as you can. So long as they are the same type and unit, keep the number of attributes small.
• Use the test server to validate new structures with end users. Sometimes they don't know what they want and do not understand full search capabilities.  Using attributes and facets can sometimes eliminate nodes that do not do anything but bucket parts.  This will help before you commit a lot of work to production.
• I am old school and did not use CSV file. Once we had a good structure, I can add incrementally live. Key is laying out a few levels down and making sure with users it actually works for them. 

[d_graham]

@avillanueva ,

@Casey_Swain posted he was looking for help on April 12, yesterday, that's why I posted.

In your post you state "Reuse Global attributes as much as you can."

I think you mean Reuse Reusable Attributes as much as you can.

To be honest, I've always wonder why all of use don't create just one Reusable Attribute for each datatype site wide.

For example a reusable named STRING that is a String and is reference by for ALL global attributes that are Strings.

Same for Integer, Boolean, Timestamp, etc.

The global attributes that reference the reusable attribute STRING would of course have a descriptive name but is there any reason the Reusable attributes need a descriptive name other than to distinguish their datatype?

Why does everyone seem to make many Reusable Attributes of the same datatype?

Unless I'm missing something this seems redundant (unnecessary) and we really need to create ONLY one Reusable Attribute per datatype Site wide.

I'd be very interested in hearing sound technical reason why any of us need more than one reusable attribute per datatype.

Who knows? Might fall into the "because we've always done it that way" category? 

[d_graham]

@avillanueva Tony,

BTW, I'm seeing some very strange behavior in 12.1.0.1.

It seems that if an attribute with the same name and datatype appears in more than one node that is classified to the same part the attribute appears only in the first node displayed when editing node attributes.

Meaning if attribute MAX_PRESSURE (Real Number) is in nodes Motors and Cylinders and you select both nodes Motor and Cylinders and then you attempt to edit their attributes MAX_PRESSURE will appear for only the first Node listed on the edit attributes window.

If that's not bad enough, if you classify to Motors (setting MAX_PRESURE = 25)  and checkin then later  classify to Cylinders, if Cylinders appears first (which is will due to alpha sorting) is will already display Motors value of 25 for MAX_PRESSURE.

Motors will not display the attribute MAX_PRESSURE. 

I know this sounds crazy but that is the behavior.

Which Windchill version are you working in and do you see this behaviors?

[avillanueva]

I was noodling on your suggestion. While you can call out an attribute from the global reusable attributes and call it something else in the node, I do not think it works as you described to call it out again and call it a second attribute name. Internally, I think there is a mapping back to the same global reusable attribute ID (like logical name) and since they would be the same, it can get messed up.  Here is something I did. I had soft typed parts with attributes listed as you normally would.  I then created a PartsLink node to replace the soft type (long term goal to get rid of soft typing).  When I classified that part, the attributes I added to the node automatically populated with the values I had before. That should be the clue that its doing behind the scenes mapping. Works in my case as I would want. 

[d_graham]

Tony, I hear you loud and clear but if we need to create a unique reusable attribute for each node attribute we will require the oh so small sum of 2,313 reusable attributes. 😂

Really? 2,313 reusable attributes? Good grief.

I did some testing to verify.

Created reusable attributes REAL_NUMBER and REAL_NUMBER_1.

Added attributes to node 1 and node 2 that reference both reusable attributes. The node attributes all have different internal names and display names.  The ONLY common thread is the reusable attribute.

Edit part classification and only the first node (alphabetically) displays the attributes. (No surprise here as this is what I've been seeing).

I then edit the node 1 that is displaying the attribute by deleting one of the attribute that reference REAL_NUMBER_1.

I then edit the part and sure enough node 2 that had not displayed the attributes now displays the attribute that reference REAL_NUMBER_1.  The attribute that referenced reusable attribute REAL_NUMBER of course still does not display.

Now, here's the craziest part of all of this.

I add a value to node 2 attribute for REAL_NUMBER_1. Then I added attribute REAL_NUMBER_1 back to node 1.

When I edit the part the REAL_NUMBER_1 is no longer visible of node 2 (no surprise) however, the value entered for it is displayed under node 1.

I'm telling you, you can't make this stuff up! 😂

This means that until this is fixed, and I would call this a bug, every node attribute in the entire tree structure MUST have it's own reusable attribute.  Good grief.

The dB has all info stored accurately.

Again, this is just a display problem. If I run a utility to automatically classify a part based on:

part number

node1 internal name

attribute1 internal name = <a value>

attribute2 internal name = <a value>
node2 internal name

attribute1 …

You get the idea. The dB is perfect fine.

The ONLY problem is the display when editing attributes and this is generated on the app side.

It really should not matter if the reusable attribute is reference by 1 or 1000 attribute definition.

If one has an attribute named LENGTH (Real Number) used in many types does one make a new reusable for each occurrence of the attribute in each type? I don't think so.  You just use the "reusable" attribute.

This issue rears it’s ugly head ONLY when a part is classified to more than one node that has an attribute that shares a reusable attribute with another attribute that should be displayed when editing classification.

For now I’m calling it a bug. If the PartsLink PM is listening let’s discuss.

[Casey_Swain]

Thanks @avillanueva for the tips!  Lots of good info here!

And thanks @d_graham for the curiosity and testing! 

I've wondered the same thing about reusable attributes but feared "crossing the wires" somewhere underneath.

Looks like that's a valid concern, at least for classification display. 

Do you use this level of one-reusable to many strategy for regular object subtype attributes? 

We've always used the Reusable to represent a given bit of business data, and reused it across types to represent the same data, mainly because that seems to be most consistent with the OOTB concepts as displayed in Type & Attribute.

[d_graham]

@Casey_Swain my two cents on this is as follows.

If you navigate your way through the database and follow how types, reusable attributes, type attributes that reference reusable attributes and the attributes values (all of which are stored in distinct tables in the dB) are related it becomes clear how it all works under the hood.

 I see nothing fundamentally wrong with having a single reusable attribute be referenced by more than one user-defined attribute that is added to a type.

The purpose of the reusable attribute is to define the datatype (String, Boolean, etc.).

The only restriction is that you can’t use the same reusable attribute on more than one attribute on any one type.

If you have a Real Number reusable attribute named LENGTH and you need a LENGTH attribute in CAD Documents and WTPart there is nothing wrong with reusing the reusable attribute as it is being used on two different types. Hey, imagine that, reusing a “reusable” attribute.

The problem we see with classification is purely a display problem that PTC should to fix.

As I mention our current PartsLink project has 325 nodes and 2,313 node attributes.

Does anyone really think requiring the creation of 2,313 reusable attributes node is “Functions according to spec”?

[DKWc]

Hi,

I'm facing a strange behavior on WC 12.1.2.4 using PartsLink.

The classification attribute displays the internal names of values for enumeration in Structure page, however on Details page it shows proper display value.

Any suggestions.

[avillanueva]

This sounds like something else. Recommend creating new post and providing screen shots.