19 Integrating with Your BRM Cloud Native Deployment

Learn how to integrate the Oracle Communications Billing and Revenue Management (BRM) cloud native deployment with external systems, such as Oracle Analytics Publisher.

Topics in this document:

Integrating with Thick Clients

You can integrate BRM cloud native with thick clients that connect to Connection Manager (CM). When you enable TLS, provide the thick client with a customer-managed TLS wallet that contains the certificates required for the configured TLS mode.

To integrate a thick client with CM:

  1. In the override-values.yaml file for oc-cn-helm-chart, configure the CM TLS settings:

    • ocbrm.cm.serviceFqdn: Set this key to the Subject Alternative Name (SAN) in the TLS certificate, such as dns:node1.brm.com.

    • ocbrm.isSSLEnabled: Set this to true.

    • ocbrm.sslMode: Set this key to the TLS authentication mode:

      • ONE_WAY: The thick client validates the certificate presented by CM.

      • TWO_WAY: The thick client and CM authenticate each other by presenting and validating certificates.

  2. Provide a TLS wallet for the thick client.

    Configure the wallet according to the TLS mode:

    • For one-way TLS, include the trusted certificate authority (CA) certificates that the thick client uses to validate the certificate presented by CM.

    • For two-way TLS, include the thick client's identity certificate and private key in addition to the trusted CA certificates that it uses to validate the CM certificate.

    Use certificates issued by a CA approved by your organization. Manage the thick-client wallet independently of the CM wallet. Do not copy the CM TLS wallet to the thick client.

  3. If you configure two-way TLS and the thick client connects to CM over PCP, enable PCP client authentication in the client's Infranet configuration:

    infranet.pcp.ssl.client_auth=true

    For more information, see "Configuring BRM Client Applications for Two-Way TLS".

  4. If thick clients connect to CM through an external load balancer, ensure that the client wallet trusts the certificate presented at the TLS endpoint.

    The host name or IP address in the certificate must match the host name or IP address that the thick client uses to connect to the load balancer. See “Configuring an External Load Balancer for Connection Manager SSL/TLS Connections”.

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

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace 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.

Configuring TLS Certificates for BRM Cloud Native

You can secure TLS connections between BRM components and external applications by using Oracle wallets.

BRM cloud native container images do not include populated TLS wallets, private keys, or sample CA certificates. Before you enable TLS, obtain the required certificates from a certificate authority (CA) approved by your organization and create the Oracle wallets required for your deployment. You are responsible for managing and maintaining your certificates and wallets, including renewing and rotating certificates as needed.

How BRM Selects the TLS Wallet

When TLS is enabled, BRM selects the TLS wallet from the first available source in the following order:

  1. Component-specific extUserSSLWalletSecret

  2. ocbrm.extCustomSSLWalletSecret

  3. The custom-ssl-wallet secret created from brm_custom_wallet/cwallet.sso in the Helm chart

If none of these wallet sources is available when TLS is enabled, the Helm installation fails.

Note:

The ocbrm.customSSLWallet key is no longer used. Do not include this key in your override-values.yaml file.

Preparing the Required TLS Wallets

Before configuring TLS in your BRM cloud native deployment, obtain the CA certificates and identity certificates required by your organization's security policies and create the appropriate Oracle wallets. Use certificates issued by a certificate authority (CA) approved by your organization.

When you create a certificate for a BRM component, include all DNS names that clients use to connect to the component in the certificate's Subject Alternative Name (SAN). For example, if clients connect to the Connection Manager (CM) by using both its Kubernetes service name and an external host name, include both DNS names in the CM certificate.

The certificates required in each wallet depend on the TLS mode:

  • One-way TLS: The client must trust the certificate presented by the server. Ensure that the client wallet contains the appropriate trusted certificates and that the server wallet contains the server's identity certificate and private key. A BRM component that acts only as a TLS client does not require an identity certificate or private key.

  • Two-way TLS: both the client and server authenticate each other. Ensure that the wallets for both endpoints contain the appropriate trusted certificates, identity certificates, and private keys. A BRM component that acts as a TLS client therefore also requires its own identity certificate and private key.

