1. Cloud Native System Administrator's Guide
  2. Basic System Administration of BRM Cloud Native
  3. Managing a BRM Cloud Native Multischema System

8 Managing a BRM Cloud Native Multischema System

Learn how to perform basic tasks, such as migrating accounts, adding schemas, or setting a schema's status, in an Oracle Communications Billing and Revenue Management (BRM) cloud native multischema system.

Topics in this document:

Running Billing Against a Specified Schema

You generate bills for your customers' accounts by running the pin_bill_accts utility through the brm-apps job. By default, the utility runs against all schemas in your database, but you can configure BRM cloud native to run the utility against a specific schema. For more information about generating bills, see "Billing Accounts By Using the pin_bill_accts Utility" in BRM Configuring and Running Billing.

To run billing against a particular database schema using the brm-apps job:

  1. In your override-values.yaml file for oc-cn-helm-chart, set these keys:

    • ocbrm.brm_apps.job.isEnabled: Set this to true.

    • ocbrm.brm_apps.job.isMultiSchema: Set this to false.

  2. Update the oc-cn-helm-chart/brmapps_scripts/loadme.sh script to run pin_bill_accts commands on the specified schema: 

    if [ "${DB_NUMBER}" = "0.0.0.x" ]; then
cd /oms/apps/pin_billd; pin_bill_accts –verbose
exit 0;

    where x is the schema number.

  3. Run the helm upgrade command to update your Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

    The pin_bill_accts utility generates bills for the accounts in the specified schema.

Adding Schemas to a Multischema System

To add one or more schemas to your existing BRM cloud native multischema system:

  1. Initialize the new secondary schemas in your BRM database.

    1. Open your override-values.yaml file for oc-cn-init-db-helm.

    2. Set the ocbrm.db.skipPrimary key to true.

    3. For each existing secondary schema in your system, set the ocbrm.db.multiSchemas.secondaryN.deploy key to false.

    4. For each new schema, add an ocbrm.db.multiSchemas.secondaryN block, where N is 3 for the third secondary schema, 4 for the next secondary schema, and so on.

    5. In the new ocbrm.db.multiSchemas.secondaryN block, set these keys:

      • deploy: Set this to true to deploy this secondary schema.

      • host: Set this to the hostname of the secondary schema. This key is optional.

      • port: Set this to the port number for the secondary schema. This key is optional.

      • service: Set this to the service name for the secondary schema. This key is optional.

      • schemauser: Set this to the schema user name.

      • schemapass: Set this to the schema password.

      • schematablespace: Set this to the name of the schema tablespace, such as pin01.

      • indextablespace: Set this to the name of the index tablespace, such as pinx01.

      This shows sample override-values.yaml entries for adding a third secondary schema to an existing multischema system. 

      ocbrm:
   isAmt: true
   db:
      skipPrimary: true
      multiSchemas:    
         secondary1:
            deploy: false
            schemauser: pin02    
            schemapass: password    
            schematablespace: pin02   
            indextablespace: pinx02
         secondary2:  
            deploy: false  
            schemauser: pin03   
            schemapass: password   
            schematablespace: pin03
            indextablespace: pinx03
         secondary3:  
            deploy: true  
            schemauser: pin04   
            schemapass: password   
            schematablespace: pin04
            indextablespace: pinx04

    6. Save and close your override-values.yaml file.

    7. Run the helm install command for oc-cn-init-db-helm-chart. 

      helm install InitDbReleaseName oc-cn-init-db-helm-chart --values OverrideValuesFile -n InitDbNameSpace

      where:

      • InitDbReleaseName is the release name for oc-cn-init-db-helm-chart and is used to track this installation instance.

      • OverrideValuesFile is the path to a YAML file that overrides the default configurations in the values.yaml file for oc-cn-init-db-helm-cart.

      • InitDbNameSpace is the namespace for oc-cn-init-db-helm-chart.

  2. Specify the details for connecting the BRM server to your new secondary schemas.

    1. Open your override-values.yaml file for oc-cn-helm-chart.

    2. Enable account migration by setting the ocbrm.isAmt key to true.

    3. Set the ocbrm.db.skipPrimary key to false.

    4. For each secondary schema you are adding to your system, add an ocbrm.db.multiSchemas.secondaryN block, where N is 3 for the third secondary schema, 4 for the next secondary schema, and so on.

    5. In each ocbrm.db.multiSchemas.secondaryN block, set the following keys:

      • deploy: Set this to true.

      • host: Set this to the hostname of the secondary schema. This key is optional.

      • port: Set this to the port number for the secondary schema. This key is optional.

      • service: Set this to the service name for the secondary schema. This key is optional.

      • schemauser: Set this to the schema user name.

      • schemapass: Set this to the schema password.

      • schematablespace: Set this to the name of the schema tablespace, such as pin01.

      • indextablespace: Set this to the name of the index tablespace, such as pinx01.

      This shows sample override-values.yaml entries for adding a third secondary schema to an existing multischema system. 

      ocbrm:
   isAmt: true
   db:
      skipPrimary: false
      multiSchemas:    
         secondary1:
            deploy: true
            schemauser: pin02    
            schemapass: password    
            schematablespace: pin02   
            indextablespace: pinx02
         secondary2:  
            deploy: true  
            schemauser: pin03   
            schemapass: password   
            schematablespace: pin03
            indextablespace: pinx03
         secondary3:  
            deploy: true  
            schemauser: pin04   
            schemapass: password   
            schematablespace: pin04
            indextablespace: pinx04

    6. Run the helm install command from the helmcharts directory: 

      helm install BrmReleaseName oc-cn-helm-chart --namespace BrmNameSpace --values OverrideValuesFile

      where:

      • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance. It must be different from the one used for oc-cn-init-db-helm-chart.

      • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

      • OverrideValuesFile is the path to a YAML file that overrides the default configurations in the values.yaml file for oc-cn-helm-chart.

      The BRM Helm chart deploys new dm-oracle, amt, and rel-dameon pods, Rated Event (RE) Loader PVCs, services, ConfigMaps, and secrets. It also updates their corresponding schema entries in the primary CM and Oracle DM and deploys multiple containers for the batch-wireless-pipe pod.

  3. Set each database schema's status and priority. BRM cloud native assigns accounts to an open schema with the highest priority.

    1. Open the configmap_pin_conf_testnap.yaml file.

    2. Under the config_dist.conf section, add the following entries for each new secondary schema: 

      DB_NO = "schema_number" ;             # database config. block
