Config Spec Conundrum - How do I publish 'As Relea...

TomU · ‎Jul 05, 2018

I'm running into two fairly significant problems with Windchill and I could really use some help.

Additional files generated during publishing do not always agree with the corresponding models (at the same revision.)
Users outside of engineering are unable to view all of the models in an assembly in Creo View.

Both of these situations are being caused by the publisher using the 'As Stored' config spec when the 'As Stored' version of the model is not the same as the 'As Released' version. For example:

Drawing or Assembly

A.1 - In Work

A.2 - Released

Model

A.1 - In Work

A.2 - In Work ('As Stored' when drawing version A.2 was created.)

A.3 - Released

A.2 of the drawing/assembly and A.3 of the model are both released together, but when published the older, unreleased version of the model is being used. For drawings this could mean the wrong geometry is displayed. For assemblies it means that users outside of engineering can't even see the model since they are not allowed to view 'In Work' objects. (We use positioning assemblies to dynamically pull the models in during viewing.)

In this simple example, switching to 'Latest' would fix the problem but it may cause much bigger problems in the future. For example, if we add several new revisions to the model and then republish the drawing, the new representation for the old drawing (or assembly) will now show the latest models at revisions that didn't exist when the drawing (or assembly) was originally created.

Drawing or Assembly

A.1 - In Work

A.2 - Released

Model

A.1 - In Work

A.2 - In Work ('As Stored' when drawing version A.2 was created.)

A.3 - Released

B.1 - In Work

B.2 - Released

C.2 - In Work

C.2 - Released.

Republishing the drawing after C.2 of the model is created means the drawing will now display C.2 instead of A.2 (or in a perfect world, A.3.) Every time the drawing (or assembly) is republished the contents will change.

There seem to be two root issues here - user behavior and system behavior.

User Behavior - Is it realistic to expect a user to check out and re-save each drawing and assembly every time any component in the drawing/assembly changes? Even when the change is just to an attribute? Without re-saving, the 'As Stored' config spec. is pointing to an older version of the dependent objects.
System Behavior - Is there any way to allow the system to publish using an 'As Released' config spec.? If not, what about publishing with the version references instead of object references? (Version references always point to the latest iteration of an object at the specified revision.)

I've run some database queries and analyzing just drawings alone I have over 17,000 latest, released drawings where the 'As Stored' version of the drawing's model does not match the latest version of the same model. (Most of these 'As Stored' and 'Latest' models are at the same revision, just not the same iteration.) I can't imagine the situation with assemblies is any better.

Any suggestions?

Note - Publishing is automatic, not something users manually do. Additional files generated during publishing are sent to both internal and external suppliers for manufacturing. Promotion requests are being used in a limited fashion but the vast majority of the objects currently in the system were released via 'Set State' and we don't use WT Parts.

BenLoosli · ‎Jul 06, 2018

Education on the part of your users that the drawing MUST be the last item saved.

The Model and drawing MUST be at the same version! You do not revise the model without also revising the drawing.

Modify the workflow with code that checks the drawing modified date with that of the model. If the model is newer, reject the check-in and do not publish. I know Great Plains Manufacturing has modified their system for this, but the code to do it is proprietary. I would love to have the code if someone develops it and can share it. Maybe PTC needs to modify the base code with a preference setting that requires the drawing to be the latest.

TomU · ‎Jul 09, 2018

It's not revising that's a problem, we revise both together, rather it's making additional changes to a model after the drawing or assembly has already been checked in. It might be 10 seconds later, but it's enough to make the 'As Stored' config spec unusable.

The thing I'm struggling with is the need to check out and re-save the drawing and all assemblies anytime ANY change is made to a model, even if the change has no impact on the drawing and/or assembly. For example, simply opening a model, hiding a layer, saving the status, and checking it back in now requires that the drawing and every assembly it's used in (and all of the parent assemblies all the way up the structure) to also be checked out and re-saved. This seems nuts. It's the same problem we are trying to avoid by not publishing 'Latest' - the never ending 'rev rolling'.

Does your custom code prevent checking in all assemblies if any component in the assembly is newer than the assembly itself, or do you just do this with drawings?

TomU · ‎Jul 09, 2018

Does your custom code prevent checking in all assemblies if any component in the assembly is newer than the assembly itself, or do you just do this with drawings?

I just realized this question makes no sense. It should say, "does your custom code prevent checking in a model if any assembly exists anywhere in the database that references that model and isn't also being saved and checked in at the same time?" That's really what we're talking about. Never having a model newer than the assembly. The only way to prevent that is to never allow a model to be checked in without ALL corresponding assemblies and drawings, right?

RandyJones · ‎Jul 09, 2018

@TomU wrote:

Does your custom code prevent checking in all assemblies if any component in the assembly is newer than the assembly itself, or do you just do this with drawings?