Configuring TLS Certificates

To configure TLS certificates for your BRM cloud native deployment:

  1. Ensure that each wallet contains the certificates required for the component and the configured TLS mode:

    • For one-way TLS, a component acting as a server requires its identity certificate and private key. A component acting as a client requires the trusted certificates needed to validate the server certificate.

    • For two-way TLS, both the client and server require the appropriate identity certificate, private key, and trusted certificates.

  2. Provide the TLS wallets required by your BRM components.

    You can provide TLS wallets by using pre-created Kubernetes secret or, where supported, by providing brm_custom_wallet/cwallet.sso in the Helm chart.

    If a component requires its own identity certificate, provide a separate wallet for that component so that its pod receives only the certificate and private key that it requires.

    BRM supports component-specific and shared TLS wallet sources and selects the wallet according to a defined precedence order. See "How BRM Selects the TLS Wallet" for information about the supported wallet sources and their selection order.

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

  4. Configure TLS by setting the following keys:

    • ocbrm.isSSLEnabled: Set this to true.

    • ocbrm.sslMode: Specify the TLS authentication mode:

      • ONE_WAY: The client validates the certificate that the server presents.

      • TWO_WAY: The client and server authenticate each other by presenting and validating certificates. For BRM client applications that connect to CM over PCP, also set infranet.pcp.ssl.client_auth=true. See "Configuring BRM Client Applications for Two-Way TLS".

    • ocbrm.cmSSLTermination: Set this key to true if you want CM to terminate TLS and you do not want to use TLS between CM and downstream DMs and EMs.

  5. Configure the TLS wallet source for each BRM component that requires a wallet.

    To use a component-specific Kubernetes Secret, set the component's extUserSSLWalletSecret key to the name of the Secret.

    For example, to specify a TLS wallet Secret for CM:

    ocbrm:
   isSSLEnabled: true
   sslMode: "ONE_WAY"
   cm:
      extUserSSLWalletSecret: CmTLSWalletSecret

    Set the corresponding extUserSSLWalletSecret key for each additional component that requires its own TLS wallet.

    To use a shared external Kubernetes Secret, set ocbrm.extCustomSSLWalletSecret to the name of the Secret.

    Alternatively, where supported, provide brm_custom_wallet/cwallet.sso in the Helm chart. The Helm chart creates the custom-ssl-wallet Secret from this wallet.

    Note:

    If you enable TLS and do not provide a supported wallet source, the Helm installation fails.

  6. Install BRM cloud native services by entering the following command from the helmcharts directory:

    Note:

    If BRM cloud native is already installed, run the helm upgrade command instead. 

    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.

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

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

  7. Verify that the BRM pods are running and that the TLS connections are succeed.

    Before you install or upgrade BRM cloud native, you can verify the contents of an Oracle wallet by running:
    orapki wallet display -wallet WalletPath -summary

    where WalletPath is the path to the Oracle wallet.

    Verify that the wallet contains the identity and trusted certificates required for the configured TLS mode.

For information about integrating clients outside the Kubernetes cluster with the CM, see "Integrating with Thick Clients".

Configuring BRM Client Applications for Two-Way TLS

When you set ocbrm.sslMode to TWO_WAY, BRM clients and servers authenticate each other by using TLS certificates. Configure each BRM client application that uses PCP to present its client certificate during the TLS handshake.

To configure a BRM client application for two-way TLS:

  1. Ensure that the application's TLS wallet contains:

    • The application's identity certificate and private key

    • The trusted certificates required to validate the certificate presented by the BRM server

  2. Enable PCP client authentication in the application's Infranet configuration:

    infranet.pcp.ssl.client_auth=true

  3. Configure the application to use the TLS wallet that contains the required certificates and private key.

  4. Restart or redeploy the application so that the configuration changes take effect.

