Purge worker

The Purge worker picks up a job from the Purge work queue and purges or prunes jobs that meet the criteria. The following flow chart shows how the purge worker processes the job. Any job that emerges from step 7 will be considered for purging by the batch process on or after the NextPurgeCheckDate.

The numbered items in the flow chart are described below.

1. In this step, the job is evaluated according to the following criteria:

   Condition	Configurable in Purge plugin?	Configurable in config.xml?
   Is the PurgeStatus not equal to NoActionRequired?
   On the policy period that is the SelectedVersion, is the Status not bound, making the job a candidate for purging?
   Does the job have more than one policy period, making the job a candidate for pruning?

   Then the worker updates the PurgeStatus.

2. This decision point evaluates whether the job and all of its policy periods can be purged. A job can be purged if all of the following apply:

   Condition	Configurable in Purge plugin?	Configurable in config.xml?
   The policy is not bound.
   The job subtype is a subtype for purging. Calls the AllowedJobSubtypesForPurging getter in the PurgePlugin plugin interface.	•
   The DoNotDestroy flag is set to false on the policy and all policy periods on the job.
   The purge date returned by the getPurgeJobDate method is less than or equal to the current date. The purge date is calculated by comparing the job close and policy end dates with configuration parameters. For more information, see Quote purging configuration parameters. Calls the getPurgeJobDate method in the PurgePlugin plugin interface.	•	•
   The job has no open activities.
   The job has no archived policy periods.
   There are no workflows on any policy period in the job. For information about a process that purges workflows, see About purging activity-related workflow data.

3. In this step, the purger purges the job in two separate bundles:
   1. The first bundle calls the createContext and prepareForPurge methods in the PurgePlugin plugin interface.

      For each policy period in the job, the purger calls the skipPolicyPeriodForPurge method in the PurgePlugin plugin interface. This bundle then purges the job and the related objects.

   2. The second bundle calls the postPurge method in the PurgePlugin plugin interface.
      Important: Guidewire recommends that you put business critical operations in the prepareForPurge method so that the first bundle does the purge and business critical operations. Do not put business critical operations in the second bundle. If by chance the system fails while the purger is processing the job, the second bundle may not occur. If the first bundle does not complete, the bundle transaction consisting of the prepareForPurge and the purge-from-database action is rolled back. The job will be again be a candidate for purging or pruning the next time the batch process picks it up.
4. This decision point evaluates whether the policy periods on a job can be pruned. The policy periods on a job can be pruned if all of the following apply:

   Condition	Configurable in Purge plugin?	Configurable in config.xml?
   The job subtype is a subtype for pruning. Calls the AllowedJobSubtypesForPruning getter in the PurgePlugin plugin interface.	•
   The prune date returned by the getPruneJobDate method is less than or equal to the current date. The prune date is calculated by comparing the job close and policy end dates with configuration parameters. For more information, see Quote purging configuration parameters. Calls the getPruneJobDate method in the PurgePlugin plugin interface.	•	•
   The job has no open activities.
   The job has no archived policy periods.

   If the previous conditions are met, then each individual policy period is evaluated for pruning. The policy period is sent to the purger if the following apply:

   Condition	Configurable in Purge plugin?	Configurable in config.xml?
   The policy period is not bound.
   The DoNotDestroy flag is set to false on the policy period.
   There are no workflows on the policy period.

5. In this step, the purger prunes policy periods on the job in two separate bundles:
   1. The first bundle calls the prepareForPurge method in the PurgePlugin plugin interface.

      For each policy period in the job except the selected version, the purger calls the skipPolicyPeriodForPurge in the PurgePlugin plugin interface. This bundle then purges the policy periods and the related objects.

   2. The second bundle calls the postPurge method in the PurgePlugin plugin interface.
      Important: Guidewire recommends that you put business critical operations in the prepareForPurge method so that the first bundle does the purge and business critical operations. Do not put business critical operations in the second bundle. If by chance the system fails while the purger is processing the job, the second bundle may not occur. If the first bundle does not complete, the bundle transaction consisting of the prepareForPurge and the purge-from-database action is rolled back. The job will be again be a candidate for purging or pruning the next time the batch process picks it up.
6. This step updates the PurgeStatus to one of the following values:
   • NoActionRequired – This is the most common case. For example, PurgeStatus gets this value when the only remaining period is bound.
   • Pruned – When there is one and only one policy period version remaining.
   • Unknown – If the purge status is unknown. For example if a version that is not the selected version is marked DoNotDestroy, then pruning leaves that version as well as the selected version.
7. This step calculates the next purge check date. This step calls the calculateNextPurgeCheckDate method in the PurgePlugin plugin interface.

   When the batch process runs again, this job will be reevaluated for purging or pruning.