Introduction

Are you new to Windchill Visualization?  Would you like WVS Jobs to be processed more efficiently or to just have more control over how they are processed?  This blog will cover the fundamental concepts behind WVS Job Processing and how WVS utilizes Windchill Processing Queues to achieve this.  In addition, I have included links to key Technical Support knowledge base articles for your reference.

The primary TS knowledge article CS149619 - How Windchill Visualization Services uses Windchill Queues for processing WVS Jobs.

WVS Jobs

Since Windchill 10.0 there are three types of WVS Jobs:

• Publish Jobs - Traditional WVS Publishing
• Clash Jobs - Batch Interference Detection
• Print Jobs - Batch Printing

All three WVS Job types are managed and processed using Windchill Processing Queues but WVS utilises these in a unique way.

WVS Queues and Job Processing

At start-up, for Publish Jobs, WVS creates three Prioritized ‘Waiting Queues for High, Medium and Low priority jobs, and a single Numbered ‘Processing’ Queue where the work is actually done.  These together are referred to as the default (unnamed) WVS Queue Set.  WVS also creates similar Queue Sets for processing Clash and Print Jobs but including the respective queue set names, CLASH and PRINT, i.e.:

An Administrator can optionally then create additional Numbered ‘Processing’ Queues to which WVS will attempt to distribute the entries from the Prioritized ‘Waiting’ Queues equally, thereby spreading the publishing load across multiple queues in parallel.  Although, if publishing large numbers of small and quick publish jobs (simple parts), only the lower queue numbers will be loaded (Refer to TS knowledge article CS42096).

WVS processes each logical WVS Job using a combination of two physical Windchill Processing Queue Entries:

• A Prioritized ‘Waiting’ Queue Entry - Target Method queueJob
• A Numbered ‘Processing’ Queue Entry - Target Method doJob

Note: Clash and Print Jobs do not currently support all the capabilities that are supported for Publish Jobs; for example, Clash and Print Jobs cannot be processed in Dedicated Publisher Queue Set or using Dedicated Workers (see below).

WVS Job Related Queue Entry Processing

The following shows a conceptual diagram of the traditional WVS Publisher Queue mechanism in the context of the overall WVS architecture:

WVS adds queue entries (that execute the queueJob method) for each newly submitted Publish Job to the relevant Prioritized ‘Waiting’ Queue, based on the type of the content to be processed and source of the request.  The mapped priorities for the type and source combinations can be configured using property settings in the wvs.properties file (refer to TS knowledge base article CS28472).

Note: Similar settings are available for prioritizing Print and Clash Jobs (refer to the wvs.properties.xconf file alongside wvs.properties).

All Windchill processing queues are FIFO (First in First Out) queues.  Queue Entries initially have a READY state when they are created, EXECUTING state when they are being processed and COMPLETED state once processing completed successfully.  Since Windchill 10.0, the NONEVENTFAILED state is used when processing completed but unsuccessfully; the Windchill Queue Entry states COMPLETED and NONEVENTFAILED now map to the WVS Job completion states JOB SUCCESSFUL and JOB FAILED respectively. Refer to TS knowledge article CS37569 for details of the different Windchill Queue Entry states and how to manage the related queue entries.

Queue Entries in the WVS Prioritized ‘Waiting’ Queues are processed one-at-a-time, so there should only ever be one EXECUTING entry in each queue and the rest waiting in the READY state.  All entries in the High priority queue are processed before those in the Medium and all those in the Medium priority queue before those in the Low.  An EXECUTING ‘Waiting’ Queue Entry (queueJob) is simply looking for an idle Numbered ‘Processing’ Queue that has no READY or EXECUTING entries.  When it finds one, it creates a new ‘Processing’ Queue Entry (doJob) within it, initially in a READY state.  The related ‘Waiting’ Queue Entry is then COMPLETED and is automatically removed by the Windchill Queue Service.

Note: Out-of-the-box, this process is repeated every 5 seconds for all ‘Waiting’ Queues in every defined WVS Queue Set, based on the value of the publish.publishqueuepollinterval property in wvs.properties.

Queue Entries in the WVS Numbered ‘Processing’ Queues are also processed one-at-a-time, so there should only ever be one EXECUTING entry in each queue and the rest already processed in the COMPLETED state.  An EXECUTING Queue Entry (that executes the doJob method) will identify and execute the Document Publisher (for WTDocuments) or the respective CAD Publisher (for EPMDocuments) configured using the Authoring Application specific CadConvert properties in wvs.properties, e.g. for Creo Parametric, with an internal Authoring Application of PROE, the publisher class defined by the publish.cadconvert.PROE property is used.  It is the Publisher that controls the execution of the publishing process for its respective CAD application data type.

Upon successful completion of publishing, the ‘Processing’ Queue Entry state is set to COMPLETED and depending on the Numbered ‘Processing’ Queue name and the value of the respective wt.queue.removeCompleted.<QueueName> property in wt.properties, will automatically keep or remove it (refer to TS knowledge base article CS32811).  After publishing is complete, the Publish Job Details log is added to a BLOB data column in the COMPLETED queue entry, so removing the queue entry also removes the logging.  At Windchill 10.0 the new state NONEVENTFAILED was added so that completed unsuccessful Publish Jobs are not automatically deleted by this mechanism.

WVS Dedicated Publisher Queue Sets and Workers Sets

Since Windchill 9.1 M010, WVS has also supported the concept of Dedicated Publisher Queue Sets.  The purpose of this capability is to extend the ability to manage and control specific categories of Publish Jobs using a completely separate and dedicated publisher queue set.  For example, to separate the publishing of Parts, Assemblies and Drawings, or to separate publishing of different CAD authoring application content, so that all the Numbered ‘Processing’ Queues in each dedicated publisher queue set can be dedicated to optimally loading the CAD workers for the same application. These Dedicated Publisher Queue Sets can also be combined with Dedicated Worker Sets for even greater control over which workers should process Publish Jobs from specific Publisher Queue Sets.

For a detailed example configuration, including sample filter code, refer to TS knowledge article CS132318 - Windchill PDMLink 10.0: An example of how to configure WVS Dedicated Publisher Queues and/or Workers to process Publish Jobs based on custom criteria.

I hope you find the information in my blog post interesting and of use.  As always, your comments and feedback are very welcome.