Note:

For one-way TLS, do not set infranet.pcp.ssl.client_auth to true. A BRM component that acts only as a client needs the trusted certificates required to validate the server certificate. The component does not need a client identity certificate or private key.

Configuring an External Load Balancer for Connection Manager SSL/TLS Connections

You can configure clients to connect to CM through an external load balancer. In this configuration, the client connects to the load balancer, and the load balancer forwards the connection to the Kubernetes worker node on which CM is available.

When CM is configured to use SSL or TLS, a handshake error can occur if the load balancer or the BRM client is not configured with the required certificate information.

You can configure the load balancer for SSL/TLS in one of these ways:

  • Configure SSL/TLS between the BRM client and the load balancer only.

    In this configuration, the BRM client connects to the load balancer using SSL/TLS. The load balancer connects to CM without SSL.

    Ensure that the certificate configured on the load balancer meets one of these requirements:

    • The certificate is issued by a certificate authority (CA) that is trusted in the Oracle wallet used by the BRM client.

    • The certificate configured on the load balancer is added as a trusted certificate in the Oracle wallet used by the BRM client.

    Also ensure that the host name or IP address in the certificate matches the load balancer host name or IP address that the BRM client uses to connect.

  • Configure SSL/TLS between the BRM client and the load balancer, and between the load balancer and CM.

    In this configuration, the BRM client connects to the load balancer using SSL/TLS. The load balancer must also start an SSL connection to CM.

    Configure the load balancer to connect to the CM back end using SSL instead of a plain TCP connection. Also configure the load balancer with the certificate information that it requires to trust the CM certificate.

Integrating with JCA Resource Adapter

You can deploy the BRM JCA Resource Adapter in WebLogic Server and use it to run opcodes in the BRM cloud native deployment. For more information about JCA Resource Adapter, see BRM JCA Resource Adapter.

Note:

To allow the JCA Resource Adapter to communicate with the BRM cloud native deployment, expose the CM service as NodePort. For information, see "Integrating with Thick Clients".

To deploy JCA Resource Adapter in your BRM cloud native deployment:

  1. Enable the brm-sdk pod by setting these keys in your override-values.yaml file for oc-cn-helm-chart: 

    brm_sdk:
   isEnabled: true
   deployment:  
      imageName: brm_sdk
      imageTag: 16.26.0.x.x
   pvc:             
      storage: 50Mi

  2. Run the helm upgrade command for oc-cn-helm-chart: 

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

  3. Find the name of the brm-sdk pod:

    kubectl get pods -n BrmNameSpace | grep brm-sdk

    You should see something similar to this:

    NAME                       READY    STATUS     RESTARTS    AGE
brm-sdk-f67b95777-bf8j5    1/1      Running    0           18m

  4. Enter the brm-sdk pod:

    kubectl exec -n BrmNameSpace -it BrmSdkPodName bash

    where BrmSdkPodName is the name of the pod from step 3.

    For example:

    kubectl exec -n MyNameSpace -it brm-sdk-f67b95777-bf8j5 bash

  5. Go to the apps/brm_integrations/jca_adapter/ directory and copy the OracleBRMJCA15Adapter.rar file to a new staging directory: 

    cd apps/brm_integrations/jca_adapter/
mkdir staging
cp OracleBRMJCA15Adapter.rar staging/

  6. Go to your staging directory and extract the files from the OracleBRMJCA15Adapter.rar archive file: 

    cd staging
jar xvf OracleBRMJCA15Adapter.rar

  7. Update the following parameters in your META-INF/weblogic-ra.xml file:

    • ConnectionString: Set this to the string for connecting to the BRM service in the format: 

      protocol host port

      For example: ip cm 11960.

    • Password: Set this to the password for the BRM root user.

    • JavaPcmSSL: Set this to true if SSL is enabled for BRM.

    • SslWalletLocation: Set this to the location of the Oracle wallet that contains the BRM client TLS certificate. This can be copied from the BRM installation.

  8. From your staging directory, delete the OracleBRMJCA15Adapter.rar file and then build a new archive file using the updated META-INF/weblogic-ra.xml file: 

    rm OracleBRMJCA15Adapter.rar
