Is PTC's spec faulty? - Publish EPMDoc updates non-latest WTPart which may lead to erronous Released data

[cbunes-roa]

If your company has set up Windchill with WTParts and publishes EPMDocuments both on Checkin and during the Release workflow this behaviour may lead to incorrect data to be Released. I will present two use cases that describe the problem. While the first is easiest to reproduce it leads to no critical errors but could still be seen as incorrect behaviour. The other causes non-latest data to be released.

TL;DR: The published representation of an EPMDoc when its WTPart has been iterated past latest "built" configuration is copied to non-latest WTPart. PTC states this is "working according to spec". Should the spec be treated as a bug?

Settings in wvs.properties:

publish.copyrepresentationsforward=true (Representation should be copied forward to the new iteration)

publish.copyrepresentationsforward.restrict=false (Representations for WTParts should be copied forward to the new iteration)

Use case 1:

1. Create a CAD model with WTPart
2. Wait for publishing to complete
3. Iterate WTPart without EPMDocument
4. Promote WTPart 1.2 and EPMDoc 1.1 to Release
5. Representation created from publishing during workflow is not linked to latest WTPart

Since CAD data has not been altered and the representation of WTPart 1.1 is copied to WTPart 1.2 on iteration this use case does not lead to erronous data being released. If you'd go into Representations/Annotations you will see that WTPart 1.1 shows the representation published during the release process while latest iteration will show that it was copied from WTPart 1.1 before it was published during release. While this causes no critical issues it can still be seen as faulty.

Use case 2 (during heavy load on worker):

1. Create and check in CAD model with WTPart, wait for publishing to complete
2. The worker is now under high load and the queue is long, which means it may take several minutes for next-in-line publishing to complete
3. Check out WTPart and EPMdoc, modify EPMDoc and check in.
4. Publishing of EPMdoc is now in queue. WTPart get representation from 1.1 copied.
5. Check out WTPart, modify attributes and check in. WTPart get representation from 1.1 copied. Publishing of EPMDoc 1.2 is still in queue.
6. Publishing of EPMDoc 1.2 finishes and the representation is copied to its "built configuration" WTPart 1.2
7. Latest WTPart now show non-latest and not up to date model as its default representation
8. Promote all latest to Released
9. Publishing during workflow is linked to non-latest WTPart
10. Latest (Under Review) WTPart now shows wrong model in Windchill and in Creo View
11. Approve Promote Request. Part Configuration of the released structure is generated during workflow.
12. Latest (Released) WTPart and Part Configuration now shows wrong model in Windchill and in Creo View

With a sufficiently large organization this scenario may play out for more than just this one customer we've identified the problem at. The worker may have a long queue and since there are no option to define that publishing should link the resulting representation to the latest WTPart this may cause erronous data to be released.

I've brought this to PTC's attention but I'm told that this is working according to spec and it will not be fixed. We tried to argue that if this was the spec then the spec surely must be faulty, to which I was told we would have to present our findings to the PTC Community to see if I'd get support here for these findings. PTC states that "WVS determines the earliest 'built' WTPart iteration to be the 'Representable' object".

This was our feedback from PTC (customer name removed): The official response is that we have no near term plans to change the current behavior. [You] might want to put forth their use-case / scenario on the PTC Community and see how other customers may have addressed this use-case, if indeed they have the same situation as [your customer].

I have seen (and voted on) a product idea from Nicola Giacomelli‌ asking for this functionality so I know at least some out there see things our way. Have any of you other Windchill users seen or experienced this potentially grave issue and if so how have you addressed it? If you haven't seen it yet I hope that you see it as a potentially dangerous flaw in this behaviour and can vote for the product idea suggested by Nicola Giacomelli.

CS61223 & SPR 2186339

[GregoryPERASSO]

Hi

Agree with you for this particular point.

I still don't understand why the Representation handle by the EPMDocument is copied  forward to the WTpart in the Viz Service.  Except that the actual Worker behaviour is to copy some WTpart informations in the Rep.  I've personnaly an idea to dynamically load attributes from any objects in Creo View session ....

We use multi owner capability.  And that lead also to some weird things, cause the 1st owner link take the lead to other Wtparts ... the Representation is then duplicate on other WTparts from the 1st one, even if they have to be exactly the same ...

Anyway..   I think you probably talk about Assemblies Rep ? more than Component Rep ?

Cause for assemblies,  the default rep is always generated from a specific ConfigSpec (latest , astored ...) which will give a "static" structure  .  And then obsolete représentations if some sub levels are changing

But if you use the Dynamic representations.  I mean by loading a specif Configuration of your WTpart BOM . (based on any filter available in Windchill).  You never have obsolete Rep.  You are Wtpart centric and Windchill load and position components "has configured"

Some restiction about parts with assembly features, but last enhancements of the Vizualiation Service (since 10.2 M020 CPS17 I think ) allow to handle most of cases

Another idea for me.  A pref that permit to set the dynamic Viz as default (even if the little rep displayed on WTpart info page is not really up to date:  just a tiny image for helping users to see what kind of part it is ...)

[cbunes-roa]

Gregory PERASSO wrote:

I think you probably talk about Assemblies Rep ? more than Component Rep ?

Cause for assemblies,  the default rep is always generated from a specific ConfigSpec (latest , astored ...) which will give a "static" structure  .  And then obsolete représentations if some sub levels are changing

But if you use the Dynamic representations.  I mean by loading a specif Configuration of your WTpart BOM . (based on any filter available in Windchill).  You never have obsolete Rep.  You are Wtpart centric and Windchill load and position components "has configured"

Some restiction about parts with assembly features, but last enhancements of the Vizualiation Service (since 10.2 M020 CPS17 I think ) allow to handle most of cases

If I understand you correctly you are referring to the fact that you can see a different assembly representation if you go into the Structure tab on the object info page than what you will see in the preview window under the Details tab. I am not referring to that, no. That one that you mention is another "feature" which is not very intuitive for fresh, or even seasoned, Windchill users to know about. My abovementioned issue can be reproduced even for component representations. In fact this is what I've described in order to try to keep things simple.

[GregoryPERASSO]

OK

So agree with you.  It should be a bug

The owner link between WTpart and EPMdoc tracks precisely the exact iteration of the CAD that Build a WTpart

So whatever is the Worker load, or even whatever id the order you pubilsh the parts ...  the correct representation should be linked to the WTpart !

[cbunes-roa · Accepted solution]

Anders Kullenberg, one of my very competent colleagues, brought this to my attention:

With Windchill 11.0 M020 comes a new wvs property that seems to adress this issue. It is possible to enable the primary owner association to latest WTPart iteration when publish.representable.owner.usefirstiteration is set to false.

I've run a few tests on this with my 11 M020 test server and can confirm that this indeed solves these issues. Now it seems it's just a matter of getting the customer upgraded to the latest Windchill release.