6 Deploying the BRM Database Schema

Learn how to deploy a new or existing database schema in the Oracle Communications Billing and Revenue Management (BRM) cloud native environment.

Topics in this document:

Deploying BRM with a New Database Schema

To deploy BRM with a new BRM and pipeline database schema:

  1. If you have not already done so, create and configure your BRM database. See "Creating and Configuring Your BRM Database".

  2. Create a new Kubernetes namespace for oc-cn-init-db-helm-chart: 

    kubectl create namespace InitDbNameSpace

  3. Create an override-values.yaml file for oc-cn-init-db-helm-chart, and add keys from Table 6-1.

    Note:

    This documentation uses the override-values.yaml file name for ease of use, but you can name the file whatever you want.

  4. If you want the init-db Helm chart to create users and tablespaces for you, add the following keys to your file:

    Note:

    Skip this step for production systems or if you pre-created the database user and tablespaces.

    • db.user: Specify the user name of the system administrator.

    • db.password: Specify the password for the system administrator.

    • db.port: Specify the port number of the database server.

    During deployment, the init-db Helm chart uses these values to validate the schema user names and tablespace names that you provide. If any schema users or tablespace names are missing, the init-db Helm chart creates them using the system administrator credentials.

  5. If you want to deploy the BRM cloud native schema into a multischema database, do the following in your override-values.yaml file:

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

    2. For each secondary schema in your system, add an ocbrm.db.multiSchemas.secondaryN block, where N is 1 for the first secondary schema, 2 for the next secondary schema, and so on.

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

      Note:

      If the host, port, and service keys are not defined, the secondary schema uses the same host name, service, and port number as the primary schema.

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

      • host: Set this to the host name 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.

    4. Enable account migration between your schemas by setting the ocbrm.isAmt key to true.

      See "Understanding Account Migration" in BRM Moving Accounts Between Database Schemas for more information.

    This shows example entries for a BRM database with one primary schema, two secondary schemas, and account migration enabled:

    ocbrm:
   isAmt: true
ocbrm:
   db:
      host: hostname
      port: 12345
      service: serviceName
      schemauser: pin01
      schemapass: password
      schematablespace: pin01
      indextablespace: pinx01
      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

  6. To commit seed data to the BRM database, modify the init-db container (configmap_create_obj_2.yaml) to add the corresponding PCM_OP_CREATE_OBJ input flist. For example: 

    <PCM_OP $PIN_OPNAME=$PIN_CONF_INIT_OPNAME; $PIN_OPFLAGS=0>
0 PIN_FLD_POID           POID [0] $DB_NUMBER /config/recharge_card_type 0 0
0 PIN_FLD_NAME            STR [0] "-"
0 PIN_FLD_PROGRAM_NAME    STR [0] "load_pin_recharge_card_type"
0 PIN_FLD_HOSTNAME        STR [0] "-"
0 PIN_FLD_VERSION         STR [0] "1"
0 PIN_FLD_ACCOUNT_OBJ    POID [0] 0.0.0.1 /account 1 0
</PCM_OP>

  7. Initialize the BRM database schema by running this command from the helmcharts directory: 

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

    where:

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

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

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

    The init-db Helm chart creates an init-db pod and job for each schema.

  8. After the init-db Helm chart deploys successfully, delete the Helm chart from your namespace by running this command from the helmcharts directory: 

    helm delete InitDbReleaseName -n InitDbNameSpace

Table 6-1 lists the keys that directly impact the BRM database schema and pipeline database schema. Add these keys to your override-values.yaml file with the same path hierarchy.

Caution:

Some keys hold sensitive data. They must be handled carefully with controlled access to the file containing its values. Encode all of these values in Base64. See "Secrets" in Kubernetes Concepts.

Table 6-1 oc-cn-init-db-helm-chart Keys

Key Purpose

imageRepository

Specify the registry server where you have pushed images. Typically, in the format “RepoHost:RepoPort/”.

The value is added as a prefix to all image names when you install or upgrade Helm charts.

This key is empty by default.

imagePullSecrets

Specify the name of the secret containing credentials for accessing images from your private image server.

This is added to each pod to give it permission to pull the image from your private registry server. See "Creating Secrets for Docker Registry Authorization" for more information.

uniPass

Use this key to apply a uniform password to all BRM cloud native services, including:

  • Database Schemas
  • BRM Root Login
  • Oracle Wallets
  • WebLogic User

To override this password for a specific service, specify a different password in the service's key.

Note: Use this key for test or demonstration systems only.

db.sslMode

Specify the type of SSL connection required to connect to the database: TWO_WAY, ONE_WAY, or NO. The default is ONE_WAY.

db.extDBSSLWalletSecret

Specify the name of the Kubernetes secret containing the SSL database wallet. See "Using External Kubernetes Secrets for Certificates and Wallets" in BRM Cloud Native System Administrator's Guide.

db.user

db.password

db.port