jar cvf OracleBRMJCA15Adapter.rar  .

  9. Copy the new OracleBRMJCA15Adapter.rar into the brm-sdk PVC storage class: 

    cp OracleBRMJCA15Adapter.rar /oms/ext/

  10. Copy the client wallet to the brm-sdk PVC storage class:

    cp -r /oms/wallet/client/ /oms/ext/wallet/

  11. Exit the brm-sdk pod.

  12. Retrieve the name of the PVC volume for the brm-sdk pod:

    kubectl get pvc -n BrmNameSpace | grep brm-sdk

    You should see something similar to this:

    NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGE CLASS  AGE
brm-sdk   Bound    pvc-094feae0-4d11-4887-83a0-b47a0fc6a3f4   50Mi       RWX            myclass        24h

  13. Copy the OracleBRMJCA15Adapter.rar archive file from the PVC to the working directory 

    cp NfsMountPath/BrmNameSpace/BrmSdkPvc/OracleBRMJCA15Adapter.rar  .

    where BrmSdkPvc is the name of the PVC volume from step 12.

    For example:

    cp -r /mnt/oke_test/MyNameSpace/pvc-094feae0-4d11-4887-83a0-b47a0fc6a3f4/OracleBRMJCA15Adapter.rar .

  14. Copy the client wallet from the PVC to the working directory:

    cp -r NfsMountPath/BrmNameSpace/BrmSdkPvc/WalletFolder .

    For example:

    cp -r /mnt/oke_test/MyNameSpace/pvc-094feae0-4d11-4887-83a0-b47a0fc6a3f4/wallet .

  15. Copy the client wallet to the appropriate path and deploy OracleBRMJCA15Adapter.rar on AIA.

Integrating with Kafka Servers

You can integrate your BRM cloud native system with a Kafka server to keep data synchronized between BRM cloud native and your external applications that are connected to the Kafka server. To synchronize account, pricing, and other data, BRM cloud native takes data from internal notification events and constructs a business event that is published to a topic in your Kafka server. Your external applications can then retrieve and process the data from the Kafka topic. For more information, see "About Integrating BRM with an Apache Kafka Server" in BRM Developer's Guide.

You integrate BRM cloud native with a Kafka server and configure it to publish data to a Kafka server using the CM, Kafka DM, and Enterprise Application Integration (EAI) framework.

