No publish on state change

[mspencer]

We have a problem where objects are no longer getting republished on state changes.  We are using promotion requests to advance to state of our objects, and a republish event to update a lifecycle state attribute in our drawing formats. This used to work flawlessly but at some point broke...we just noticed last week.  We see a publish event occurring during checkin, but not on state changes.

Our wvs.properties has these settings:

publish.republishonepmdocumentchange=true

publish.service.readytopublish.enabled=true

The objects are not listed in the publish.usesPublishRules criteria, as I am fine with a default publish to keep things simple for now.  I am seeing the following coming through on the background MS.  Seems it is determining NOT to republish it.

2016-04-14 14:27:07,264 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.StandardPublishService Administrator - process update for STATE_CHANGE/REASSIGN multi-object

2016-04-14 14:27:07,264 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.StandardPublishService Administrator -

updateMap size = 0

2016-04-14 14:27:07,264 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.StandardPublishService Administrator - republishMap size = 1

2016-04-14 14:27:07,264 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.StandardPublishService Administrator - publishList size = 0

2016-04-14 14:27:07,279 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.Publish Administrator - republishRepresentationsOf: Processing Representations for wt.epm.EPMDocument:52970123

2016-04-14 14:27:07,279 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.Publish Administrator - Derived From Reference: wt.epm.EPMDocument:52968575 does not refer to representable: wt.epm.EPMDocument:52970123 and will NOT be republished.

2016-04-14 14:27:07,889 DEBUG [WfUserWorkQueue.PoolQueueThread-19] wt.wvs.publish.StandardPublishService Administrator - process update for STATE_CHANGE/REASSIGN multi-object

2016-04-14 14:27:07,889 DEBUG [WfUserWorkQueue.PoolQueueThread-19] wt.wvs.publish.StandardPublishService Administrator -

updateMap size = 0

2016-04-14 14:27:07,889 DEBUG [WfUserWorkQueue.PoolQueueThread-19] wt.wvs.publish.StandardPublishService Administrator - republishMap size = 0

2016-04-14 14:27:07,889 DEBUG [WfUserWorkQueue.PoolQueueThread-19] wt.wvs.publish.StandardPublishService Administrator - publishList size = 0

Any advice what I am missing?  Thanks, Max

[TomU]

This line is really intriguing:

2016-04-14 14:27:07,279 DEBUG [WfPropagationQueue.PoolQueueThread-75] wt.wvs.publish.Publish Administrator - Derived From Reference: wt.epm.EPMDocument:52968575 does not refer to representable: wt.epm.EPMDocument:52970123 and will NOT be republished.

How was the existing representation created?  When you look on the content tab, what does the representation show that it was derived from?

[mspencer]

Existing rep was created by clicking on the representation area on the details page.  This causes a publishing job and makes the default representation.

The representation was created on the object before it was revised.  Hence it says the representation is copied from J.1, where the current version is K.1.

[TomU · Accepted solution]

Ah, that makes sense.  I have our system set to not copy forward on revise.  I'm thinking this might be part of the root problem.  Since this representation doesn't see itself as derived from this object, it doesn't see a need to republish.  I'll bet if you were to delete the copied forward representation and create a new one, it will correctly republish on state change.

I'm not sure how the republishing process deals with copied forward representations.  You might want to take a look at the "mark out of date" functionality.

[mspencer]

Thanks Tom!

I think you are correct.  I tested today with deleting the copied forward representation and manually making a new one.  With a new default representation made from the current revision, the republish events are triggered perfectly during the state changes from the promotion request.  Great...so now I move on the solving the details of teh copy forward problem.

If a copied forward representation is not seen as connected to the revised object, why is a 'new' publish event not triggered for the object?  I guess this isn't clear to me.  Seems like the system should generate a publish event for it?

[TomU]

I guess I'm still not clear how the representation was copied forward to the L.1 version. (assuming the revise to L created L.0)  When you revise an object, does it go to *.0 or *.1?

If the first "L" version is L.0, then I don't understand how (or why) the representation was copied forward from L.0 to L.1

If the first "L" version is actually L.1, then I don't really see why it matters.  Due to how Windchill revises things, the first version after any revise is basically useless.  It's no different from the last version of the previous revision (hence the representation copy forward functionality).  You would never release an object after revise until you made some change to it, and therefore an new version.

What am I missing here???

[mspencer]

The first version after a revise is L.1. 

One case where we might want to revise a publish a L.1 version of a CAD part is if we are revising a record to add/delete/or correct data on the WTPart description.  Hence we would revise all (WTPart, CAD Part, CAD Drawing), update the WTPart data, then put all on a promotion request.  No change to the CAD data, but I need them to republish during the promote events to get the latest revision letters on the drawing blocks.