Specify the system administrator credentials. Set these keys only if you want the init-db Helm chart to create database users and tablespaces for you. The init-db Helm chart creates any missing schema users and tablespaces using the system administrator credentials.

  • db.user: Specify the user name of the system administrator.

  • db.password: Specify the password of the system administrator.

  • db.port: Specify the port number of the database server.

Note: If these keys are not included, the init-db Helm chart assumes that the database user and tablespaces have been pre-created and throws an error if it runs into a connection issue.

ocbrm.*

Specify the details for deploying BRM:

  • imagePullPolicy: Specify when to pull images:

    • IfNotPresent: Pulls an image only if one is not present locally. This is the default.
    • Always: Always pulls an image.

  • isAmt: Whether account migration is enabled in your BRM multischema database (true) or not (false). The default is false.

  • isIPV6Enabled: Whether IPV6 is enabled in your Kubernetes environment (true) or not (false). The default is false.

  • ece_deployed: Whether to deploy and load ECE configurations into your BRM cloud native environment (true) or not (false). The default is true.

  • pdc_deployed: Whether to deploy and load PDC configurations into your BRM cloud native environment (true) or not (false). The default is false.

  • is_upgrade: Whether to upgrade the database (true) or perform a fresh database initialization (false). The default is false.

  • TZ: Specify the Linux time zone. The default is UTC.

  • LOG_LEVEL: Specify the log level. The default is 1.

  • isSSLEnabled: Whether TLS is enabled for BRM components. The default is true.

  • sslMode: Specify the TLS authentication mode for BRM component connections: ONE_WAY or TWO_WAY. The default is ONE_WAY.

  • cmSSLTermination: Whether the CM terminates TLS and disables TLS between the CM and DMs/EMs

    • true: The CM is the SSL endpoint. Set it to true when using a custom TLS certificate for the CM. When set to true, also set the isSSLEnabled key to true.
    • false: SSL is enabled across all components, from client to CM to DMs and EMs. This is the default.

  • extCustomSSLWalletSecret: Specify the name of an external Kubernetes secret containing customer-provided TLS wallet material. BRM uses this secret as a shared wallet source when a component-specific wallet secret is not configured. See "Using External Kubernetes Secrets for Certificates and Wallets" in BRM Cloud Native System Administrator's Guide.

  • isHPAEnabled: Whether to enable autoscaling (true) or not (false). The default is false.

  • refreshInterval: Specify the interval for refreshing the PCM context to accept a request on a new CM.

  • terminationGracePeriodSeconds: Specify how long to wait before terminating the pod. Increase the value for long-running transactions.

  • pcpReconnectDelayOnSocketError: Specify how long to wait for a socket reconnection.

  • pcpConnectRetryDelayOnError: Specify the amount of time for retrying a connection after the PCP connection fails.

  • EnableSecurityContext: Whether to enable the Security Context in the cluster. The default is false.

  • root_key_rotate: Whether to rotate the BRM root key. The default is false. For more information, see "Rotating the BRM Root Key" in BRM Cloud Native System Administrator's Guide.

  • brm_root_pass: Specify the BRM root password. The value can be per user. You must generate a secret. Add this key to your override-values.yaml file with the same path hierarchy.

  • rotate_brm_role_passwords: Whether to rotate the BRM role passwords. The default is false.

ocbrm.brm_role_pass.*

Specify the initial passwords for each BRM role. The roles grant users the permission to access different BRM components, such as Billing Care or Pipeline Configuration Center (PCC).

Note: You must set all of these passwords when the unipass key is not set.

You set passwords for the following roles:

  • acct_recv.0.0.0.1: Accounts receivable
  • bc_client.0.0.0.1: Billing Care
  • bill_inv_pymt_sub.0.0.0.1: Invoice payments
  • billing.0.0.0.1: Billing
  • boc_client.0.0.0.1: Business Operations Center
  • collections.0.0.0.1: Collections
  • crypt_utils.0.0.0.1: Encryption utilities
  • cust_mgnt.0.0.0.1: Customer management
  • invoicing.0.0.0.1: Invoicing
  • java_client.0.0.0.1: Java clients
  • load_utils.0.0.0.1: Load utilities
  • payments.0.0.0.1: Payments
  • pcc_client.0.0.0.1: PCC
  • rerating.0.0.0.1: Rerating
  • rsm.0.0.0.1: BRM REST Services Manager
  • super_user.0.0.0.1: Super User
  • ui_client.0.0.0.1: All thick clients
  • ece.0.0.0.1: ECE

Note: After you deploy or upgrade the database schema, you should rotate the role passwords regularly to improve security. For more information, see "Rotating BRM Role Passwords" in BRM Cloud Native System Administrator's Guide.

ocbrm.wallet.config

The BRM configuration wallet used to securely store sensitive BRM configuration information, such as passwords, database credentials, and connection information. The wallet is created at runtime and is available at /oms/wallet/config.

ocbrm.db.*