PRIORITY = priority ;
MAX_ACCOUNT_SIZE = 100000 ;
STATUS = "status" ;
SCHEMA_NAME = "pin111x" ;

    3. Set the STATUS and PRIORITY entries for each new secondary schema: 

      DB_NO = "0.0.0.1" ;             # Primary schema configuration block
PRIORITY = priority;
MAX_ACCOUNT_SIZE = 100000 ;
STATUS = "status" ;
SCHEMA_NAME = "pin112x" ;
  
DB_NO = "0.0.0.2" ;             # Secondary schema configuration block
PRIORITY = priority;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "status" ;
SCHEMA_NAME = "pin113x" ;

      where:

      • priority is a number representing the schema's priority, with the highest number having the most priority. For example, 5 indicates a greater priority than a value of 1. For more information, see "Modifying Database Schema Priorities".

      • status specifies whether the schema is open, closed, or unavailable. For more information, see "Modifying Database Schema Status".

    4. Set up the configurator job to run the load_config_dist utility by adding the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script: 

      #!/bin/sh
 
cp /oms/config_dist.conf /oms/sys/test/config_dist.conf
cd /oms/sys/test ; load_config_dist
exit 0;

    5. In the override-values.yaml file for oc-cn-helm-chart, set this key:

      ocbrm.config_jobs.run_apps: Set this to true.

    6. Run the helm upgrade command to update the Helm release: 

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      The distribution information is loaded into the primary schema.

    7. Update these keys in the override-values.yaml file for oc-cn-helm-chart:

      • ocbrm.config_jobs.restart_count: Increment the existing value by 1.

      • ocbrm.config_jobs.run_apps: Set this to false.

    8. Update the oc-cn-helm-chart release again: 

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      The CM is restarted.

  4. Reset BRM POID sequences as part of the brm-apps job.

    1. Add these lines to the oc-cn-helm-chart/brmapps_scripts/loadme.sh script: 

      #!/bin/sh 

