Batch jobs
Batch Jobs execute a series of programs on an application without any manual intervention. These jobs are set up such that they can be run on predefined schedules or be triggered on occurrence of specific events. Using the Batch Jobs page, you can define the time of the day when these jobs are to be run.
In CL Loan, the Start of Day (SOD), End of Day (EOD), and End of Month (EOM) are some of the key batch jobs that include a further set of jobs for processing transactions, creating reports and performing tasks for starting and closing a business day. Some of the batch jobs included in the SOD and EOD jobs can also be run independently on an ad-hoc basis. For detailed information on the batch jobs available in CL Loan, refer to section Definition of Batch Jobs.
Parallel Processing of SOD Jobs - CL Loan leverages Salesforce's permissible limit for running concurrent SOD batch jobs. You can configure the org parameters to run up to five parallel instances of the SOD job. The default and minimum value of this parameter is 1. For example, if this parameter is set to 5, five instances of the StartofDay job would run at the same time.
The migration script AssignThreadToLoanContracts assigns thread numbers ranging from 1 to the number set in Concurrent Batch Jobs custom setting, to all the existing contracts, when you upgrade to or install CL Loan 2.5000 or later version. For every new contract, a thread number is automatically assigned. The ProcessJobQueryUtil4 class splits the loan contracts based on their thread number.
Start of Next Day - When the End of Day job finishes, it updates the system date to the next day. Based on the thread number, the loan contracts are divided for parallel processing of SOD chaining jobs. The start of day (SOD) jobs run subsequent to this.
Customers upgrading to CL Loan 2.2003 need to set the value of the Concurrent Batch Jobs parameter.
In cases where the concurrent batch jobs are set at greater than 1, when the SOD job is run, the system performs the preliminary step of identifying all eligible contracts and grouping these into the specified number of batches for concurrent processing. Subsequently, the start of day batch jobs run and records are processed. Parallel processing helps users avoid reaching the Salesforce limit on number of records and minimizes job failure scenarios.
Batch Size for Daily Jobs -This parameter specifies the number of daily jobs that can be run in a batch. Default is 200, you can change the number.
Batch Size for Reschedule Jobs - This parameter specifies the number of reschedule jobs that can be run in a batch. Default is 20, you can change the number.
To define the number of batch jobs parameters:
- Go to Setup, App Setup, Develop, Custom Settings.
- Click on O, Org Parameters, Manage.
- Specify the value for the parameters.
- Click Save.
Record Filtering - The batch jobs use the values of certain fields on the loan contract to filter the records that need to be processed by the specific batch job. For example, the Interest Posting batch job filters contracts where the "Interest Posting Enabled" field is selected. Similarly, late fee processing must occur only if "Active-Bad Standing" contracts exist for a given day. Filtering out records not relevant to the job allows optimized batch processing.
Batch jobs are also run based on the loan product. For example, the job for broker payout must be run only for LOC contracts. Therefore, the job filters out contracts for other loan products and processes only LOC contracts.
Indexing of Fields - Indexing allows you to group related records at the database level. You can index specific fields of an object, to allow batch job queries to fetch the records from the database faster and with more ease. For example, assume that you have 50000 contracts and from these, you need to filter contracts that are in Active-Bad Standing status. If you have indexed the Loan Status field, then, within the database, contracts are grouped by loan status and the query can simply fetch the contracts with Active-Bad Standing status. Else, the query must check the loan status of each of the 50000 records to identify those in Active-Bad Standing status.
Customers deploying CL Loan 2.2003 must raise a service request with Salesforce to index any default or custom fields of CL Loan objects, with each service request including up to a maximum of three fields. This must be done individually for every object and org.
For example, if you operate two different orgs in the two geographies - Australia and Asia - and want to index 10 fields of the Account object, then, you must raise 4 service requests with Salesforce, grouping up to 3 fields in each service request, for Australia business org, and another 4 service request for the Asia org. Similarly, you must raise service requests for each object to be indexed.
Error Logging in SOD Jobs - For critical SOD jobs, any event that causes a batch to fail is logged to allow for easy identification of the failing record, and its correction and reprocessing. For example, if the Billing job fails, the error log identifies the loan account and the bill that caused the job to fail. You can review all errors in the Batch Process Logs. Failures and errors are logged for the following jobs:
End Of Day
Start Of Day
Change Interest Rate
Late Charge Creator
Interest Posting
Billing
Billing Loc
Billing Amz
Delinquency Processing
Late Charge Creation for Migrating Customers - For customers who are upgrading to CL Loan 2.2003, no late charges would be generated for the loans that would become delinquent on the migration date. This is because upon migration, the checkbox 'Unpaid Bills' that is added to the CL Contract page layout, is deselected. Users must run the migration script by scheduling the MarkUnPaidBillsAfterUpgrade job to mark it as selected for relevant contracts, before scheduling the SOD jobs, and before the late charge creation job runs.