I just realized this question makes no sense. It should say, "does your custom code prevent checking in a model if any assembly exists anywhere in the database that references that model and isn't also being saved and checked in at the same time?" That's really what we're talking about. Never having a model newer than the assembly. The only way to prevent that is to never allow a model to be checked in without ALL corresponding assemblies and drawings, right?

Our custom code only checks objects submitted on a promotion request. It does not check objects on a check in.

TomU · ‎Jul 09, 2018

Our custom code only checks objects submitted on a promotion request. It does not check objects on a check in.

Are you checking both drawings and assemblies?

For drawings it seems like it would be relatively straight forward since you just have to look at the children. For assemblies wouldn't you need to check all of the parents as well? Do you really re-release every single assembly and sub-assembly in a structure anytime a component inside one of the lower level sub-assemblies changes? (Even for an attribute change???)

RandyJones · ‎Jul 09, 2018

@TomU wrote:

Our custom code only checks objects submitted on a promotion request. It does not check objects on a check in.

Are you checking both drawings and assemblies?

For drawings it seems like it would be relatively straight forward since you just have to look at the children. For assemblies wouldn't you need to check all of the parents as well? Do you really re-release every single assembly and sub-assembly in a structure anytime a component inside one of the lower level sub-assemblies changes? (Even for an attribute change???)

We are only checking to make sure the drawings reference the latest (drawing) model and the latest format(s). We are not diving into the assemblies and checking those.

TomU · ‎Jul 09, 2018

@RandyJones, wouldn't that essentially be the same as the "BOM Release Rule"?

http://support.ptc.com/help//windchill/wc110_hc/whc_en/index.html#page/Windchill_Help_Center%2FWCCG_BusLogicCust_BusRules_Load_WCCG_BusLogicCust_BusRules_LoadTypes_4_Examples.html%23

RandyJones · ‎Jul 09, 2018

@TomU wrote:

@RandyJones, wouldn't that essentially be the same as the "BOM Release Rule"?

http://support.ptc.com/help//windchill/wc110_hc/whc_en/index.html#page/Windchill_Help_Center%2FWCCG_BusLogicCust_BusRules_Load_WCCG_BusLogicCust_BusRules_LoadTypes_4_Examples.html%23

Possibly. I have never played with business rules so I do not know what they are capable of or how flexible they are.

MikeLockwood · ‎Jul 06, 2018

As stored is generally the right and only choice that makes sense for publishing.

Publishing results in a static image that has to synch with the models that the published drawing is displaying / published assembly is displaying. This is different than a config spec applied dynamically to product structure, for which "latest released" is a valid option to apply.

TomU · ‎Jul 09, 2018

Publishing results in a static image that has to synch with the models that the published drawing is displaying / published assembly is displaying.

This is okay on the drawing side because the PDF we create of the drawing isn't going to care if some of the models displayed on the drawing are not released. This doesn't work on the assembly side where we use extended positioning assemblies for all assembly publishing. Users outside of engineering are only allowed to view released models. If the 'As Stored' config spec. references non-latest, 'In Work' versions of a model then the full structure doesn't load in Creo View for these users.

It would be great if I could publish using 'Latest Iteration at Current Revision' of each dependent model since those are the versions being released.

I'm just really surprised other people aren't struggling with this. Maybe it's more of an issue for us due to heavy use of positioning assemblies...

BenjaminWagner · ‎Nov 26, 2018

Hi TomU,

we came across your request here, which very much describes a problem we are currently dealing with, too.

I wonder if you found any solution since you posted this question. Or any workaround?

Maybe you are interested in discussing this in more detail.

If so, please let me know.

Kind regards,

Benjamin

TomU · ‎Nov 26, 2018

I don't have a better solution yet. I keep beating into everyone's heads that anytime they save a part they also need to save the upper level assembly and re-save the related drawing(s). I have also contracted with a developer to create something similar to the BOM Release Rule for promotion requests. I'm having him add a check to make sure the objects under promotion are all referencing that latest versions of the objects they are referencing. Hopefully this will prevent this situation from reoccurring in the future.

SYang · ‎Dec 11, 2018

Hi Tom,

Are you trying to publish CAD objects with the following Config spec by default? (see screenshot below) or do you want to publish those CAD objects with 'Latest Iteration at Current Revision' of each dependent model?

I once worked with you when creating the publish utilities publishing jobs based on EPMDocument's object identifier(OID) from a CSV in the article CS211115 and just want to help you creating a article with this custom publisher

Life Cycle Config spec:

TomU · ‎Dec 12, 2018

I'm not sure exactly what that highlighted option does, but for automated publishing there are only two possible settings - 'latest' or 'as stored'. Our system is currently configured to publish on check in and then republish again on change (set state to 'Released', etc.) I'm not sure this option is useful for automated publishing...

SYang · ‎Dec 14, 2018

Hi TomU,

If we provide an option to publish cad drawing with LifeCycle: Released Configuration Specification in the following article:

https://www.ptc.com/en/support/article?n=CS238377

so Windchill publishes or republishes the representation when an EPMDoc is changed to Released Lifecycle states, would it be a workaround on this issue?