Specify the details for connecting to a shared database. The keys in this section take precedence over other database connection keys.

Add these keys only if your system uses a shared database:

  • host: Specify the host name of the machine on which the BRM database is configured.
  • port: Specify the port on which the BRM database is configured.
  • service: Specify the BRM database service name.
  • sslMode: Specify the type of SSL connection required to connect to the database: TWO_WAY, ONE_WAY, or NO.

  • extDBSSLWalletSecret: Specify the name of the secret containing the SSL database wallet. See "Using External Kubernetes Secrets for Certificates and Wallets" in BRM Cloud Native System Administrator's Guide.

  • walletPassword: Specify the password for accessing the database certificates from the TrustStore and KeyStore.
  • walletType: Specify the type of file specified as the TrustStore or KeyStore for database SSL connections: SSO or pkcs12.
  • enable_partition: Whether partitioning is enabled in your BRM database: Yes or No. The default is Yes.
  • enable_delayed_partition: Whether delayed partitioning is enabled for all subclasses of the /event storable class: Yes or No. The default is Yes.
  • storage_model: Specify the size of the BRM database tablespaces: Test (less than 700 MB), Small (less than 1.5 GB), Medium (less than 30 GB), or Large (greater than 30 GB).
  • schemauser: Specify the user name for the primary BRM schema.
  • schemapass: Specify the password for the database schema.
  • schematablespace: Specify the name of the schema tablespace.
  • indextablespace: Specify the name of the index tablespace.
  • nls_lang: The language, territory, and character set. Set this to American_America.characterset, where characterset is either UTF8 or AL32UTF8.

    Note: You must use American_America as the language and territory, regardless of your locale.

  • pipelineschemauser: Specify the BRM pipeline schema user name.
  • pipelineschemapass: Specify the BRM pipeline schema password. You must generate a secret. Add this key to your override-values.yaml file with the same path hierarchy.
  • pipelineschematablespace: Specify the name of the tablespace for the BRM pipeline schema. This field is case-sensitive.
  • pipelineindextablespace: Specify the name of the index tablespace for the BRM pipeline schema. This field is case-sensitive.
  • skipPrimary: Whether to skip the deployment of the primary schema: False (deploy the primary schema) or True (do not deploy the primary schema).

    Set skipPrimary to true only if you are adding a schema to an existing BRM multischema system. See "Adding Schemas to a Multischema System" in BRM Cloud Native System Administrator's Guide.

ocbrm.db.multiSchemas.secondaryN

Specify the details for connecting to your secondary schemas, where N is 1 for the first secondary schema, 2 for the next secondary schema, and so on.

Add this block only if your BRM database contains multiple schemas. This section is commented out by default:

multiSchemas: 
   secondary1: 
      deploy: true
      host: localhost 
      port: 1521 
      service: pindb 
      schemauser: 
      schemapass: 
      schematablespace: 
      indextablespace:

Deploying BRM with an Existing Schema

You can deploy BRM cloud native with an existing BRM database schema by using either the default Oracle images or custom BRM server images.

Starting in BRM 16.26.0, BRM stores the root-key wallet in the BRM database and retrieves it from the database when required.

If you enable TLS, provide the required TLS identity and trust material by using the supported Kubernetes secret configuration.

To deploy BRM with an existing schema:

  1. Complete the database upgrade before you deploy the BRM services.

    You do not need to copy the root-key wallet into the Helm chart after the upgrade.

  2. If you use custom BRM server images, create an image for each BRM server component in the installed BRM staging area that you used to initialize the database.

    Do not include populated wallets, private keys, sample CA certificates, or default credentials in your custom images or image-build context.

    If you use the default Oracle images, skip this step.

  3. In your override-values.yaml file for oc-cn-helm-chart, configure the connection information and credentials for the existing BRM database schema. Also configure the following keys as applicable:

    • ocbrm.use_oracle_brm_images: If you use custom BRM Server images, set this to false. If you use the default Oracle images, set this to true.

    • ocbrm.db.queuename: Set this to the queue name in the existing BRM database.

    • ocbrm.db.roamqueuename: If you use a database queue for Roaming Pipeline, create the queue by following the instructions in "Creating Additional Queues for Multischema BRM Systems" in BRM Installation Guide. Set the roamqueuename key to the name of the queue that you create.

  4. If you enable TLS and use external Kubernetes secrets, pre-create the secrets that contain the required TLS wallet material.

    Configure a component-specific secret by using the appropriate ocbrm.component.extUserSSLWalletSecret key, or configure a shared wallet secret by using the ocbrm.extCustomSSLWalletSecret key, as appropriate for your deployment. BRM uses the configured external wallet secret instead of obtaining TLS wallet material from the container image.

    You do not need to create a Kubernetes secret for the root-key wallet because BRM stores the root-key wallet in the database.

    For more information about configuring wallet secrets, see "Managing Wallet and KeyStore Certificates".

  5. Deploy oc-cn-helm-chart.