In a previous post, I discussed what I do to reduce the impact of publishing job failures. Since then, I have implemented another custom scheduled publishing job to further reduce the impact. As an attachment to this post, I have included the code required to add this new custom job as a selection in the WVS Job Scheduler Administrator. I added additional code to the files included in PTC article CS211115, so the directions included in the article for deploying can be followed. This addition creates a job called Republish_EPMDoc_WithFilters_OldReps as shown below.
Unless you have changed the OOTB behavior, when the state of an EPMDoc is changed, it is sent back to republish existing representations. It does this to ensure that the representation's state attribute is current. EPMDocs aren't iterated when the state is changed, so existing representations for the version could then be out of date if not republished. As an example of the problems this could cause, if you include the state in a drawing title block and the drawing isn't republished after the state changes, the old state will be displayed in the title block. It's important to note that this applies to any representation, including those created with the as-stored configuration.
The purpose of this new job is to catch all EPMDoc publishing failures that occur after the state changes. When the job runs, the last modified date/time of the existing default representation is checked against the date/time of the most recent state change. If the representation is older than the most recent state change, it is sent back to publishing.
I scheduled this job to run every hour along with the other recurring job I discussed in this previous post. I run this job more frequently because I know that the EPMDoc has already successfully published. This query only finds EPMDocs that have an existing default representation.
With these two recurring jobs, I don't have to worry about failures. They're cleaned up with a third scheduled job that deletes any left in the publishing queues. I only consider EPMDocs that were modified over the last day, so the query is quick and only a small number of new jobs are submitted back to publishing. Like I said before, my first-time success rate is over 98%, so there's never many jobs to resubmit. If you have a low success rate, you should first spend some time correcting any problems you may have before creating these recurring scheduled jobs.
As always, use my code at your own risk, and test before implementing in production.
.