java -cp $ORACLE_HOME/lib/ojdbc8.jar:$PIN_HOME/jars/pin_reset_seq.jar:$PIN_HOME/jars/pcm.jar:$PIN_HOME/jars/oraclepki.jar PinResetSeq /oms/pin_confs2/pin_reset_seq.properties 
exit 0;

    2. In your override-values.yaml file for oc-cn-helm-chart, set these keys:

      • ocbrm.brm_apps.job.isEnabled: Set this to true.

      • ocbrm.brm_apps.job.isMultiSchema: Set this to false.

    3. Update the oc-cn-helm-chart release: 

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

  5. Set up the configuration job to run the load_pin_uniqueness utility.

    See "Synchronizing the Database Schema /uniqueness Objects" in BRM System Administrator's Guide for more information about the utility.

    1. Add the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script: 

      #!/bin/sh 

cd /oms/sys/test ; load_pin_uniqueness
exit 0;

    2. In the override-values.yaml file for oc-cn-helm-chart, set this key:

      ocbrm.config_jobs.run_apps: Set this to true.

    3. Update the oc-cn-helm-chart release: 

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      The /uniqueness objects are synchronized between the schemas.

    4. Update these keys in the override-values.yaml file for oc-cn-helm-chart:

      • ocbrm.config_jobs.restart_count: Increment the existing value by 1.

      • ocbrm.config_jobs.run_apps: Set this to false.

    5. Update the oc-cn-helm-chart release again: 

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      The CM is restarted.

  6. Configure the account-router Pipeline Manager to route CDRs to pipelines based on the database schema POID. To do so, edit the ConfigMap file configmap_acc_router_reg.yaml.

    Based on the configuration, the account router Pipeline Manager does the following:

    • Moves input files to the data PVC directory. The input file names have a router prefix and an .edr suffix.

    • Moves the rated output files to the input of the Rating pipeline.

    • Replicates the Rating pipeline based on the multischema entry. The Range function is used to replicate the rating pipeline.

    • Moves the output files from the Rating pipeline to the outputcdr PVC directory.

Migrating Accounts from One Schema to Another

You migrate accounts from one schema to another in the same database by configuring the account search configuration file and then running the pin_amt utility through the brm-apps job. For more information, see "Understanding Account Migration" in BRM Moving Accounts between Database Schemas.

To migrate accounts from one schema to another:

  1. Enable Account Migration Manager in your BRM database by setting the ocbrm.isAmt key to your override-values.yaml file.

  2. In your override-values.yaml file for oc-cn-helm-chart, set these keys:

    • ocbrm.brm_apps.job.isEnabled: Set this to true.

    • ocbrm.brm_apps.job.isMultiSchema: Set this to false.

    • ocbrm.isAmt: Set this to true.

  3. Update the oc-cn-helm-chart/brmapps_scripts/loadme.sh script to run pin_amt commands: 

    cd /oms/apps/amt; pin_amt -s /oms/apps/amt/account_search.cfg