To integrate BRM cloud native with a Kafka Server:

  1. (Optional) Configure the KeyStores required for secure communication between the Kafka DM and Kafka Server.

    1. Create the client certificate, client KeyStore, and client TrustStore. See "Security" in the Apache Kafka documentation.

    2. Verify that the server KeyStore and TrustStore are set up properly by running the following command:

      openssl s_client -debug -connect DomainName:PortNumber -tls1_2

      If successful, the certificate is displayed. If the certificate isn't displayed or if there are any other error messages, the KeyStore isn't set up properly.

    3. Move the client's KeyStore files, such as identity.p12 and trust.p12, under the oc-cn-helm-chart/keystores directory.

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

  3. Enable and configure the Kafka DM by editing the following keys:

    • ocbrm.dm_kafka.is_enabled: Set this to true.

    • ocbrm.dm_kafka.kafkaAsyncMode: Specify whether to use asynchronous mode (true), in which the Kafka DM records all business events that fail to publish to a log file. In synchronous mode (false), the Kafka DM returns errors to BRM when a business event fails to publish to the Kafka server.

    • ocbrm.dm_kafka.deployment.kafka_bootstrap_server_list: Set this to a comma-separated list of addresses for the Kafka brokers in this format: hostname1:port1, hostname2:port2. The default is ece-kafka:9093.

    • ocbrm.dm_kafka.deployment.poolSize: Set this to the number of threads that can run in the JS server to accept requests from the CM. Enter a number from 1 through 2000. The default is 64.

      Note:

      Set ocbrm.dm_kafka.deployment.poolSize to the thread pool size that the EAI Java Server (JS) uses. A mismatch can lead to thread exhaustion or connection failures over time. The CM log can contain intermittent PIN_ERR_DM_CONNECT_FAILED errors. The connection failures can cause order processing to fail. For more information, see "Configuring Thread Pooling for the Kafka DM" in BRM Developer's Guide.

    • ocbrm.dm_kafka.deployment.topicName: Set this to the name of the default Kafka topic. The default name is BRM.

    • ocbrm.dm_kafka.deployment.topicFormat: Set this to the format of the payload that is published to the default Kafka topic: XML or JSON.

    • ocbrm.dm_kafka.deployment.topicStyle: Set this to the style of all field names in XML payloads:

      • ShortName: The XML field names are in all capitals, such as <POID>, <ACCOUNT_OBJ>, and <SUBSCRIBER_PREFERENCES_INFO>. This is the default.

      • CamelCase: The XML field names are in CamelCase, such as <Poid>, <AccountObj>, and <SubscriberPreferencesInfo>.

      • NewShortName: The XML field names are in CamelCase and are prefixed with fld, such as <fldPoid>, <fldAccountObj>, and <fldString>.

      • OC3CNotification: The input is transformed to match the field and formatting requirements of Oracle Communications Convergent Charging Controller. Use this style if Convergent Charging Controller is your external notification application.

    • ocbrm.dm_kafka.deployment.isSecurityEnabled: Specifies whether SSL is enabled between the Kafka DM and Kafka Server.

    • ocbrm.dm_kafka.deployment.trustStorePassword: Specifies the TrustStore password in Base64 format.

    • ocbrm.dm_kafka.deployment.keyStorePassword: Specifies the KeyStore password in Base64 format.

    • ocbrm.dm_kafka.deployment.keyPassword: Specifies the key password in Base64 format.

    • ocbrm.dm_kafka.deployment.password: Specifies the password in Base64 format.

  4. Configure the EAI Java Server (JS) to use the Kafka DM event notification file by setting the ocbrm.eai_js.deployment.eaiConfigFile key to payloadconfig_ifw_kafka_sync_merged.xml.

  5. Save and close the file.

  6. To create additional Kafka topics or configure the Kafka DM to publish different business events to a Kafka topic, edit the dm-kafka-config ConfigMap.

    For more information about editing this ConfigMap, see "Mapping Business Events to Kafka Topics" in BRM Developer's Guide.

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

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace 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.

Example: Integrating BRM Cloud Native with a Kafka Server

The following shows sample override-values.yaml entries for integrating a BRM cloud native system with a Kafka Server: 

ocbrm:
    dm_kafka:
        isEnabled: true
        kafkaAsyncMode: true
        deployment:
            imageName: dm_kafka
            imageTag: $BRM_VERSION
            replicaCount: 1
            kafka_bootstrap_server_list: ece-kafka:9093
            poolSize: 64
            topicName: BRMTopic
            topicFormat: XML
            topicStyle: CamelCase
            isSecurityEnabled: true
            trustStorePassword: TrustStorePassword
            keyStorePassword: KeyStorePassword
            keyPassword: KeyPassword
            password: Password
    eai_js:
        deployment:
            imageName: eai_js
            imageTag: $BRM_VERSION
            eaiConfigFile: payloadconfig_ifw_sync.xml

Integrating with Oracle Analytics Publisher

You can optionally integrate your BRM cloud native deployment with invoicing software such as Oracle Analytics Publisher. This integration enables you to generate more detailed and stylized customer invoices that can be viewed in your invoicing software or Billing Care.

