IBAs, ModeledAttributesDelegate and Workspace limitations

[PN_5076692]

Hello,

in all the years of Windchill projects there is one problem-area that's always coming up:

The (Creo) workspace and it's (annoying) limitations.

Quite often there is a triple set of related objects: CAD Model, CAD drawing and a related item. (yes, that's somewhat simplified 😉 )
Model, drawing and item have usually a different number - which results in the "problem" that in a table view it's hard to group those triple sets or pairs in the table view.
A solution we sometimes use is to define an IBA on the EPM documents named "partno"  as well as on the WTParts. that attribute always contains the value of WTPart.number.

result: in the workspace it's possible to sort by column "partno" and the objects are grouped together. my customers like that.

But... while this is "ok" for smaller installations it's creating a lot of "duplicate" data in the database and especially in the StringValue table which is quite often already huge even without that attribute.

Problems:

Unfortunately the workspaces don't support "local" / alias / calculated attributes for WTParts.
EPMDocuments don't support "locals" anyway.

Local Attributes would be great as it would prevent further increasing the StringValue table.

ModeledAttributesDelegate

The MAD would be great for solving this. But the MAD only processes the EPMs.
The MAD could deliver a PartNo attribute for EPMDocs but not for the WTPart.

Over the years I tried different approaches for this requirement, but it seems to me that the only working way is to define a Global IBA PartNo and add it to EPM and WTPart.
This comes with the huge tradeoff that the systems stores the "WTPart Number" in multiple places and increases the StringValue table...

Has somebody also had this requirement?
Is there a better solution for it?

Thanks in advance!

[HelesicPetr]

Hi @PN_5076692 

What is your real issue?

You described how you've solve your user's case that you can group the part objects together.

Perfect. 

And now please describe what is your real problem, because the size of the StringValue table should not be problem if your database works good.

I know one customer that had a performance problem with this table, but it solves some indexes.

An another customer needed to move all string definition to the soft attributes an thanks that .he needed to customize all applications (WTP.getMyStringValue()) where the soft attribute has been used, but it solves the size of string table.

PetrH

[PN_5076692]

Hello @HelesicPetr ,

thanks for your reply!

It's not a hard real issue as the requirement with the PART_NO can be solved by using a regular Global StringValue IBA.\

At one customer we have about 500mio rows in the StringValue table which requires at least quite some diskspace / big indexes and DB performance.

So, there is a way to make it work.

My real issue is that I'm not happy what I need to do to achieve that goal.

From an IT perspective I'm not happy to store the WTPart number over and over again in the database. It's redundant data. That's usually regarded as not-ideal.

It would be somewhat better if I could use Local Attributes - I would still store the information over and over, but at least I wouldn't fill up the StringValue table.

Ideal would be If you alias / calculated the PART_NO value in the workspace somehow. 
That would eliminate the necessity to store the duplicate information completely. 🙂

Unfortunately the workspace doesn't allow the use of those. 😞

So I was hoping that somebody would tell me that I'm just doing it wrong and that there is way smarter way to do it 🙂

Regards

[HelesicPetr · Accepted solution]

Hi @PN_5076692 

There is not real better solution without hard customization of workspace environment.

Any workspace customization is against any standard procedures and will not be allowed in cloud environment in future.

Also any Windchill update cases that the workspace customization code will have to be updated to new release.

.  

PetrH

[PN_5076692]

Hi @HelesicPetr 

customization of the workspace environment:

Well.. I have thought about it, but I also don't think it's reasonable for this requirement. 

But hey... maybe PTC makes the workspace more flexible regarding attribute types in future releases? 🙂

Regards

[joe_morton]

Just an idea for another way of doing things:

Our numbering rules are as follows;

(WTPart Number) = (Model Number)

(Drawing Number) = (Model Number) + "-DRW"

I'm sure we're not unique in this. The consulting company that helped with our original Windchill installation said this was a typical way of doing the numbering. 

With this numbering, sorting on Number groups related objects pretty nicely. I'm sure other companies have different numbering requirements though.

[PN_5076692]

Hi @joe_morton 

thanks for your input too. 

For some projects this a possible way of course.

But that approach has also some limitations. For example it would require naming rules for multiple drawings, ...
There is also the question how to handle existing numbers...

We consulted in some projects customers to use this approach too. 

In the "bigger" projects it's usually not feasible as the numbers are pulled from connected ERP systems and follow company numbering schemes.
To my experience usually there a different numbering schemes for documents and articles/materials (WTPart)

Regards