I've been doing administration for Windchill since 2008 when we implemented 9.0. Although it gets better and better with each new release, Windchill publishing, or WVS as they call it now, still has its problems. It's both amazing and frustrating at the same time - sound familiar Creo parametric users? It's time consuming to setup and tune, and troubleshooting is a difficult task. The word temperamental comes to mind. Currently, we get about a 98% success rate on first time publishing jobs. Most of our publishing is for Creo Parametric content but we have also configured dummy publishing for many wtDocs. After a manual retry, most of the jobs that failed on the first try publish successfully resulting in a 99%+ overall success rate. That sounds very good, but anything less than 100% requires some amount of babysitting. Since downstream processes depend on an up-to-date published representation being available at the right time, failed or delayed jobs can really throw a wrench in the works. I want to share some of my experiences with WVS and possibly help someone else. If not, at least I've documented it for my future reference. We're currently using Windchill version 10.2 with the latest Creo View Adapters, and some of what I discuss below might only apply to that version. It's important to keep your Adapters and CAD application up to date with the latest compatible release on the worker machines. I have found that as PTC releases maintenance updates to both, I almost always get better publishing results.
My current best strategy is to (1) configure as many workers as I have resources for, (2) reduce the number of publishing jobs and (3) implement a custom scheduled job to help with failures.
1. Having a ton of workers available for any jobs that might be submitted always bothered me because they sit idle a lot of the time, but without some clever resource sharing scheme, I don't see a way around that. See PTC article CS29308 configuring multiple workers on the same machine. Also, create about 1.5 times more queues than workers because some of the pre and post processing activity doesn't require a worker - see PTC TS Article CS43769.
2. The OOTB publishing is overkill in my opinion. I disabled the creation of Promotion Request related representations - see PTC TS Article CS38895. We use one as-stored default representation and don't have a need for all those "extra" representations. We do still publish on checkin, state change and all other OOTB situations. Limit publishing by using the publish.service.filterpublishmethod property discussed in PTC TS Article CS39455. Publish rules can also help limit publishing volume, see for example PTC TS Article CS115536. After using these methods to reduce the number of jobs, we have an average of 2,200 jobs per day including weekends. It's also a good idea to prioritize publishing per PTC TS Article CS28472.
3. The OOTB jobs available for scheduling via the WVS Job Scheduler Administrator have limited value. We migrated lots of legacy content into Windchill and some of it won't publish successfully due to problems beyond the control of WVS. I couldn't schedule a recurring job to publish all without existing rep (OOTB method PublishAllLatestEPMDocumentsNoRepresentation) without repeating hundreds of failures.
Then I saw PTC Article CS211115 which was recently added. I really liked the options this gave me. It includes an easy to follow example for adding some custom job methods. Jobs can be scheduled based on additional criteria, like lifecycle state, last modified date, version and number (with wildcard). I made a couple small additions to the code to better suit my situation. I added an option to publish EPMDocs modified in the last X number of days to the property file. My code and property file are attached to this post. What this allowed me to do was schedule a recurring job that only publishes latest version EPMDocs without a default representation from only the last day. It doesn't include all the legacy content with problems. I run this job every two hours to catch the recent jobs that fail. I even restricted it to drawings, since we are still a drawing driven business. I don't care as much about the models, which can be published on-demand anyway. After this recurring job was in place, I added a second daily recurring cleanup job to delete the failed jobs that accumulate (DeleteCompletedJobs). I was worried that the scheduled jobs might place a large burden on the db and publishing, but the db query completes in less than eight seconds and normally only a handful of results are found. The one problem with this is that it only publishes when the representation is missing. If it is out of date, due to a state change for example, it won't republish. I haven't figured out how to tie up that one loose end.
If my programming skills were better, I could probably come up with something to resubmit the failed jobs in the publishing queues automatically. I've always wanted to do it that way. From what I've read, a listener might be appropriate for this, but I'm not sure a publishing queue failure can be listened for. Also, resubmitting jobs blindly can cause problems, so I'm not sure if that's a good solution anyway.
No programming skills are required to implement everything I listed above. I didn't include all my configuration details, so if you have any questions, let me know.
I have also configured DFS publishing for our multi-master vault setup. I'll discuss how that works in an upcoming blog entry.
What are your experiences with WVS and how do you deal with publishing job failures?