To integrate your BRM cloud native deployment with Oracle Analytics Publisher:

  1. If you have not already done so, install Oracle Analytics Publisher.

    For a list of compatible software versions, see BRM Compatibility Matrix.

  2. Install the BRM-Oracle Analytics Publisher invoicing integration package using the OUI installer on your Oracle Analytics Publisher server. This copies invoice layout templates, such as for corporate invoices and consumer invoices, to the Oracle Analytics Publisher server.

    The steps for installing the package on BRM cloud native are similar to those on BRM on-premises. For more information, see "Installing the BRM-Oracle Analytics Publisher Invoicing Integration Package" in BRM Designing and Generating Invoices.

  3. Configure how to connect your Billing Care and Billing Care REST API cloud native services with Oracle Analytics Publisher.

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

    • ocbc.bc.configEnv.bipUrl: The URL for PublicReportService_v11 from your Oracle Analytics Publisher instance, which Billing Care uses to show invoices.

    • ocbc.bc.configEnv.bipUserId: The name of the user with access to the Oracle Analytics Publisher instance for viewing invoices from Billing Care.

    • ocbc.bc.secretVal.bipPassword: The Base64-encoded password for the Oracle Analytics Publisher user.

    • ocbc.bcws.configEnv.bipUrl: The URL for PublicReportService_v11 from your Oracle Analytics Publisher instance, which is used by the Billing Care REST API when accessing PDF invoices.

    • ocbc.bcws.configEnv.bipUserId: The name of the user with access to the Oracle Analytics Publisher instance for accessing invoices from the Billing Care REST API.

    • ocbc.bcws.secretVal.bipPassword: The Base64-encoded password for the Oracle Analytics Publisher user.

  4. Do one of the following:

  5. Configure how to connect BRM cloud native with Oracle Analytics Publisher.

    In your override-values.yaml file for oc-cn-helm-chart, set these keys under ocbrm.brm_apps.deployment.pin_inv_doc_gen:

    • bipServer: The name of the server on which Oracle Analytics Publisher is installed.

    • bipPort: The port number for Oracle Analytics Publisher.

    • bipUsername: The name of the user with access to the Oracle Analytics Publisher instance.

    • bipPassword: The Base64-encoded password for the Oracle Analytics Publisher user.

    • schedulerDBServer: The name of the server on which the Scheduler database is installed.

    • schedulerDBPort: The port number for communicating with the Scheduler database.

    • schedulerDBService: The service name for the Scheduler database.

    • schedulerDBUsername: The user name for the Scheduler database.

    • schedulerDBServiceCredentials: The security credentials for connecting to the Scheduler database.

    • jdbcPoolSize: The initial number of connections maintained in the pool.

    • jdbcPoolMaxSize: The maximum number of connections that can be created.

    • securityCredentials: The password for the Oracle wallet.

  6. In the BRM Helm chart's configmap_pin_conf_brm_apps_1.yaml file, set the following entries:

    • pin_inv_export export_dir: Set this to ./invoice_dir.

    • pin_inv_export invoice_fmt: Set this to text/xml.

    For example:

    - pin_inv_export  export_dir  ./invoice_dir
- pin_inv_export  invoice_fmt  text/xml

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

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

    where BrmReleaseName is the release name assigned to your existing oc-cn-helm-chart installation.

  8. In your bus_params_Invoicing.xml file, set the following entries:

    • xsi:schemaLocation: Set this to http://www.portal.com/schemas/BusinessConfig/oms/xsd/business_configuration.xsd.

    • EnableInvoicingIntegration: Set this to enabled to integrate BRM with your invoicing software.

    • InvoiceStorageType: Set this to 1 to store invoices in XML format.

    For example:

    <BusinessConfiguration
    xmlns="http://www.portal.com/schemas/BusinessConfig"        
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        
    xsi:schemaLocation="http://www.portal.com/schemas/BusinessConfig 
