Enable the Storage Optimization Configuration

  • Updated

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.

Caution:

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 Important Instructions before Enabling this Configuration.

To enable this configuration, you must perform the following steps in the following order:

  1. Define the Big Object Storage Configuration

  2. Run the migration jobs if you are upgrading

  3. Add the ScheduleExtractionDynamicJob and RetryRepaymentScheduleBOOperationsJob

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.

Note:

A minimum of six months of the future schedules must be stored in the sObject.

Caution:

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

  1. Log in to your Salesforce account.

  2. Go to Setup > Setup .

  3. In the Quick Find search box, search for Custom Settings and then select it.

  4. On the Custom Settings page, search for Big Object Storage Config.

  5. Select Manage for the Big Object Storage Config.

  6. 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

    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 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 The 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 The ScheduleExtractionDynamicJob.

  7. Select Save.

    This enables the optimization of storage taken by amortization schedules.

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:

  1. 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.

  2. 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

  3. 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.

  4. 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

  5. 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.

  6. 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

  7. 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.

  8. 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.)

Note:

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

Note:

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:

  1. Create a Job/Add a new Job (DAG-enabled Job) to the DAG section

  2. 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.

Note:

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.

Go back to

In This Article