Batch Process and work-queue:
[Link] process:
1. [Link] for the processing of a batch of items sequentially, one after the other.
2. 2.A batch process is a background process to perform an action without manual
intervention. When performing an action in UI it is configured in the batch process. It
will run on a scheduled times. Eg Financial esc batch. After creating a check every one
hr the batch will run, it will pick all the checks in Awaiting submission and changes it
to Requested state.
3. To access information about the Batch processing types, open the following files in
Studio:
[Link] – Provides the name and descriptions for each
processing type.
[Link] – Provides the schedule time of the batch process which
is Schedulable.
How can we configure a batch process / Steps to implement a new batch process:
1. Add the typecode in Batchprocesstype typelist. Configure it based on
batchprocesstype usage(whether as UI runnable or schedulable)
2. Create a new class under the package(erieinsurance/batch)
3. Create the new class on the newly added batch process type as highlighted above
4. dowork() is the main class of the batch process class that includes our custom logic of
the process.
5. Once the class logic is written , call this class in the processplugin class under
Createbatchprocess() method which calls the customized batch process or GW ootb
batch process based on the process type.
6. Schedule this bath process in [Link].
Run a writer or batch process from the command prompt
Start a process using a maintenance_tools command option.
1. Open a command prompt.
2. Navigate to the following location:
o admin/bin
3. Run the following command:
o maintenance_tools -password password -startprocess process
For the process value, specify a valid process code.
Work-Queue:
Provides for the processing of a batch of items in parallel, in a distributed manner.
[Link] – Provides the name of the backing class and number of work
instances for a processing type.
A work queue comprises the following components.
Work queue
A work queue is a database table that holds work items for processing. Guidewire
work queues share the standard work item table: StandardWorkQueue
(bc_standardworkqueue).
Writer
A writer thread does the following:
It selects units of work for processing.
It writes the identities of the work items to a work queue table.
It notifies the workers that there are work items to process.
Worker
A worker retrieves or more work items from the work queue and processes the work
items to completion. A worker only processes work items from its associated writer.
By default, each work queue starts a single worker on each cluster member with
the workqueue role, unless configured otherwise.
Executor
The work queue executor manages the worker tasks on each application server in
a cluster. If a work queue has no more remaining items to process, the executor shuts
down all worker on a server node except for one, which periodically checks to see if
there is new work to perform.
Starting the writer initiates a run of processing on a work queue. The work is complete if the
workers exhaust the queue of all work items, except those that they failed to process
successfully.
[Link] has the below properties:
Work queues provide a way to distribute load for processing-intensive tasks across multiple
servers or instances within a server.
For each workqueue, you may declare as many worker instances as you
wish, specifying for each one what server and environment (e.g. dev, test, prod)
it should run on. If no worker is specified for a queue no instance
will be started. If a worker element has no server attributes specified
the defaultServer attribute will be used (i.e. the specified number of workers
will be started on every server matches the defaultServer).
Worker definitions include a number of parameters designed to tune
latency and load characteristics. When a new workitem is added to the
queue, a notification is broadcast to all servers in the cluster, and
workers wake up to compete for the workitem.
By setting maxpollinterval (default 60,000 milliseconds) you can define
how often workers wake up automatically, even if no notification is
received. This default may not be appropriate for large numbers of
workers and may need to be increased to prevent excessive numbers of
queries for workitems.
The batchsize attribute to a worker controls how many workitems it will
attempt to check out when searching for more workitems. Larger batchsizes
are more efficient, but may not result in good load distribution.
Default is 10.
The workqueue defines a progressinterval attribute, which is used
to recover from error situations. Any workitems checked out
longer than this interval will be assumed to have been failed or
dropped by a crashing server, and will be reassigned to a new
worker instance. It is important that this interval be much
larger than the normal time required to process a workitem.
The retryLimit attribute on the workqueue element specifies how
many times a failing work item must be retried before being marked as failed
(default value is specified in the WorkItemRetryLimit config parameter).
The retryInterval specifies how many miliseconds to wait before
retrying a work item (default is 0).