July 16th, 2018
Loan Payment Batch Processing
Last month I wrote about general improvements in Batch processing. In this edition of Raj’s Corner, I’ll stay on the Batch Processing topic and provide tips specific to CLS’s most critical batch processing job – the Loan Payment Transactions (LPT) Creation Job.

The Loan Payment Transactions (LPT) Creation Job processes contracts that have automated payments configured to create and clear payment transaction records.  Most customers schedule this job at least once a day resulting in thousands of payment transactions created daily.  Given the critical nature of this batch job, fault-tolerance and on-time completion of this job is extremely important.  The following 3 configuration tips will assist in making sure that the process completely successfully.

  1. Defining Custom Batch Size for LPT Creation Job: Post Vela release, customers can define a different batch size than the batch size used for other batch jobs. This setting will help optimize the size of the batch to eliminate failure due to Salesforce limits. It will prevent errors such as “CPU time limit exceeded.” In order to utilize this setting, Customers are required to create a custom field to define the batch size specific to the LPT Creation job.  More details are available at in this Support Center article.
  2. Fault-Tolerance in Processing Loan Payment batches:  Prior to the Lynx release, one payment failure within a larger batch of payments would cause the all payments to fail. In the Lynx release, a feature has been added to ensure that failure in one record only results in the failure of that particular payment. The rest of the payments in the batch will continue to be processed.  If you want to enable this behavior, check the “Enable Fault Tolerant Batch Processing” flag in the “Org Parameters” Custom Settings.
  3. Splitting of LPT Creation and Clearing actions: When you are creating a large number of ACH files, it is useful to split the clearing of the payment from the payment creation.  This improves the time needed to create the LPTs since it is not dependent on the clearing process.   For larger volumes, it is recommended to schedule the LPT Clearing job every 2 to 4 hours in cases where borrower payments originate from various online payment modes. Scheduling the Clearing job multiple times in a day will minimize load on the LPT Clearing job which executes after the LPT creation job.

 

June 15th, 2018
Running Batch Jobs – Then and Now
From Raj – our Technical Architect, Services: Dear Customers – During my interactions with you, I often come across common questions and requests. I look forward to providing you tips and insights that will improve the operational efficiencies of your business! I’ll begin our series with information on the faster, more fault-tolerant Batch Jobs in CLS products.

Let’s first see what Batch Jobs mean from Salesforce’s perspective. You can write code in Salesforce’s Apex language to process a set of records asynchronously in batches. This is the best solution if you have a need to process a lot of records periodically (e.g. process all Active CL Contracts daily).

CLS Batch Jobs: CLS Batch Jobs execute a series of programs on an application or a contract without any manual intervention. These jobs are set up such that they can be run on predefined schedules or can be triggered on occurrence of specific events.
In CL Loan, the Start of Day (SOD), End of Day (EOD), and Loan Payments Processing are some of the key batch jobs that include sets of jobs for processing transactions, creating reports and performing tasks for starting and closing a financial business day. Some of the batch jobs included in the SOD and EOD jobs can also be run independently on an ad-hoc basis.

Over the course of various releases CLS has made significant improvements in Batch Job processing in terms of speed, error logging, and making various jobs fault-tolerant. By upgrading to CLS’s latest release you will get the following benefits:

  1. Parallel Processing of SOD Jobs:
  • For customers with versions greater than 2.2003 (Vela release), I highly recommend using this feature. The customers who have implemented this feature have seen the SOD batch jobs run 40% to 70% faster.
  • CL Loan leverages Salesforce’s permissible limit for running concurrent SOD batch jobs. You can configure the org parameter ‘Concurrent Batch Jobs‘ to run up to five parallel instances of the SOD job.
  • The migration script ‘AssignThreadToLoanContracts’ assigns thread numbers ranging from 1 to the number set in the Concurrent Batch Jobs custom setting to all the existing contracts. This occurs when you upgrade to or install CL Loan 2.5000 or later version. For every new contract, a thread number is automatically assigned and is split for processing based on their thread number.
  1. Optimization in Batch processing:Post Hydra release, most of the batch jobs have been made intelligent to filter contracts that they would process based on certain statuses and field values. For example, the fees processing batch job is run only if “Active-Bad Standing” contracts exist for that day. Another example is Batch Jobs being 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.
  2. Immediate Start of Next Day:Pre Vela release, if any batch job in the SOD chain failed, the date would not have moved to the next day. This would have caused the business to halt causing a Severity 1 situation. Post Vela release, when the End of Day job finishes, it immediately updates the system date to the next day. This eliminates the possibility of the financial day being stuck at previous date due to failure of any job chained in the SOD execution.
  3. Fault-Tolerance in Processing Loan Payment batches: Pre Lynx release, when multiple payments were processed in a batch, if one payment failed the whole batch failed resulting in none of the payments in the batch being processed. It is required that a failure of one record does not result in all records in that batch to remain unprocessed. Post Lynx release, a feature has been added to ensure that failure in one record only results in the failure of that particular payment. The rest of the payments in the batch will continue to be processed. To enable this feature, the “Enable Fault Tolerant Batch Processing” flag must be checked in the ‘Org Parameters’ settings.
  4. Improvised Error Logging in SOD Jobs:Post Vela release, 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 EOD, SOD, Change Interest Rate, Interest Posting, Billing and Delinquency Processing batch jobs.

In addition to the above, there are several batch jobs that can be run as standalone. The CLS Support website has a library of knowledge notes that gives you specific instructions on:

  • Scripts to run the batch job in stand-alone mode in Developer’s console.
  • Parameter definitions for specific batch jobs.
  • Specific failure cases and how to generate error logs for them. For example, if a bill was due today and the BillingJob did not generate it.

I look forward to sharing additional insights in the next newsletter. 

 

For more information, ask a question or to request a demo, contact us.
Please Complete All Fields