TomU · ‎Dec 14, 2018

Based on what I'm reading in CS230180, no it would not. 'Lifecycle:Released' is not equal to 'Latest Iteration at Current Revision'. For file synchronization enabled CAD workers (which are recommend by PTC), the 'Lifecycle:Released' config spec will fall back to 'Latest' anytime a 'Released' version is not available. I also don't seen anything stating that 'Lifecycle:Released' won't jump to the 'Latest Released' during future republish events. Having a representation use a completely different revision, and especially one this is not released, it not a solution.

I really just need a new config spec. 'Latest iteration of as-stored (or target) revision', and then some way to make it the default config spec. for automated publishing. Basically a hybrid of the current 'Latest' config spec. and 'mark out of date' functionality, but in a way that won't cross revision boundaries. It should always use the latest iteration of whatever revision is being requested. Make sense?

SYang · ‎Dec 18, 2018

Hi TomU,

We can internally create a new snapshot of an evolving collection of data objects as a baseline from the Drawing's as-stored config spec. In this case, the baseline can be essentially a snapshot of the Latest iteration of as-stored (or target) revision. It will be created automatically when admin republishes the drawings

We may then add a new wvs scheduler to the article CS211115 that publishes the latest Drawing objects with this new Baseline Configuration Spec.

We cannot make it the default config spec. for automated publishing.

Not sure if this new wvs scheduler would help

TomU · ‎Dec 18, 2018

In my case, if it can't be the default config spec. for publishing (especially republishing on change), then no, it won't help.

The correct solution is to make sure anytime a part is changed that all referencing objects (assemblies and drawings) are also updated as well. This just creates a tremendous amount of work that really shouldn't be necessary and doesn't add any value. It's just updating references in the database that wouldn't need to be updated if I could publish using 'latest iteration of as-stored revision'.

SYang · ‎Mar 15, 2019

Hi TomU,

Please take a look at attach DOC documents if it can be a workaround

Attachment:

Instructions.docx - AddToWorkspaceFromCSV

Instructions2.docx - AddLatestToWorkspaceFromCSV

Instructions3.docx - AddLILVToWorkspaceFromCSV

You may then create a baseline and copy those added objects in the workspace to the baseline by selecting them in the workspace using Quick Link > Copy Page. In the baseline, go to Action > Paste in the Related Objects tab. You may now publish it using the baseline

d_graham · ‎Mar 07, 2019

Tom,

If this is still an issue I think I have a solution for you.

If I understand the problem correctly you want a snapshot of the drawing and the required dependencies in their latest configuration at the moment the drawing is released.

If this describes what you want this is very doable.

Have you tried using the APIs to create a ManagedBaseline that consists of the Drawing and all Required dependencies using Latest ConfigSpec. If you create this baseline the moment the drawing is released you'll have your snapshot.

When you publish you can reference the Baseline either using the GUI or if need be using the APIs.

When you publish using the APIs you pass the ManagedBaseline to the doPublish method by using it to create a BaselineConfigSpec.

Hope this help and sorry for the slow reply. I've been out of the Windchill coding scene for a while but I am back in the game again. If you know anyone who needs help let me know.

David Graham

d_graham · ‎Mar 12, 2019

Tom,

I've posted a suggestion publishing a baseline.

Since then I thought this a good problem and therefore have written a class that does exactly what you've described and best of all it does not necessarily have to be run at the moment the state is changed to the state in question. You can run it days, weeks, months, whatever after the state change and it still build the same ConfigSpec you'd get if you ran it at the time the of the promotion.

The trick is to build a baseline that consists of all dependencies as they were at the moment the top level object was released. You can get this time from the top level object's LifeCycleHistory.

Next you get a list of dependencies of the top level object at the time in question. The easiest way to do this is to use the CadCollector class.

Next get the latest iteration (that is not a working copy) of each dependency as of the time in question. If you want the latest iteration at a specific state as of the time in question that too can easily be tested for.

Add those latest iterations to a WTArrayList().

Create a WTCollection from the WTArrayList and then add the WTCollection to a ManagedBaseline

As for the drawing format, you can code such that the latest non-working copy is added rather than the latest as of the time in question..

The baseline is passed to the doPublish() method to be published. That's it.

If you don't want to keep the baseline, as it's only for publishing, you can delete it when done.

In my code I keep it but I give it a description that describes what it is and why it was created.

d_graham · ‎Apr 19, 2020

Tom,

This is very doable but not OOTB. It is possible to specify a desired ConfigSpec when publishing. In your case you want to specify a ConfigSpec based on a the state released.

The actual publishing can be automated using the doPublish() method and pointing this method to the desired ConfigSpec.

A way to implement this it to fire off the doPublish() method from a workflow Expression robot after the drawing is released.

A listener written to listen for drawing's state change to release could also be used to fire off the doPublish() method.

Config Spec Conundrum - How do I publish 'As Released'?

Config Spec Conundrum - How do I publish 'As Released'?