Custom batch process overview

Custom batch processes are Gosu classes that extend the BatchProcessBase base class. The BatchProcessBase base class includes code that PolicyCenter uses to manage the processing of your custom batch process class.

Note: Custom batch processes are not substitutes for shell scripts or batch files. Do not attempt to automate a batch of system commands by developing custom batch processes.

You extend the BatchProcessBase base class by providing your own implementation of the doWork abstract method that BatchProcessBase inherits from its super class, SinglePhaseBatchProcess.

Custom batch processes are inherently single threaded. Do not attempt to improve the throughput of units of work by spawning threads from within your doWork method. In particular, the inherited methods incrementOperationsCompleted and incrementOperationsFailed are not thread-safe. Entity instances in transactional bundles on separate threads can cause problems.

Important: If your type of batch process requires processing units of work in parallel to achieve sufficient throughput, develop a custom work queue instead of a custom batch process.
Warning: Do not implement multi-threaded programming in custom batch processes derived from BatchProcessBase.

Custom batch processes, bundles, and users

Most likely, any custom batch process that you create needs to create, delete, or modify one or more business objects. Your batch process class must create a new bundle to perform this work. If you do not explicitly associate a user with the bundle, PolicyCenter uses a default user for bundle creation and commit.

Do not use the Guidewire sys user (System User), or any other default user, for this purpose. Instead, create your own application system user and limit the permissions assigned to that user to what is appropriate to successfully perform the necessary operation. You then use the following syntax to create a bundle with a specific user.
gw.transaction.Transaction.runWithNewBundle(\ bundle -> BLOCK_BODY, user)