exit 0;

  4. In the configmap_infranet_properties_brm_apps.yaml file, do this:

    1. Under the Infranet.properties section, set the controller_1_hold_period key to the amount of time, in minutes, that the AMM Controller waits before migrating accounts. This provides time for your pipelines to flush any EDRs targeted for accounts in the migration job. The default is 120. 

      controller_1_hold_period=Value

    2. Under the account_search.cfg section, specify the account search criteria by editing the parameters in Table 8-1.

      Table 8-1 Account Search Parameters

      Parameter Description Required

      src_database

      Specifies the source schema, which is the schema from which you are migrating accounts. The default is 0.0.0.1.

      YES

      dest_database

      Specifies the destination schema, which is the schema to which you are migrating accounts. The default is 0.0.0.2.

      YES

      batch_size

      Specifies the number of accounts in each batch. You can specify any amount from 1 through 1,000. However, set this to an integer between 50 and 100 for optimal performance. The default is 100.

      Important:

      • Using a batch size of more than 50 accounts does not improve performance.

      • If you set this to a number greater than 100, you must increase the size of your Oracle rollback segments.

      YES

      start_creation_date

      Use this parameter to migrate accounts that were created in a specific date range. AMM migrates accounts created between midnight (00:00:00) on the start date and 23:59:59 on the end date. For example, to migrate accounts created after midnight on August 1, 2030, enter 08/01/2030.

      Important: If you set this parameter, you must also set the end_creation_date parameter.

      no

      end_creation_date

      Use this parameter to migrate accounts that were created in a specific date range. AMM migrates accounts created between midnight (00:00:00) on the start date and 23:59:59 on the end date. For example, to migrate accounts created on or before 11:59:59 p.m. on August 10, 2030, enter 08/10/2030.

      Important: If you set this parameter, you must also set the start_creation_date parameter.

      no

      product_name

      Migrates accounts that purchased the specified charge offer. For example, Offer 1b - Email Account.

      no

      account_status

      Migrates accounts based on the specified account status:

      • Active: Migrates only active accounts. This is the default.

      • Inactive: Migrates only inactive accounts.

      • Closed: Migrates only closed accounts.

      no

      bill_day_of_month

      Migrates accounts that have the specified billing day of the month (DOM). You can specify any number from 1 through 31. For example, enter 4 to migrate all accounts that are billed on the 4th of the month.

      no

      max_accounts

      Specifies the maximum number of accounts to move in a job. The default is 200.

      no

      poid_list

      Migrates accounts based on the POID. Use comma separators, for example, 22860, 22861, 22862. Limit the number of accounts to 1,000 or less.

      no

      migration_mode

      Specifies whether to migrate account groups. When AMM finds an account that belongs to a hierarchical account, charge sharing group, or discount sharing group, AMM migrates all accounts related to that account.

      • IncludeAccountGroup specifies to migrate accounts groups.

      • ExcludeAccountGroup specifies to exclude account groups from migrations. This is the default.

      Important: If you set this parameter, you must also set the max_group_size parameter.

      no

      max_group_size

      Specifies the maximum size of an account group that AMM can migrate. If an account group exceeds the maximum number of accounts, AMM excludes the account group from the job. The default is 100.

      no

      cross_schema_group

      Specifies whether pin_amt migrates accounts that belong to a cross-schema sharing group. A cross-schema sharing group has members in multiple database schemas.

      • Enabled: Does not migrate account members of a cross-schema sharing group.

      • Disabled: Migrates account members of a cross-schema sharing group. This is the default.

      Note: When this parameter is enabled, AMM performs validation for an account and only its immediate child account. You should perform extra validation to ensure accounts picked up by AMM are not part of a cross-schema sharing group.

      no

      For more information, see "Creating the Account Search Configuration File" in BRM Moving Accounts between Database Schemas.

  5. Run the helm upgrade command to update the release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

    The accounts meeting your search criteria are migrated from the source schema to the destination schema.

  6. Verify the brm-apps and controller log files.

Migrating Accounts Using Custom Search Criteria

Account Migration Manager (AMM) allows you to migrate accounts from one schema to another using custom search criteria. For example, you can create custom criteria for finding and migrating accounts for customers living in a specific American state or belonging to a particular service provider.

To migrate accounts using custom search criteria:

  1. Enable Account Migration Manager in your BRM database by setting ocbrm.isAmt to true in your override-values.yaml file.

  2. In your override-values.yaml file for oc-cn-helm-chart, set these keys:

    • ocbrm.brm_apps.job.isEnabled: Set this to true.

    • ocbrm.brm_apps.job.isMultiSchema: Set this to false.

    • ocbrm.isAmt: Set this to true.

  3. Update the oc-cn-helm-chart/brmapps_scripts/loadme.sh script to run pin_amt commands: 

    cd /oms/apps/amt; pin_amt -s /oms/apps/amt/account_search.cfg
exit 0;

  4. Open the configmap_infranet_properties_brm_apps.yaml file.

  5. Under the Infranet.properties section, set the controller_1_hold_period key to the amount of time, in minutes, that the AMM Controller waits before migrating accounts. This provides time for your pipelines to flush any EDRs targeted for accounts in the migration job. The default is 120. 

    controller_1_hold_period=Value

  6. Under the custom_account_search.properties section, add SQL fragments for your search criteria using this syntax: 

    criteria_name=AND SQL_condition \n

    where:

    • criteria_name is the name of your selection criteria.

    • SQL_condition is a valid SQL condition that searches a BRM table and references one or more search variables, as shown below. Surround search variables with curly braces “{ }" and ensure they match an entry under the account_search.cfg section. 

      condition_text '{SearchVariable}'...

    • SearchVariable must use a unique name and not match one of the BRM-defined search variable names under the account_search.cfg section.

    For example, this SQL fragment enables AMM to search for accounts in a particular state. AMM searches the ACCOUNT_NAME_INFO_T table for objects with the state field set to a specified value. 

    # select accounts based on state