/oms/xsd/business_configuration.xsd">
...
<EnableInvoicingIntegration>enabled</EnableInvoicingIntegration>
<InvoiceStorageType>1</InvoiceStorageType>

  9. In your bus_params_billing.xml file, set the following entries:

    • RerateDuringBilling: Specify whether delayed events that arrive after the end of the accounting cycle but during the delayed billing period can borrow against the rollover of the current cycle (enabled) or not (disabled).

    • EnableCorrectiveInvoices: Specify whether to enable corrective billing and corrective invoicing (enabled) or not (disabled).

    • AllowCorrectivePaidBills: Specify whether to allow a corrective bill to be generated for a bill that has been fully or partially paid (enabled) or not (disabled).

    • RejectPaymentsForPreviousBill: Specify whether to reject payments when the bill number associated with a payment does not match the last bill (enabled) or to accept them (disabled).

    • CorrectiveBillThreshold: Specify the minimum bill amount that triggers a corrective bill.
    • GenerateCorrectiveBillNo: Specify whether corrective invoices use corrective bill numbers (enabled) or the original bill numbers (disabled).

    For example:

    <RerateDuringBilling>enabled</RerateDuringBilling>
<EnableCorrectiveInvoices>enabled</EnableCorrectiveInvoices>
<AllowCorrectivePaidBills>enabled</AllowCorrectivePaidBills>
<RejectPaymentsForPreviousBill>enabled</RejectPaymentsForPreviousBill>
<CorrectiveBillThreshold>0</CorrectiveBillThreshold>
<GenerateCorrectiveBillNo>enabled</GenerateCorrectiveBillNo>

  10. In your events.file file, specify which events to include in your invoices.

    For more information, see "Including Payment, A/R, and Tax Details in Invoices" in BRM Designing and Generating Invoices.

  11. In your pin_business_profile.xml file, configure your business profiles and validation templates.

    For more information, see "Setting Up Business Profiles and Validation Templates" in BRM Managing Customers.

  12. In your pin_invoice_data_map file, create or modify the data invoice templates.

    For more information, see "Using Data Map Templates" in BRM Designing and Generating Invoices.

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

    #!/bin/sh 

cd /oms/sys/data/config; pin_bus_params -v /oms/load/bus_params_Invoicing.xml
cd /oms/sys/data/config; pin_bus_params -v /oms/load/bus_params_billing.xml 
cd /oms/sys/data/config; pin_load_invoice_events -reload -brand "0.0.0.1/account 1 0" -eventfile /oms/load/events.file
cd /oms/sys/data/config; load_pin_business_profile /oms/load/pin_business_profile.xml
cd /oms/sys/data/config; load_pin_invoice_data_map -dv /oms/load/pin_invoice_data_map
exit 0;

  14. Move the following input files to the oc-cn-helm-chart/config_scripts directory:

    • bus_params_invoicing.xml

    • bus_params_billing.xml

    • events.file

    • pin_business_profile.xml

    • pin_invoice_data_map

  15. Enable the configurator job.

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

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

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

    The configurator job runs the utilities specified in the loadme.sh script.

  17. Restart the CM because it is required by pin_bus_params.

    1. Set these keys in the override-values.yaml file:

      • 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 --namespace BrmNameSpace

When configuring Oracle Analytics Publisher, ensure that the Create_Xmlp_Invoice_Job.sql script is run in the schema in which the scheduler database is installed. This script creates the XMLP_INVOICE_JOB table, which should be present in the scheduler database.

Generating Invoices in Oracle Analytics Publisher

After integration is complete, you can generate your customers' invoices in Oracle Analytics Publisher by doing the following:

  1. Creating /invoice objects for your customers by doing one of the following:

  2. Generating your customer invoice documents using Oracle Analytics Publisher templates by running the pin_inv_doc_gen utility through a brm-apps job. See "Running Applications and Utilities Through brm-apps Jobs".