Enable the Storage Optimization Configuration
Overview
If you want to optimize the storage of the amortization schedules in your org, you must enable the storage optimization configuration in your system.
You must not enable this configuration without the Q2 Loan Servicing product team's knowledge as this may require reimplementation of the code if you have any customizations.
Once you enable this storage optimization, you cannot disable it later.
Therefore, before you enable it, please consult our product team.
For more details on the things to keep in mind before enabling, refer to the Important Instructions before Enabling this Configuration.
For more information on this feature, see the Amortization Schedules Storage Optimization Overview section of the Q2 Loan Servicing User Guide for Simple Loans.
To enable this configuration, you must perform the following steps in the following order:
Define the Big Object Storage Configuration
To enable, you must first define the big object storage configuration by defining the number of months for which the schedules must be stored in the big object to save storage space.
You can, thus, see and store only the required number of schedules in the Salesforce sObject.
A minimum of six months of the future schedules must be stored in the sObject.
This is a one time configuration that you must do to enable the storage optimization for the amortization schedules. Once you have configured, you cannot change this configuration.
Prerequisites
Before you enable this optimization configuration, please give a good read to Important Instructions before Enabling this Configuration.
Steps
Log in to your Salesforce account.
Go to Setup > Setup .
In the Quick Find search box, search for Custom Settings and then select it.
On the Custom Settings page, search for Big Object Storage Config.
Select Manage for the Big Object Storage Config.
-
Provide the values as highlighted in the following image and explained in the table following this image:
Field Action and Description Store Schedules After Fixed Period Of Specify the period in terms of a number that represents the number of upcoming months falling in the schedules after which the schedules must be stored in the big object.
Here, the period can only be in terms of months.
When you specify a number in this parameter, you are asking the system to store only those upcoming schedules in the sObject that fall in these many number of months and the rest of the future schedules in big object.
For example, if you set the value of this parameter to 12, then the system will only store those upcoming schedules in the sObject that fall within these upcoming 12 months. The schedules after 12 months are stored in the big object, or if they are already present in the sObject, then they are moved to the big object by the ScheduleExtractionDynamicJob. Thus, if the payment frequency is monthly, you can see only 12 upcoming schedules on the Repayment Schedule tab on the UI
Note:For more information on ScheduleExtractionDynamicJob, see the The ScheduleExtractionDynamicJob section of the Q2 Loan Servicing User Guide for Simple Loans.
The default and the minimum value of this parameter is 6. (for weekly and monthly) For example, even if you specify 4, the system still considers 6.
If you have quarterly payment frequency loans in your portfolio, then it is recommended that you set the value of Store Schedules After Fixed Period Of parameter to 12. This is because for a quarterly payment frequency, to have minimum 3 schedules in future to show, schedules up to 12 months need to be available.
To understand this, let us say there is a quarterly payment frequency loan that was created on January 1. In this case, the schedules would fall on April 1, July 1, Oct 1, Nov 1 and so on. If the configuration for future schedules to show (Store Schedules After Fixed Period Of parameter) is given as 6 (6 is minimum default number), then it means that the schedules falling in the next 6 months, would be April 1 and Jul 1 only. This means only 2 schedules in the future will be shown, but at least 3 are recommended for the product. To handle this, It is recommended that you set the value of Store Schedules After Fixed Period Of parameter to 12 if the portfolio consists of quarterly payment frequency loans.
The job of fetching and storing the schedules to and from the sObject and big object is done by the ScheduleExtractionDynamicJob.
Store Schedules Before Fixed Period Of Specify the period in terms of a number that would represent the number of months in the past before which the schedules must be stored in the big object.
Here, the period can only be in terms of months.
When you specify a number in this parameter, you are asking the system to store only those schedules of the past in the sObject that fall within these number of months, and only those will get displayed on the Repayment Schedule tab. The rest of the past schedules are stored in big object and are not displayed on the Repayment Schedule tab on the UI.
For example, if you set the value of this parameter to 6, then the system will only store those schedules in the sObject that fall in the six months in the past before the current schedule. The schedules prior to the six months are stored in the big object, or if they are already present in the sObject, then they are moved to the big object by ScheduleExtractionDynamicJob.
If the value of this parameter is null or blank, then it means that all the past schedules will be stored in sObject.
The job of fetching and storing the schedules is done by the ScheduleExtractionDynamicJob.
-
Select Save.
This enables the optimization of storage taken by amortization schedules.
For more information on ScheduleExtractionDynamicJob, see the The ScheduleExtractionDynamicJob section of the Q2 Loan Servicing User Guide for Simple Loans.
If you are upgrading from a previous version, run the migration jobs
Once you define the big object storage configuration in the preceding steps and if you are upgrading from a previous version to the August 2024 release, then you must run the following migration jobs individually to migrate the existing schedule records from sObject to big objects:
ScheduleBigObjectMigrationJob
InactiveScheduleBigObjectMigrationJob
This is done to improve the performance as inactive schedules are the major portion of the data that are to be migrated from sObject to big object.
To run the migration jobs individually, do the following:
For ScheduleBigObjectMigrationJob:
Perform the steps in the Create a DAG Schedule / Add a new DAG to the DAG Schedule section of the DAG Configuration for ScheduleBigObjectMigrationJob by giving a unique DAG name for this job.
-
Perform the steps in the Create a Job/Add a new Job to the DAG section of the DAG Configuration with the following values:
Batch Size = 1 (As the scope is the contracts)
Class = loan.ScheduleBigObjectMigrationJob
Label = ScheduleBigObjectMigrationJob
Perform the steps in the Create a Job Dependency/Establish a relationship between DAG and the Job section of the DAG Configuration to establish a relationship between the DAG created in the preceding step 1 and the DAG-enabled migration Job (ScheduleBigObjectMigrationJob) added in the preceding step 2.
-
Perform the steps in the Run a DAG Job> With the help of the CL Loan UI in Servicing Configuration section of the DAG Configuration to run ScheduleBigObjectMigrationJob in Servicing Configuration.
For InactiveScheduleBigObjectMigrationJob
Perform the steps in the Create a DAG Schedule / Add a new DAG to the DAG Schedule section of the DAG Configuration for InactiveScheduleBigObjectMigrationJob by giving a unique DAG name for this job.
-
Perform the steps in the Create a Job/Add a new Job to the DAG section of the DAG Configuration with the following values:
Batch Size = 1 (As the scope is the contracts)
Class = loan.InactiveScheduleBigObjectMigrationJob
Label = InactiveScheduleBigObjectMigrationJob
Perform the steps in the Create a Job Dependency/Establish a relationship between DAG and the Job section of the DAG Configuration to establish a relationship between the DAG created in the preceding step 5 and the DAG-enabled migration Job (InactiveScheduleBigObjectMigrationJob) added in the preceding step 6.
Perform the steps in the Run a DAG Job> With the help of the CL Loan UI in Servicing Configuration section of the DAG Configuration to run InactiveScheduleBigObjectMigrationJob in Servicing Configuration.
(These jobs can be run in the Developer Console, but it is recommended that you run using the DAG Configuration to maintain parallelization.)
For more information on DAG setup, DAG schedules, adding the jobs, and parallelization, go to:
Add the ScheduleExtractionDynamicJob and RetryRepaymentScheduleBOOperationsJob
Once you define the big object storage configuration and run the migration jobs (if you are upgrading), you must then add the following jobs to your default DAG so that they can run in the start of the day job chaining (SOD) or end of the day job chaining (EOD) as required:
ScheduleExtractionDynamicJob
RetryRepaymentScheduleBOOperationsJob
For more information on Default DAGs, go to Default DAGs section of the DAG Configuration.
To add the preceding two jobs to your Default DAG, go to the DAG schedule corresponding to your default DAG Name and then perform the steps in the following sections of the DAG Configuration in this order:
Create a Job/Add a new Job (DAG-enabled Job) to the DAG section
Create a Job Dependency/Establish a relationship between DAG and the Job section
The jobs will then run as part of the SOD or EOD as per the default DAG configuration.
If you do not have a default DAG for the start of the day or end of the day, then create one by performing the steps in Create a DAG Schedule / Add a new DAG to the DAG Schedule section of the DAG configuration.