cust_acct_search_account_state_constraint=\
AND EXISTS \n\
(SELECT an.obj_id0 FROM account_nameinfo_t an \n\
WHERE an.obj_id0 = a.poid_id0 and an.state = '{account_state}') \n

  7. Under the account_search.cfg section, add your SearchVariable entry set to the appropriate value.

    For example:

    # - Migrates accounts located in a specific state. Valid values
# are California and Oregon.
account_state=California

  8. Under the account_search.cfg section, specify the source and destination schema as well as any additional account search criteria by editing the parameters in Table 8-1.

  9. Save and close the configmap_infranet_properties_brm_apps.yaml file.

  10. For each custom search variable, create a corresponding Java implementation of the Conversion interface.

    1. Run the appropriate profile script for your shell. This script sets your CLASSPATH and PATH environment variables to the appropriate values.

      For example, for the c shell:

      cd BRM_home/apps/amt
source profile.csh

    2. Create a class that implements the Conversion interface.

      The following sample class, account_state.class, allows users to search for accounts from California or Oregon. 

      package com.portal.amt;
public class account_state implements Conversion {
  public String convert(String stateName) throws ConversionException {
    String stateCode = null;
    if(stateName.equals("California")) {
      stateCode = "CA";
    } else if(stateName.equals("Oregon")) {
      stateCode = "OR";
    } else {
      throw new 
        ConversionException("Error: account_state " + stateName + " unknown.");
    }
    return(stateCode);
  }
}

    3. Save and compile your SearchVariable.java source file in the BRM_home/apps/amt/com/portal/amt directory. 

      cd BRM_home/apps/amt/com/portal/amt
javac SearchVariable.java

      This creates a SearchVariable.class file in the same directory.

  11. Run the helm upgrade command to update the release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    The accounts meeting your custom search criteria are migrated from the source schema to the destination schema.

  12. Verify the brm-apps and controller log files.

Modifying Database Schema Priorities

Database schema priority determines when customer accounts are created in a particular schema relative to other schemas. Multidatabase Manager assigns accounts to an open schema with the highest priority.

If all schemas have the same priority, Multidatabase Manager chooses an open schema at random in which to create the account. This distributes accounts evenly across all schemas. However, BRM locates accounts as follows:

  • All accounts with nonpaying child units in the same schema as their paying parent bill units

  • All sponsored accounts are in the same schema as their sponsoring accounts

To limit the number of accounts in your primary database schema, set your primary database schema to a lower priority than the secondary database schemas. Accounts will be created in the secondary database schemas when possible.

You set each schema's priority by editing the configmap_pin_conf_testnap.yaml file and then running the load_config_dist utility through the configurator job.

Note:

The load_config_dist utility overwrites all distributions already in the database. When adding or updating distributions, be aware that you cannot load only new and changed distributions.

To modify database schema priorities:

  1. Open the configmap_pin_conf_testnap.yaml file.

  2. Under config_dist.conf, set the PRIORITY entries to the schema's priority with the highest number having the most priority. For example, 5 indicates a greater priority than a value of 1.

    In this example, BRM cloud native would create accounts on schema 0.0.0.2 because it has the highest priority setting of all open schemas.

    DB_NO = "0.0.0.1" ;             # 1st database config. block
PRIORITY = 1 ;
MAX_ACCOUNT_SIZE = 100000 ;
STATUS = "OPEN" ;
SCHEMA_NAME = "schema_name"
  
DB_NO = "0.0.0.2" ;             # 2nd database config. block
PRIORITY = 3;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "OPEN" ;
SCHEMA_NAME = "schema_name"
  
DB_NO = "0.0.0.3" ;             # 3rd database config. block
PRIORITY = 5; 
MAX_ACCOUNT_SIZE = 50000 ; 
STATUS = "CLOSED" ; 
SCHEMA_NAME = "schema_name"

  3. Save and close the file.

  4. Set up the configurator job to run the load_config_dist utility by adding the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script: 

    #!/bin/sh
 
