Skip to main content
M
mspencer1-Visitor
1-Visitor
April 14, 2016
Solved

No publish on state change

  • April 14, 2016
  • 6 replies
  • 4068 views

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

Best answer by TomU

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.

6 replies

T
TomU23-Emerald IV
23-Emerald IV
April 14, 2016

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?

M
mspencer1-VisitorAuthor
1-Visitor
April 14, 2016

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.screenshot_1.png

T
TomU23-Emerald IVAnswer
23-Emerald IV
April 14, 2016

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.

    Terms & ConditionsAccessibility statement