Considerations for developing a custom work queue

Before you develop the Gosu code for your custom work queue, you need to decide which of the following you want to use for your work queue table:

A StandardWorkItem entity type
A custom work item type

The following reasons outline why you would want to define a custom work item type:

Include custom fields on work items not available on the StandardWorkItem entity type
Avoid table contention with other work queues that typically process large batches at the same time

Whenever you define a custom work item type, you must implement the createWorkItem method that your custom work queue inherits from WorkQueueBase.

If you create a custom work queue, your writer can pass more fields to the workers than a target field. On StandardWorkItem, the Target field is an object reference to an entity instance, which represents the unit of work for the workers. In a custom work item, you can define as many fields as you want to pass to the workers. Your custom work item itself can be the unit of work.

Guidewire recommends that you use custom work queue types for work queues with typically large batches that potentially run at the same time as other work queues with large batches. Especially if developing a custom work queue for night-time processing, consider using a custom work queue subtype instead of using StandardWorkItem. If you create a custom work item subtype to avoid table contention, you often define a single field for the writer to set, much like the Target field on StandardWorkItem. By convention, you name the single field with the same name as the entity type, not the generic name Target.

Important: Do not create multiple work queues that use the same work item type other than the StandardWorkItem type. If you attempt to do so, PolicyCenter throws an error.

Linking custom work items to target entities

In creating a custom work item, you need to create a link from the custom work item table to the entity table that is the target of the work item. To create this link, add a column element to your custom work item and use the following parameters.

Name	Value
name	`Target`
type	`softentityreference`
nullok	`false`

For Target, enter the name of the entity on which the work items acts. Use softentityreference (a soft link) rather than foreignkey (a hard link). A softentityreferece is a foreign key for which PolicyCenter does not enforce integrity constraints in the database. The use of a hard foreign key in this context would do the following:

Require that you delete the work item row from the database before you delete or archive the linked entity row.
Can force PolicyCenter to include the custom work item table in the main domain graph. It is not usually desirable to include such administrative entities in the domain graph for archiving along with the other data.

Keyable work item entities

Guidewire recommends that you define your custom work item entities as keyable, rather than retireable. If you define a custom work item as retireable, then you also need to create a custom batch process to purge the work items after PolicyCenter processes them and they become old and stale. This batch process also needs to clean up failed work items as well. Any delay in purging failed or stale work items can prevent further operations such as archiving.