#cp /oms/config_dist.conf /oms/sys/test/config_dist.conf
cd /oms/sys/test ; load_config_dist
exit 0;

  5. In your override-values.yaml file for oc-cn-helm-chart, set the ocbrm.config_jobs.run_apps key to true.

  6. Run the helm upgrade command to update the Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    The distribution information is loaded into the primary schema.

  7. Restart the CM.

    1. Update these keys in the override-values.yaml file for oc-cn-helm-chart:

      • ocbrm.config_jobs.restart_count: Increment the existing value by 1

      • ocbrm.config_jobs.run_apps: Set this to false

    2. Update the Helm release again:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      The CM is restarted.

Modifying Database Schema Status

Database schema status determines whether a schema is available for account creation. You can set schemas to the following statuses:

  • Open: Open schemas are available for account creation.

  • Closed: Closed schemas are not used for account creation under most circumstances. Accounts are created in a closed schema only if a sponsoring account belongs to that schema or if all schemas are closed. If all schemas are closed, Multidatabase Manager chooses a closed schema at random in which to create accounts. It continues creating accounts in that schema until a schema becomes open. To limit the number of accounts created in a schema, you can manually change the schema's status to closed or have Multidatabase Manager automatically switch it to closed when the schema reaches a predefined limit.

  • Unavailable: Unavailable schemas are not used for account creation unless the schema contains an account's parent or sponsoring account.

You set each schema's status by editing the configmap_pin_conf_testnap.yaml file and then running the load_config_dist utility through the configurator job.

Note:

The load_config_dist utility overwrites all distributions already in the database. When adding or updating distributions, be aware that you cannot load only new and changed distributions.

To modify a schema's status:

  1. Open the configmap_pin_conf_testnap.yaml file.

  2. Under config_dist.conf, set the value of each schema's STATUS entry to OPEN, CLOSED, or UNAVAILABLE. For example: 

    DB_NO = "0.0.0.1" ;             # 1st database config. block
PRIORITY = 1 ;
MAX_ACCOUNT_SIZE = 100000 ;
STATUS = "OPEN" ;
SCHEMA_NAME = "schema_name" ;
  
DB_NO = "0.0.0.2" ;             # 2nd database config. block
PRIORITY = 3;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "OPEN" ;
SCHEMA_NAME = "schema_name" ;

  3. Save and close the file.

  4. Set up the configurator job to run the load_config_dist utility by adding the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script: 

    #!/bin/sh
 
#cp /oms/config_dist.conf /oms/sys/test/config_dist.conf
cd /oms/sys/test ; load_config_dist
exit 0;

  5. In your override-values.yaml file for oc-cn-helm-chart, set the ocbrm.config_jobs.run_apps key to true.

  6. Run the helm upgrade command to update the Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    The distribution information is loaded into the primary schema.

  7. Restart the CM.

    1. Update these keys in the override-values.yaml file for oc-cn-helm-chart:

      • ocbrm.config_jobs.restart_count: Increment the existing value by 1

      • ocbrm.config_jobs.run_apps: Set this to false

    2. Update the Helm release again:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

Synchronizing /uniqueness Objects Between Schemas

In a multischema environment, BRM cloud native uses the /uniqueness object to locate subscribers. It contains a cache of services and must stay synchronized with the service cache in the primary schema. During normal multischema operations, the /uniqueness objects in the primary and secondary database schemas are updated automatically.

To determine whether the /uniqueness object in a secondary database schema is out of synchronization, use sqlplus to compare the entries in the uniqueness_t database table with those in the service_t database table. There should be a one-to-one relationship.

If the database tables are not synchronized, run the load_pin_uniqueness utility through the configurator job. This utility updates the /uniqueness object with the current service data.

To synchronize /uniqueness objects between database schemas:

  1. Set up the configurator job to run the load_pin_uniqueness utility by adding the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script: 

    #!/bin/sh 

cd /oms/sys/test ; load_pin_uniqueness
exit 0;

  2. In your override-values.yaml file for oc-cn-helm-chart, set the ocbrm.config_jobs.run_apps key to true.

  3. Run the helm upgrade command to update the Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    The load_pin_uniqueness utility is run.

  4. Restart the CM.

    1. Update these keys in the override-values.yaml file for oc-cn-helm-chart:

      • ocbrm.config_jobs.restart_count: Increment the existing value by 1

      • ocbrm.config_jobs.run_apps: Set this to false

    2. Update the Helm release again:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      The CM is restarted.

  5. Verify that the /uniqueness object was loaded by using one of the following to display the /uniqueness object:

    • Object Browser.

    • robj command with the testnap utility.