8 Configuring REST Services

Learn how to integrate external applications with your Oracle Communications Billing and Revenue Management (BRM) cloud native environment by using the BRM and PDC REST services.

Topics in this document:

Configuring BRM REST Services Manager

You use BRM REST Services Manager to integrate an external customer experience application with BRM. This allows you to manage billing and rating in BRM and then view your customers' account balances and bills in your external client. For more information, see REST Services Manager API for Billing and Revenue Management.

To configure BRM REST Services Manager in BRM cloud native:

  1. Generate an SSL certificate. See "Generating an SSL Certificate for BRM REST Services Manager".

  2. Optionally, configure the BRM REST Services Manager SDK. See "Configuring the SDK (Optional)".

  3. If BRM and REST Services Manager are located in separate clusters, connect BRM REST Services Manager to BRM. See "Connecting to a Separate BRM Cluster".

  4. Override the BRM REST Services Manager-specific keys in the values.yaml file. See "Adding BRM REST Services Manager Keys".

  5. Optionally, configure policies for authorizing calls to the BRM REST Services Manager REST API endpoints. See "Configuring Policies for API Authorization".

  6. Optionally, override the default mappings between BRM REST Services Manager JSON payload objects and BRM opcode flists. See "Configuring and Adding Custom Mapper Files".

  7. Optionally, the Kafka notification framework for BRM REST Services Manager. See "Configuring and Deploying Notification Framework".

Generating an SSL Certificate for BRM REST Services Manager

The following shows the steps for generating a sample SSL certificate:

  1. Create a directory named rsm_keystore under the oc-cn-helm-chart/rsm directory.

  2. Generate an SSL certificate. For example:

    openssl req -x509 -newkey rsa:4096 -keyout openSSLKey.pem -out cert.pem -days 365 -nodes

  3. Generate a PKCS12 KeyStore file. For example, this creates a KeyStore file named keystore.p12: 

    openssl pkcs12 -export -out keyStore.p12 -inkey openSSLKey.pem -in cert.pem

  4. Copy your SSL certificate file to the oc-cn-helm-chart/rsm/rsm_keystore directory.

Configuring the SDK (Optional)

To integrate the SDK with BRM REST Services Manager, generate an SDK image as follows:

  1. Copy your extended SDK JAR oc-cn-docker-files-15.2.x.x.x/oc-cn-docker-files/ocrsm/brm_rest_services_manager/SDK/libs to the oc-cn-docker-files-15.2.x.x.x/oc-cn-docker-files/ocrsm/brm_rest_services_manager/SDK directory.

    Note:

    The SDK JAR can be used directly from oc-cn-docker-files-15.2.x.x.x/oc-cn-docker-files/ocrsm/brm_rest_services_manager/SDK/libs if no changes are required. If you need to make further customizations, follow the instructions in REST Services Manager API for Billing and Revenue Management and then copy the updated SDK JAR to the oc-cn-docker-files-15.2.x.x.x/oc-cn-docker-files/ocrsm/brm_rest_services_manager/SDK directory.

  2. In your override-values.yaml file for oc-cn-helm-chart, set the ocrsm.rsm.configEnv.rsmExtensionJar key to the name of your extended SDK JAR file, such as BRMRESTExtension.jar.

  3. Go to the oc-cn-docker-files-15.2.x.x.x/oc-cn-docker-files/ocrsm/brm_rest_services_manager/SDK directory.

  4. Build the Podman image by running this command:

    podman build --format docker --tag imagerepo/brm-rest-services-manager-extension:1 .

  5. Push the SDK image to the repository by running this command:

    podman login --username user --password password imagerepo  
podman push imagerepo/brm-rest-services-manager-extension:1

Connecting to a Separate BRM Cluster

If BRM is located in a separate cluster from BRM REST Services Manager, do the following to connect BRM REST Services Manager to BRM:

  1. Open the configmap_env_brmrsm.yaml file in a text editor.

  2. Set BRM_HOST_NAME to the host name of the cluster on which BRM is located. The default value is cm.

  3. Save and close the file.

Adding BRM REST Services Manager Keys

Table 8-1 lists the keys that directly impact BRM REST Services Manager. Add these keys to your override-values.yaml file with the same path hierarchy.

Caution:

Keys with the path ocrsm.rsm.secretVal hold sensitive data. Handle them carefully with controlled access to the override file containing their values. Encode all of these values in Base64. See "Secrets" in Kubernetes Concepts.

Table 8-1 BRM REST Services Manager Keys

Key Path in Values.yaml File Description

isEnabled

ocrsm.rsm

Whether to deploy BRM REST Services Manager with BRM cloud native (true) or not (false). The default is true.

labels.*

ocrsm.rsm

 The string used to form the names of BRM REST Services Manager.

deployment.*

ocrsm.rsm

The details for deploying BRM REST Services Manager.

  • deadlineSeconds: The maximum time, in seconds, for a deployment to make progress before it is considered failed. The default is 120.

  • revisionHistLimit: The maximum number of old ReplicaSets for this deployment to retain. The remaining is garbage-collected in the background. The default is 10.

  • imageName: The name of the BRM REST Services Manager image, such as oracle/brm-rest-services-manager.

  • imageTag: The tag associated with the image, such as :15.2.0.0.0.

sdk.*

ocrsm.rsm.deployment

The details about the BRM REST Services Manager SDK.

  • imageName: The name of the BRM REST Services Manager SDK image.

  • imageTag: The tag associated with the BRM Services Manager SDK image, such as :1.

probe.ready.*

ocrsm.rsm.deployment

The configuration for the readiness probe.

  • delayInSec: The duration, in seconds, to wait before performing the first readiness probe. The default is 30.

  • intervalInSec: How often, in seconds, to perform the readiness probe. The default is 5.

  • maxAttempts: The maximum number of consecutive failures before the probe is considered failed. The default is 15.

REST Services Manager Volumes

ocrsm.rsm.deployment

The details about the REST Services Manager volumes.

  • volMntKeyStore.name: The volume containing the BRM REST Services Manager SSL KeyStore certificate.

  • volMntLogs.name: The name of the log volume mount where the SDK JAR is mounted.

  • volMntSDK.name: The name of the SDK volume mount where the SDK Jar is mounted.

  • volMntSecretEnv.name: The name of the volume mount that holds all passwords as a Secret.

  • volMntSecurity.*: The name and path of the volume mount containing the server security.

  • volMntAppExternalProperties.*: The name and path of the volume mount containing the application's external properties.

configEnv.*

ocrsm.rsm

The configuration details for the BRM REST Services Manager API.

  • name: The name of the BRM REST Services Manager API ConfigMap. The default is brm-rest-services-manager-env-configmap.

  • httpPort: The HTTP port in the container on which to deploy BRM REST Services Manager. The default is 9090.

  • httpsPort: The HTTPS port in the container on which to deploy BRM REST Services Manager. The default is 8080.

  • adminPort: The administration port for health, metrics, and other administration-related activities. The default is 9060.

  • tlsVersions: The list of TLS versions to support for connection with the WebLogic domain. List the version numbers in order, from lowest to highest, separated by a comma. For example: TLSv1.2, TLSv1.3.

  • rsmCertificateFileName: The SSL certificate file name for BRM REST Services Manager.

  • trustStoreFileName: This is the optional file name for the TrustStore. Set this key if the default Java TrustStore needs to be overridden.

infranet.*

ocrsm.rsm.configEnv

The details for connecting to BRM cloud native.

  • user.login: The login name of the service with permissions to access BRM.

  • user.serviceType: The POID type for the service having permissions to access BRM.

  • user.serviceId: The POID of the service having permissions to access BRM.

  • connectionpool.minSize: The minimum number of threads in the connection pool.

  • connectionpool.maxSize: The maximum number of threads in the connection pool.

  • PcmTimeoutInMsecs: The duration, in milliseconds, the PCM waits before timing out.

  • login.type: Whether a login name and password are required to connect to the BRM database (1) or not (0). The default is 1.

brmSSLWalletFileName

ocrsm.rsm.configEnv

The BRM SSL wallet file name. The default is cwallet.sso.

rsmExtensionJar

ocrsm.rsm.configEnv

The file name of the BRM REST Service Manager SDK JAR, such as BRMRESTExtension.jar.

bipURL

ocrsm.rsm.configEnv

The Oracle Analytics Publisher URL.

bipUserId

ocrsm.rsm.configEnv

The Oracle Analytics Publisher user ID.

Zipkin Tracing Details

ocrsm.rsm.configEnv

The Zipkin tracing details.

  • isTracingEnabled: Whether to enable tracing for the BRM REST Services Manager API (true) or not (false). The default is false.

  • zipkinHostName: The host name of the Zipkin tracing collector.

  • zipkinPort: The port of the Zipkin tracing collector.

  • zipkinProtocol: The protocol of the Zipkin tracing collector, such as http or https.

BRM REST Services Manager Cache Details

ocrsm.rsm.configEnv

The cache details.

  • baseURL: The base URL with resource details to return in the response of BRM REST Services Manager requests.

    Note: After deployment, you can update this value by editing your override-values.yaml file and then doing a Helm upgrade.

  • cacheEnabled: Whether BRM REST Services Manager supports an internal cache (true) or not (false). The default is false.

  • cacheType: The cache type: private or public. The default is private.

  • cacheMaxAge: The time, in seconds, that the response remains fresh in cache after the response is generated. The default is 86400.

  • cacheServices: The services that need to provide cache support. The default is describe, which is the resource locator for the Describe API in the REST API path.

securityEnabled

ocrsm.rsm.configEnv

The flag to indicate if token-based authentication is enabled for BRM REST Services Manager (true) or not (false). The default is true.

oidc.*

ocrsm.rsm.configEnv

The Identity Provider (IdP) authentication details.

  • identity-uri: The URI of the Identity Server, used as the base URL to retrieve metadata from the Identity Server.

  • client-id: The client ID generated by the Identity Server, used to validate the token.

  • client-secret: The client secret generated by the Identity Server, used to authenticate the application when requesting a JWT based on a code. Do not set this key directly. Instead, specify the client secret password under the secretVal.clientSecret key.

  • proxyHost: The proxy host of the IdP, if defined. When set, this triggers the use of a proxy for HTTP requests.

  • scope-audience: The audience for the scope required by this application. This is prefixed to the scope name when requesting scopes from the Identity Server.

  • audience: The secondary audience configured in the IdP. If no secondary audience is configured, use the primary audience, which is the same as the scope-audience.

  • introspect-endpoint-uri: The endpoint URI used to validate the JWT.

roleMapperName

ocrsm.rsm.configEnv

To authorize requests, specify a mapper based on your Identity Provider (IdP): use idcs-role-mapper for Oracle IDCS or oam-role-mapper for Oracle Access Manager.

This step is necessary when your JSON Web Tokens (JWTs) do not adhere to the MicroProfile JWT RBAC v2.1 specification and lack a "groups" claim because it enables fetching user/client groups and roles. If your JWTs conform to the JWT RBAC v2.1 specification, leave this key empty.

oam.*

ocrsm.rsm.configEnv

The Oracle Access Manager authentication details. These keys ensure backward compatibility for users who have not yet migrated to the latest versions of Oracle Access Management, where roles and groups are included in the JWT token.

Note: This section is enabled only if roleMapperName is set to oam-role-mapper.

  • oudHostName: The Oracle Unified Directory host name.

  • oudRootUserDN: The Oracle Unified Directory root user domain name.

  • oudHttpPort: The Oracle Unified Directory HTTP port.

  • oudHttpsPort: The Oracle Unified Directory HTTPS port.

  • oudUserBaseDN: The Oracle Unified Directory user domain name.

  • oudGroupDN: The Oracle Unified Directory group domain name.

  • msgType: The message type based on the schema used to search roles in the Oracle Unified Directory.

  • filter: The filter based on the user attribute.

Log Level Details

ocrsm.rsm.configEnv

The logging level. The possible values for these keys are: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST.

  • logLevel: The application log level.

  • helidonSecurityLogLevel: The Helidon security log level.

  • helidonWebServerLogLevel: The Helidon WebLogic server log level.

  • helidonConfigLogLevel: The Helidon configuration log level.

  • helidonMicroProfileLogLevel: The Helidon MP log level.

  • helidonCommonLogLevel: The Helidon common log level.

  • nettyServerLogLevel: The embedded netty server log level.

  • jerseyLogLevel: The Jersey log level.

  • jbossWeldLogLevel: The Helidon JBossWeld log level.

  • auditLogLevel: The audit log level.

jvmOpts

ocrsm.rsm.configEnv

The Java options to configure when setting resources for the containers, such as heap memory. For example:

-XX:InitialRAMPercentage=25.0 -XX:MaxRAMPercentage=50.0.

extKeystoreSecret

ocrsm.rsm.secretKeyStore

The name of the external Kubernetes Secret containing the Identity and Trust files.

Note: Override the rsmCertificateFileName, trustStoreFileName, and keyStoreFileName with the respective names of the TrustStore and KeyStore.

See "Secrets" in Kubernetes Concepts, and "About Using External Kubernetes Secrets" in BRM Cloud Native System Administrator's Guide.

secretVal.*

ocrsm.rsm

The credentials for accessing the system.

  • name: The name of the Kubernetes Secret that copies certificates to the container. The default is brm-rest-services-manger-env-secret.

  • rsmCertificatePassword: The Base64-encoded certificate password for BRM REST Services Manager.

  • brmInfranetWalletPassword: The Base64-encoded wallet password. You can use any password. This password will be used to store the Oracle Analytics Publisher and Infranet connections in the wallet and can be used to access the same.

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

  • clientSecret: The Base64-encoded IDCS client secret.

  • trustStorePassword: The TrustStore file password.

secret.*

ocrsm.rsm

The details about BRM REST Services Manager Secrets:

  • extBrmRsmPasswordSecret: The name of the external Secret that stores all passwords.

  • extBrmRestServicesManagerSslSecret: The name of the external Secret that copies certificates to the container.

  • extBrmRsmProfileEnvSecret: The name of the external Secret that stores all profile passwords.

See "About Using External Kubernetes Secrets" in BRM Cloud Native System Administrator’s Guide.

affinity

ocrsm.rsm

The rules for scheduling pods on particular nodes using more powerful selectors using affinity rules.

nodeSelector

ocrsm.rsm

The rules for deploying the pod on specific nodes.

addOnPodSpec

ocrsm.rsm

The details for extending pod specification or overriding features. By default, this key is empty.

resources.*

ocrsm.rsm

The minimum and maximum CPU and memory resources that containers can use.

See "Setting Minimum and Maximum CPU and Memory Values" in BRM Cloud Native System Administrator's Guide.

hpa.*

ocrsm.rsm

The details for scaling up or down the number of pod replicas in your deployment based on a pod's CPU or memory utilization. By default, the Horizontal Pod Autoscaler is disabled.

See "Setting Up Autoscaling of BRM Pods" in BRM Cloud Native System Administrator's Guide.

service.*

ocrsm.rsm

The brm-rest-services-manager service's details.

  • name: The name of the service: brm-rest-services-manager.

  • type: The service type. The default is ClusterIP.

mapperConfiguration

ocrsm.rsm

This contains the Mapper Configuration keys which are required for the APIs and events that use mapper framework. See "Configuring and Adding Custom Mapper Files" for more information.

consumers.*

ocrsm.rsm

The required consumers details of kafka and data base for consuming the events respectively.

Note: Uncomment or add the required configurations to work with event notifications.

producer.*

ocrsm.rsm

The required producer details of kafka connection in order to get the event messages.

Note: Uncomment or add the required configurations in order to work with event notifications.

connection-profiles.*

ocrsm.rsm

The required coonnection-profile details of kafka and data base for secure connection.

Note: uncomment or add the required configurations in order to work with event notifications

You can use the following commands to encode and decode passwords in Base64 format:

  • To encode strings in Linux:

    echo -n 'password' | base64

  • To decode strings in Linux:

    echo 'encoded_password' | base64 --decode

Configuring Policies for API Authorization

To configure the policies for API authorization:

  1. Define the API authorization rules in a policy file.

    You can use the sample authorization policy ConfigMap (configmap_auth_policy_brmrsm.yaml) as a template for defining API authorization rules.

  2. For any new BRM REST Services Manager API endpoints, ensure that appropriate policy statements are added to the file. This is essential for enforcing proper authorization and access restrictions for each new API.

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

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

Configuring and Adding Custom Mapper Files

By default, BRM REST Services Manager uses predefined mapper files to translate between JSON payload objects and BRM opcode flists for the latest versions of account and inventory management. However, you can customize this mapping by creating and adding your own mapper files. This allows you to extend or override the default mappings to meet your specific integration needs.

To introduce custom mapping logic for REST API payloads, extend or override the mapping between BRM REST Services Manager JSON objects and BRM opcode flists:

  1. Draft your customization as one or more YAML files. Follow the same structure as the sample files in oc-cn-helm-chart/rsm/referenceMappers.

    The following example shows how to map a custom payload field (PIN_FLD_CUSTOM) for the Create a Product REST API request:

    mapper:
    custom:
        v5:
            tmf637:
                productCreateEvent:
                   product:
                     request:
                       jsonCustomField:
                             field: PIN_FLD_CUSTOM_FIELD
                             fieldValue: "" 
                             optional: false
                             validation: "enum:[inactive, active, cancelled]"
  2. Add your custom YAML files to the BRM REST Services Manager deployment by doing one of the following:
    • Create a ConfigMap from a single YAML file:
      kubectl create configmap ConfigMapName --from-file=YamlFileName -n BrmNameSpace
      where:

      • ConfigMapName is the name of the ConfigMap to create.

      • YamlFileName is the path to your custom YAML file.

      • BrmNameSpace is the BRM Kubernetes namespace.

    • Create a ConfigMap from all YAML files in a directory:
      kubectl create configmap ConfigMapName --from-file=. -n BrmNameSpace

      Note:

      Run all commands from the directory containing the file.

    • Add your custom YAML files to the BRM REST Services Manager deployment without pre-creating a ConfigMap. Place files of size upto 1 MiB in the oc-cn-helm-chart/rsm/extendedMappers. Place larger files in SDK/extendedMappers within the SDK project, and supply the SDK image to REST Services Manager. Use the existing REST Services Manager packaging steps to build and provide the SDK image to RSM.

    Note:

    All methods are for mapper files less than 1MiB. You can use SDK to create custom mapper files larger than 1 MiB.

  3. Provide the path from your custom mapper files as requests, responses, or execute respectively. Update the override_values.yaml: 
    ocrsm:
     rsm:
        mapperConfiguration:
            config:
              paths:
                event:
                  v5:
                    ProductCreateEvent:
                      mapper-specification-keys:
                        default: Product
                        Event:
                          execute:
                            - "mapper.brm.v5.tmf637.productCreateEvent.execute"
                          request:
                            - "mapper.brm.v5.tmf637.productCreateEvent.request"
                          response:
                            - "mapper.brm.v5.tmf637.productCreateEvent.response"
                            - "mapper.custom.v5.tmf637.productCreateEvent.response"
                        Product:
                          request:
                            - "mapper.brm.v5.tmf637.post.request.product"
                            - "mapper.brm.v5.tmf637.post.request.extendedProduct"
                            - "mapper.custom.v5.tmf637.post.request.product"
                          response:
                            - "mapper.brm.v5.tmf637.post.response.product"
                            - "mapper.brm.v5.tmf637.post.response.extendedProduct"
                            - "mapper.custom.v5.tmf637.post.response.product"
    where,
    • ProductCreateEvent defines the type of event.
    • mapper-specification-keys specifies logical profiles or mapping variants.
    • default is used when no explicit profile is provided.
    • execute, request, and response designate the mapping configuration files to be applied for execution opcode, request transformation, and response transformation respectively.
  4. Update the following keys in your override_values.yaml file for oc-cn-helm-chart:

    • ocrsm.rsm.externalExtendedMapper: If you created a ConfigMap, set this to the name of the ConfigMap you created in step 2.

    • ocrsm.rsm.configEnv.restartVersion: Increment this value by one and run the helm upgrade to force restart and initialize the changes.

    Note:

    For more information on Mapper keys, refer to "Table 8-1"

  5. Run the helm upgrade command for oc-cn-helm-chart:
    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

Configuring and Deploying Notification Framework

BRM supports a notification framework for event-driven integration. This framework uses Kafka to decouple event producers and consumers, enabling reliable, scalable, and secure event processing between BRM and external systems.

To configure and deploy the notification framework, consult the following topics:

Notification Framework Prerequisites
Before you begin configuration, ensure that your environment satisfies all prerequisites for the REST Services Manager Notification Service. This section lists the required Kafka infrastructure, Oracle database wallet setup, and configuration file requirements.

Note:

In order to get event notifications, uncomment or add the required configurations as shown in this document.

Kafka Cluster and Topic requirements
  • Provision a Kafka cluster with sufficient brokers to meet your throughput and high availability requirements.
  • Define all topics required for the REST Services Manager Notification Service, including source, sink, retry, and dead-letter queue (DLQ) topics.
  • Ensure topics are created with the desired number of partitions and that appropriate access control lists (ACLs) are applied.
  • Record the host names and port numbers of all Kafka brokers.
  • Monitor Kafka server logs from time to time to validate if the connections are established.
Oracle Database Wallet Setup for Sensitive Values
  • Configure an Oracle database wallet to securely store sensitive credentials, such as SSL passphrases, KeyStore and TrustStore files, and database schema credentials.
  • The contents of the Oracle Database Wallet with security certificates is dependent on the database listener and instance being preconfigured for SSL/TLS. Ensure that the database encryption layer is active before attempting to map KeyStore and TrustStore locations within the wallet.
  • Store the necessary wallet files and KeyStore and TrustStore files for secure connection to the database in a location secured with appropriate file permissions.
  • Do not place passwords or secrets in plain configuration files.
REST Services Manager Notification Service Configuration Process

This section outlines the end-to-end workflow for configuring and setting up the Notification Service. Steps include extracting delivery packages, editing configuration files, and securely applying SSL/SASL parameters are needed for Kafka broker connectivity.

To configure and deploy Kafka, Oracle database consumers, and kafka producers:

  1. Open the override-values.yaml file for editing.

  2. Un-comment the sections relevant to your deployment:
    • Specify the active connection profiles.
    • Specify the active consumer and producer profiles.

  3. Populate connection parameters for Kafka and any required databases.

  4. Apply the appropriate SSL/SASL parameters to secure broker access.

  5. Store the secrets in a base64-encoded format in the override-value.yaml file to add them to the wallet during runtime.

  6. Save the configuration and verify all folder paths referenced in override-values.yaml exist and are accessible by the REST Services Manager process.

  7. Start REST Services Manager application to start the notification services using the Helm upgrade command.

To apply broker SSL/SASL parameters and store passphrases securely:
  • Enter SSL configurations (keystore, truststore locations and types, passwords) in override-values.yaml, using wallet references.
  • Do not write plain credentials in configuration files.
Configuring Notification Framework Components

The Notification Framework provides the foundation for integrating event-driven communications between Oracle BRM and external systems or services. This section outlines the required configuration components—including connection profiles, consumer and producer properties, event mappings, and associated security options—necessary to enable reliable, scalable, and secure event processing. By following the configuration steps described in the following subsections, you ensure that all Notification Framework components interoperate correctly in your cloud native BRM deployment.

Setting Up Connection Profiles

Configure the Kafka and database connection profiles by mapping related parameters and integrating with your wallet-based secrets. Guidance covers property definitions and secure reference of credential values in the configuration.

Kafka Connection Profile
  • Set security protocol such as SSL or SASL_SSL under the properties tag.
  • Assign locations and types for keystore and truststore files.
  • Specify credentials via wallet or environment variable references.

Example block for Kafka connection profiles in the REST_home/scripts/override-values.yaml

connection-profiles:
     - id: "cp1"
       profile-type: "kafka"
       host: "host"
       port: port
       username: ""
       password: "base64-encoded password"
       truststore-type: PKCS12
       truststore-name: "truststore.p12"
       truststore-password: "base64-encoded password"
       keystore-type: PKCS12
       keystore-name: "keystore.p12"
       keystore-password: "base64-encoded password"
       properties:
         auto.offset.reset: latest
         enable.auto.commit: false
         session.timeout.ms: 60000
         heartbeat.interval.ms: 10000
         connections.max.idle.ms: 3600000
         max:
           poll:
             records: 10
             interval.ms: 600000
           partition.fetch.bytes: 1048576
         acks: all
         retries: 3
         batch.size: 16384
         linger.ms: 1
         buffer.memory: 33554432
         compression.type: none

where,

  • id is the unique identifier for the connection profile, referenced by consumers or producers to select this profile.

  • profile-type is the type of connection; set to "kafka" for Kafka connections.

  • host is the address of the Kafka broker to connect to.

  • port is the network port used to connect to the Kafka broker.

  • username is the authentication username, if required for SASL or similar authentication mechanisms (often left empty for SSL-only setups).

  • password is the key referencing the base64-encoded password (e.g., stored in the Wallet) for authenticating this profile.

  • truststore-type is the type of the truststore file (usually PKCS12 or JKS) used for SSL/TLS connections.

  • truststore-name is the truststore file name containing trusted certificate authorities.

  • truststore-password is the key to retrieve the truststore base64-encoded password (e.g., stored in the Wallet), ensuring secure access.

  • keystore-type is the type of the keystore file (usually PKCS12 or JKS) holding client SSL certificates.

  • keystore-name is keystore file name containing the client’s SSL certificate and private key.

  • keystore-password is the key to retrieve the keystore base64-encoded password (e.g., stored in the Wallet), ensuring secure access.

  • properties is an object containing additional Kafka client properties (such as offsets, timeouts, batching, etc.). It follows standard kafka properties so the key and value must be as per standard kafka documentation guidelines.

    • auto.offset.reset determines where to start consuming if no offset is committed ("latest" starts from the latest message).

    • enable.auto.commit specifies if the consumer should auto-commit offsets (set to false for manual management).

    • session.timeout.ms sets the timeout in milliseconds to detect consumer failures.

    • heartbeat.interval.ms sets how often to send heartbeats to the Kafka broker.

    • connections.max.idle.ms sets the maximum idle time for a connection before closing.

    • max.poll.records sets the maximum number of records returned in a single poll.

    • max.poll.interval.ms sets the maximum interval between poll calls before the broker considers the consumer failed.

    • max.partition.fetch.bytes controls the maximum bytes per partition fetched in a request.

    • acks defines the number of acknowledgments the producer requires for a request (e.g., "all" for full commit).

    • retries is the maximum number of retry attempts for failed produce requests.

    • batch.size sets producer batch memory size in bytes.

    • linger.ms delays sending records to allow batching (in milliseconds).

    • buffer.memory is the total producer buffer memory in bytes.

    • compression.type sets the compression algorithm to use ("none", "gzip", etc.).

Example block for database connection profiles in the REST_home/scripts/override-values.yaml

     - id: "cp2"
       profile-type: "database"
       host: "host"
       port: port
       truststore-type: PKCS12
       truststore-name: "truststore.p12"
       truststore-password: "base64-encoded password"
       keystore-type: PKCS12
       keystore-name: "keystore.p12"
       keystore-password: "base64-encoded password"
       properties:
         service-name: pindb.us.oracle.com

where,

  • service-name is the specific name of the database service (or SID) to which the connection should be established.

Note:

Store all the keystore or truststore files and wallet files in the oc-cn-helm-chart/rsm/rsm_keystore directory.

Setting up Consumers

Example block for kafka consumers in the REST_home/scripts/override-values.yaml

consumers: 
     - connection-profile-id: "cp1"
       properties:
         group.id: cgroup-brmrsm-productInventory
       configuration:
         max-retries: 3
         retry-delay-interval-ms: 1000
         record-fetch-timeout-ms: 1000
         brm-connection-retry-interval-ms: 30000
         strict-ordering: false
         buffer-strategy: 
       topic-event-config:
         source-topic: productInventory
         sink-topic: productInventoryRetry
         key-state-topic: keyStateTopic
         consumer-thread-count: 1
         worker-thread-count: 2
         downstream-consumers:
           - connection-profile-id: "cp1"
             properties:
               group.id: cgroup-brmrsm-productInventory
             configuration:
               max-retries: 3
               retry-delay-interval-ms: 1000
               record.fetch.timeout.ms: 1000
               brm.connection.retry.interval.ms: 30000
             topic-event-config:
               source-topic: productInventoryRetry
               sink-topic: productInventoryDLQ
               consumer-thread-count: 1
               worker-thread-count: 2
               events:
                 - ProductCreateEvent
                 - ProductAttributeValueChangeEvent
                 - ProductStateChangeEvent
                 - ProductDeleteEvent
         events:
           - ProductCreateEvent
           - ProductAttributeValueChangeEvent
           - ProductStateChangeEvent
           - ProductDeleteEvent
     - connection-profile-id: "cp1"
       properties:
         group.id: cgroup-brmrsm-partyAccountInventory
       configuration:
         max-retries: 1
         retry-delay-interval-ms: 1000
         record-fetch-timeout-ms: 1000
         brm-connection-retry-interval-ms: 30000
         strict-ordering: false
         buffer-strategy: 
       topic-event-config:
         source-topic: partyAccountInventory
         sink-topic: partyAccountInventoryRetry
         key-state-topic: keyStateTopic
         consumer-thread-count: 1
         worker-thread-count: 2
         downstream-consumers:
           - connection-profile-id: "cp1"
             properties:
               group.id: cgroup-brmrsm-partyAccountInventory
             configuration:
               max-retries: 1
               retry-delay-interval-ms: 1000
               record-fetch-timeout-ms: 1000
               brm-connection-retry-interval-ms: 30000
             topic-event-config:
               source-topic: partyAccountInventoryRetry
               sink-topic: partyAccountInventoryDLQ
               key-state-topic:
               consumer-thread-count: 1
               worker-thread-count: 2
               events:
                 - PartyAccountCreateEvent
                 - PartyAccountAttributeValueChangeEvent
                 - PartyAccountStateChangeEvent
                 - PartyAccountDeleteEvent
         events:
           - PartyAccountCreateEvent
           - PartyAccountAttributeValueChangeEvent
           - PartyAccountStateChangeEvent
           - PartyAccountDeleteEvent
     - connection-profile-id: "cp1"
       properties:
         group.id: cgroup-brmrsm-billingAccountInventory
       configuration:
         max-retries: 1
         retry-delay-interval-ms: 1000
         record-fetch-timeout-ms: 1000
         brm-connection-retry-interval-ms: 30000
         strict-ordering: false
         buffer-strategy: 
       topic-event-config:
         source-topic: billingAccountInventory
         sink-topic: billingAccountInventoryRetry
         key-state-topic: keyStateTopic
         consumer-thread-count: 1
         worker-thread-count: 2
         downstream-consumers:
           - connection-profile-id: "cp1"
             properties:
               group.id: cgroup-brmrsm-billingAccountInventory
             configuration:
               max-retries: 1
               retry-delay-interval-ms: 1000
               record-fetch-timeout-ms: 1000
               brm-connection-retry-interval-ms: 30000
             topic-event-config:
               source-topic: billingAccountInventoryRetry
               sink-topic: billingAccountInventoryDLQ
               key-state-topic:
               consumer-thread-count: 1
               worker-thread-count: 2
               events:
                 - BillingAccountCreateEvent
                 - BillingAccountAttributeValueChangeEvent
                 - BillingAccountStateChangeEvent
                 - BillingAccountDeleteEvent
         events:
           - BillingAccountCreateEvent
           - BillingAccountAttributeValueChangeEvent
           - BillingAccountStateChangeEvent
           - BillingAccountDeleteEvent

where,

  • connection-profile-id is the identifier referencing the Kafka connection profile used by the consumer.
  • group.id is the unique consumer group identifier for coordinating message consumption and offset management.
  • max-retries is the maximum number of retry attempts for processing an event before routing it to the retry or DLQ topic.
  • retry-delay-interval-ms is the delay in milliseconds between retry attempts after a processing failure.
  • record-fetch-timeout-ms is the maximum time in milliseconds the consumer waits for records during a fetch operation. (Also appears as record.fetch.timeout.ms.)
  • brm-connection-retry-interval-ms is the interval in milliseconds to wait between attempts to reconnect to BRM services. (Also appears as brm.connection.retry.interval.ms.)
  • strict-ordering is a flag indicating whether strict ordering for message keys is enforced (true or false).
  • buffer-strategy is the method used for buffering events within the consumer; implementation-specific.
  • source-topic is the Kafka topic from which the consumer reads events.
  • sink-topic is the Kafka topic to which failed events are sent for retries.
  • key-state-topic is an optional topic used to track and manage state related to message keys.
  • consumer-thread-count is the number of threads allocated for polling messages from the source topic.
  • worker-thread-count is the number of threads used for processing polled events.
  • downstream-consumers is a list of additional consumer stages for retry or DLQ handling, each with its configuration.
  • events is the list of event types that the consumer instance is configured to process (e.g., ProductCreateEvent, PartyAccountDeleteEvent).

Note:

  • It is recommended to use different group.id for every individual consumer. However consumers in the same downstream consumer chain can have the same group.id.

  • When using multiple REST Services Manager replicas, the number of partitions in the downstream consumer chain must match the number of partitions in the parent consumer.

Example block for kafka consumers in the REST_home/scripts/override-values.yaml

     - connection-profile-id: "cp2"
       properties:
         username: ""
         password: "base64-encoded password"
         queue-name: OPEN_API_QUEUE
       wallet-name: db_wallet
       configuration:
         worker-thread-count: 1

where,

  • connection-profile-id is the identifier referencing the database connection profile to be used by this configuration.
  • username is the login name used for authenticating the connection to the database or queue.
  • password is the key used to securely retrieve the base64-encoded authentication password (such as from a Kubernetes Secret or Wallet).
  • queue-name is the name of the queue from which this consumer will read messages (e.g., for queue-based processing).
  • wallet-name is the name of the wallet or credential store where sensitive authentication information is managed.
  • worker-thread-count is the number of threads assigned for concurrent processing of messages from the queue.

Setting up Producers

Note:

Configure this to recieve the TMF events for supported API requests and supported TMF consumer events.

Example block for producers in the REST_home/scripts/override-values.yaml

 producer:
     connection-profile-id: "cp1"
     properties:
     event-topics-config:
       - event-name: "ProductCreateEvent"
         topic-names: [ "productCreateTopic", "productCreateTopic2" ]
       - event-name: "ProductDeleteEvent"
         topic-names: [ "ProductDeleteTopic" ]
       - event-name: "ProductAttributeValueChangeEvent"
         topic-names: [ "productAttributeValueTopic" ]
       - event-name: "ProductStateChangeEvent"
         topic-names: [ "productStateChangeTopic" ]
       - event-name: "PartyAccountCreateEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "PartyAccountAttributeValueChangeEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "PartyAccountStateChangeEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "PartyAccountDeleteEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "BillingAccountCreateEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "BillingAccountAttributeValueChangeEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "BillingAccountStateChangeEvent"
         topic-names: [ "partyAccountNotificationTopic" ]
       - event-name: "BillingAccountDeleteEvent"
         topic-names: [ "partyAccountNotificationTopic" ]

where,

  • connection-profile-id is the reference to the id of a defined connection profile (such as "cp1") that the producer will use for publishing events.

  • properties is a collection of Kafka producer configuration parameters (such as acks, retries, batch size, etc.), set to control behavior of the producer and optimize performance, reliability, and security. These properties will override the connection-profile properties if they are configured.

  • event-topics-config is a list that maps each event name to one or more Kafka topics to which the event will be published.

  • event-name is the identifier for a specific business event type that will be produced and routed by this producer (e.g., "ProductCreateEvent").

  • topic-names is the list of one or more Kafka topics to which messages for the corresponding event-name are published.

Completing Post-Installation Tasks

After deployment, validate the service using logs and functional checks. Customize event handling with mapper overrides if required and follow the correct procedure for restarting the REST Services Manager Notification Service after any configuration change.

To validate deployment and check logs:

  1. Inspect the log directory for startup messages.

  2. Confirm the service connects to Kafka brokers and joins the expected consumer group(s).

  3. Verify correct topic subscriptions and successful offset commits.

To restart REST Services Manager:

  • After any configuration or credential change, restart the REST Services Manager Notification Service to load the updated settings and wallet entries.

  • Use Helm upgrade to restart the services. Stop the BRM REST Services Manager by running the REST_home/scripts/stop-brm-rsm.sh script. Start the BRM REST Services Manager by running the REST_home/scripts/start-brm-rsm.sh script.

Performing Verification and Sanity Checks

Conduct a series of checks to ensure all topics, partitions, security settings, and service connections are correct. This section includes procedures for performing functional connectivity testing and verifying end-to-end message flow.

Perform checks to validate the REST Services Manager Notification Service deployment:

  • Confirm all topics, partitions, and ACLs are present in Kafka.

  • Ensure consumers join the correct consumer group and receive partition assignments.

  • Check that the service successfully establishes SSL or SASL connections to brokers.

  • Run test messages through the pipeline to validate end-to-end message flow.

  • Use built-in scripts to verify wallet entry references and keystore integrity.

Security Best Practices for REST Services Manager Notification Service

Adhere to recommended security practices for storage and handling of credentials. This section summarizes wallet usage, credential rotation, file permissions, and compliance alignment.

To maintain a secure deployment:

  • Store all credentials, passphrases, and secrets in the Oracle wallet. Never use plain text or version control for secret values.

  • Limit file permissions on wallet and keystore files to only necessary service accounts.

  • Rotate credentials and certificates periodically, updating the wallet, and restart services after changes.

  • Do not disable SSL endpoint identification unless explicitly required and with a formal risk assessment.

  • Ensure your deployment always aligns with Oracle security and compliance policies.

Configuring PDC REST Services Manager

You use PDC REST Services Manager to integrate an enterprise product catalog, such as Oracle Digital Experience for Communications Launch Experience, with PDC. This enables you to create a variety of product offerings in your enterprise product catalog and then have all of the rating and billing performed by PDC and BRM. For more information, see "About PDC REST Services Manager" in PDC REST Services Manager Integration Guide.

To configure PDC REST Services Manager in BRM cloud native:

  1. Override the PDC REST Services Manager-specific keys in the values.yaml file. See "Adding PDC REST Services Manager Keys".

  2. Configure OAuth authentication:

    1. If you are using Oracle Access Management for OAuth, create an identity domain, resource server, and OAuth client for PDC REST Services Manager in Oracle Access Management as described in "Setting Up OAuth for PDC REST Services Manager with Oracle Access Management" in BRM Security Guide.

    2. Configure the keys in the override-values.yaml file for OAuth with either Oracle Identity Cloud Service or Oracle Access Management as described in "Configuring OAuth Authentication in PDC REST Services Manager".

  3. Configure outbound communication to the enterprise product catalog. See "Configuring Requests to the Enterprise Product Catalog".

  4. Enable TLS encryption in PDC REST Services Manager to secure the communications it receives from your enterprise product catalog. See "Enabling TLS in PDC REST Services Manager".

  5. Enable the T3S protocol in PDC REST Services Manager to secure its communications to PDC. See "Enabling T3S in PDC REST Services Manager".

  6. Map TMF620 priceType values to BRM events to ensure that PDC REST Services Manager triggers the correct charging events for your pricing components. See "Configuring Mapping of TMF620 priceType to BRM Events".

Adding PDC REST Services Manager Keys

Table 8-2 lists the keys that directly impact PDC REST Services Manager. Add these keys to your override-values.yaml file with the same path hierarchy.

Caution:

Keys with the path ocpdcrsm.secretValue hold sensitive data. Handle them carefully with controlled access to the override file containing their values. Encode all of these values in Base64. See "Secrets" in Kubernetes Concepts.

Table 8-2 PDC REST Services Manager Keys

Key Path in Values.yaml File Description

isEnabled

ocpdcrsm

Whether to enable and deploy PDC REST Services Manager with BRM cloud native (true) or not (false). The default is false.

labels.name

ocpdcrsm

The string used to form the names of PDC REST Services Manager. The default is pdcrsm.

deployment.*

ocpdcrsm

The details for deploying PDC REST Services Manager.

  • deadlineSeconds: The maximum time, in seconds, for a deployment to make progress before it is considered failed. The default is 60.

  • revisionHistLimit: The maximum number of old ReplicaSets for this deployment to retain. The remaining will be garbage-collected in the background. The default is 10.

  • imageName: The name of the PDC REST Services Manager image, such as oracle/pdcrsm.

  • imageTag: The tag associated with the image, such as :15.2.0.0.0.

  • imagePullPolicy: When to pull images: only when one is not present locally (IfNotPresent) or always (Always). The default is IfNotPresent.

  • rootLogLevel: The root log level. The default is INFO.

  • appLogLevel: The application log level. The default is INFO.

  • JAVA_OPTS: The Java options to configure.

  • JAVA_MEM_OPTS: The Java memory options to configure.

resources.*

ocpdcrsm.deployment

The minimum and maximum CPU and memory resources that containers can use.

See "Setting Minimum and Maximum CPU and Memory Values" in BRM Cloud Native System Administrator's Guide.

configEnv.*

ocpdcrsm

The configuration details for the PDC REST Services Manager.

  • name: The name of the PDC REST Services Manager API ConfigMap. The default is pdcrsm-configmap-env.

  • rsmListenerPort: The HTTPS port number assigned to listen for API requests from the enterprise product catalog. The default is 8080.

  • baseUrl: The base URL with resource details to return in the response of PDC REST Services Manager requests.

    Note: After deployment, you can update this value by editing your override-values.yaml file and then doing a Helm upgrade.

  • useT3s: Whether to use T3s for the connection to PDC (true) or not (false). The default is true.

  • securityEnabled: Whether to enable token-based authentication for PDC REST Services Manager (true) or not (false).

  • securityType: Which OAuth provider to use for token-based authentication. Set this to oam for Oracle Access Management or idcs for Oracle Identity Cloud Service.

idcs.*

ocpdcrsm.configEnv

The Oracle Identity Cloud Service (IDCS) authentication details.

  • inboundOauthUri: The PDC REST Services Manager inbound OAuth base URI.

  • inboundOauthClientId: The PDC REST Services Manager client ID for inbound OAuth.

  • inboundOauthFrontendUri: The front end URI for inbound OAuth.

  • inboundOauthAudience: The primary audience for inbound OAuth.

  • inboundOauthProxyHost: The proxy host for inbound OAuth, if required.

  • inboundOauthPubEventScope: The scope required to access the TMF 620 Publish Event endpoint for inbound OAuth.

  • inboundOauthMetricsScope: The scope required to access the metrics endpoint for inbound OAuth.

oam.*

ocpdcrsm.configEnv

The Oracle Access Manager authentication details.

  • domainName: The Oracle Access Manager domain name.

  • audience: The name of the Oracle Access Manager OAuth server.

  • endpointURL: The OAuth token endpoint for Oracle Access Manager.

  • introspectendpointuri: The introspect endpoint for Oracle Access Manager.

  • scopeaudience: The OAuth scope audience for Oracle Access Manager.

  • authorizationendpointuri: The OAuth authorization endpoint for Oracle Access Manager.

  • proxyhost: The OAuth proxy host for Oracle Access Manager.

  • frontenduri: The OAuth front end URI for Oracle Access Manager.

isTracingEnabled

ocpdcrsm.configEnv

Whether to enable tracing for the PDC REST Services Manager API (true) or not (false). The default is false.

isTlsEnabled

 ocpdcrsm.configEnv

Whether to enable TLS encryption for PDC REST Services Manager (true) or not (false). The default is false.

tlsVersions

 ocpdcrsm.configEnv

The list of supported TLS versions, such as TLSv1.2,TLSv1.3.

tlsCertificateFile

 ocpdcrsm.configEnv

The path to the TLS certificate bundle relative to the Helm chart. The certificate must be in PKCS12 format. Ensure that the certificate file in the rsm directory.

extPDCRSMTlsSecret

ocpdcrsm.configEnv

The name of the pre-created Kubernetes Secret for the custom TLS certificate.

See "About Using External Kubernetes Secrets" in BRM Cloud Native System Administrator's Guide.

httpClients.*

ocpdcrsm.configEnv

The details for configuring the HTTP client.

nodeSelector

ocpdcrsm.configEnv

The rules for deploying the pod on specific nodes.

affinity

ocpdcrsm.configEnv

The rules for running the pod on specific nodes. Set this key if you want to constrain the pod to run only on the nodes that meet your criteria. For more information about this key, see "Node Affinity" in the Kubernetes documentation.

addOnPodSpec

ocpdcrsm.configEnv

The details for extending pod specification or overriding features. By default, this key is empty.

monitoring.prometheus*

ocpdcrsm.configEnv

The details for monitoring PDC REST Services Manager.

  • isEnabled: Whether you are using Prometheus Operator to monitor PDC REST Services Manager (true) or not (false). The default is false.

  • namespace: The namespace in which to deploy Prometheus Operator. The default is monitoring.

secretValue.*

ocpdcrsm.rsm

The credentials for accessing the system.

  • name: The name of the Kubernetes Secret that copies certificates to the container. The default is pdcrsm-secret-env.

  • inboundOauthClientSecret: The client secret for PDC REST Services Manager inbound OAuth.

  • tlsCertificatePassphrase: The Base64-encoded passphrase for the TLS certificate.

  • httpClients.*: The HTTP client configuration.

extPdcrsmSecret

ocpdcrsm.secret

The name of the external Kubernetes Secret for the PDC REST Services Manager.

See "About Using External Kubernetes Secrets" in BRM Cloud Native System Administrator's Guide.

service.*

ocpdcrsm

Details about the pdcrsm service:

  • name: The service name: pdcrsm.

  • type: The service type. The default is ClusterIP.

  • nodePort: The external node port. The default is 31000.

    Note: The nodePort key is applicable only when the type key is set to NodePort.

Sample PDC REST Services Manager override-values.yaml Entries

The following shows sample content in the override-values.yaml for PDC REST Services Manager, when Oracle Access Management is used for OAuth authentication: 

ocpdcrsm:
    isEnabled: true
    labels:
        name: "pdcrsm"
    deployment:
        deadlineSeconds: 60
        revisionHistLimit: 10
        imageName: "oracle/pdcrsm"
        imageTag: ":15.2.0.0.0"
        imagePullPolicy: IfNotPresent
        rootLogLevel: INFO
        appLogLevel: INFO
    configEnv:
        name: "pdcrsm-configmap-env"
        rsmListenerPort: 8080
        baseURL: xxxxx.xxx.xxxxx.xxx
        useT3s: true
        securityEnabled: true
        securityType: oam
        resources:
            requests:
               cpu: "50m"
               memory: "256Mi"
            limits:
               cpu: "1000m"
               memory: "2Gi"
        oam:
            domainName: PDCRSMDomain
            audience: PDCRSMResourceServer
            endpointURL: http://oam_host:oam_port/oauth2/rest/token
            introspectendpointuri: http://oam_host:oam_port/oauth2/rest/token/info
            scopeaudience: http://oam_host:oam_port/
            authorizationendpointuri: http://oam_host:oam_port/oauth2/authorize
            proxyhost: http://proxyhost:proxyport/
            frontenduri: http://oam_host:oam_port
    secretValue:
        name: "pdcrsm-secret-env"
    service:
        name: "pdcrsm"
        type: "ClusterIP"

Configuring OAuth Authentication in PDC REST Services Manager

PDC REST Services Manager uses the OAuth 2.0 protocol to authenticate an enterprise product catalog's identity and to authorize the enterprise product catalog to access the PDC REST Services Manager API. It does this by validating an OAuth access token that is passed in the header of every HTTP/HTTPS request to the PDC REST Services Manager API.

To configure OAuth authentication in PDC REST Services Manager:

  1. Add these keys to your override-values.yaml file for oc-cn-helm-chart:
    • If you are using Oracle Identity Cloud Service (IDCS) for OAuth:
      • ocpdcrsm.configEnv.isInboundOauthEnabled: Set this to true to enable OAuth authentication.
      • ocpdcrsm.configEnv.inboundOauthUri: Set this to the base URL of your Oracle Identity Cloud Service (IDCS) instance in this format:
        https://idcs-TenantID.identity.oraclecloud.com
      • ocpdcrsm.configEnv.inboundOauthClientId: Set this to the client ID of your confidential application.
      • ocpdcrsm.secretValue.inboundOauthClientSecret: Set this to the Base64-encrypted client secret obtained from your IDCS application.
      • ocpdcrsm.configEnv.inboundOauthFrontendUri: Set this to the base URL of your confidential application when run, such as http://myapp.example.com:8080.
      • ocpdcrsm.configEnv.inboundOauthAudience: Set this to the primary audience as provisioned for the PDC REST Services Manager application in IDCS.
      • ocpdcrsm.configEnv.inboundOauthProxyHost: Set this to the host name of your proxy server, if required.
      • ocpdcrsm.configEnv.inboundOauthPubEventScope: Set this to the name of the scope for accessing the TMF620 Publish Event endpoint for inbound OAuth authentication, such as pubevent.
      • ocpdcrsm.configEnv.inboundOauthMetricsScope: Set this to the name of the scope for accessing the metrics endpoint for inbound OAuth authentication, such as metrics.
    • If you are using Oracle Access Management for OAuth:
      • ocpdcrsm.configEnv.oam.domainName: Set this to the name of the OAuth identity domain created in Oracle Access Management for PDC REST Services Manager.
      • ocpdcrsm.configEnv.oam.audience: Set this to the name of the OAuth resource server created in Oracle Access Management for PDC REST Services Manager.
      • ocpdcrsm.configEnv.oam.endpointURL: Set this to the URL for requesting an OAuth token from Oracle Access Management.
      • ocpdcrsm.configEnv.oam.introspectendpointuri: Set this to the URL for validating an OAuth token from Oracle Access Management.
      • ocpdcrsm.configEnv.oam.scopeaudience: Set this to the primary audience for PDC REST Services Manager in the Oracle Access Management resource, used for error handling. This is the same as ocpdcrsm.configEnv.oam.frontenduri, ending with /.
      • ocpdcrsm.configEnv.oam.authorizationendpointuri: The URL for authorizing role-based access. PDC REST Services Manager does not support role-based access, so this will not be used.
      • ocpdcrsm.configEnv.oam.proxyhost: Set this to the URL for your Oracle Access Management proxy server, if needed.
      • ocpdcrsm.configEnv.oam.frontenduri: Set this to the URL for of the OAuth client created in Oracle Access Management for PDC REST Services Manager.

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

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace
  3. Restart the PDC REST Services Manager pods. If downtime is not a concern, both pods can be deleted and re-created by running the following command. Otherwise, delete one pod at a time, waiting for its replacement pod to become "Running" before deleting the next one.
    kubectl -n BrmNameSpace delete pods --selector=app.kubernetes.io/name=pdcrsm

Configuring Requests to the Enterprise Product Catalog

PDC REST Services Manager sends requests to the enterprise product catalog when calling the enterprise product catalog's REST API and when publishing acknowledgment notifications.

To configure PDC REST Services Manager to send requests to the enterprise product catalog:

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

  2. Edit the keys in the file based on the type of authentication required by your enterprise product catalog:

    • For OAuth 2.0 authentication, edit the keys in Table 8-3.

      Table 8-3 OAuth 2.0 Keys

      Key Path in Values.yaml file Description

      tokenEndpoint

      ocpdcrsm.configEnv.httpClients.security.oauth2

      The endpoint used to retrieve a token from.

      clientId

      ocpdcrsm.configEnv.httpClients.security.oauth2

      The client ID used to authenticate the request from PDC REST Services Manager.

      scope

      ocpdcrsm.configEnv.httpClients.security.oauth2

      The scopes required by the enterprise product catalog.

      grantType

      ocpdcrsm.configEnv.httpClients.security.oauth2

      The grant type to be used for the OAuth flow: client_credentials or password.

      clientSecret

      ocpdcrsm.secretValue.httpClients.security.oauth2

      The encrypted client secret used to authenticate the request from PDC REST Services Manager.

      password

      ocpdcrsm.secretValue.httpClients.security.oauth2

      The encrypted password required for accessing the enterprise product catalog.

    • For basic authentication, edit the keys in Table 8-4.

      Table 8-4 basicAuth Keys

      Key Path in Values.yaml file Description

      username

      ocpdcrsm.configEnv.httpClients.security.basicAuth

      The user name required for accessing the enterprise product catalog.

      password

      ocpdcrsm.secretValue.httpClients.security.basicAuth

      		 The password required for accessing the enterprise product catalog.

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

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

  4. Restart the PDC REST Services Manager pods. If downtime is not a concern, both pods can be deleted and re-created by running the following command. Otherwise, delete one pod at a time, waiting for its replacement pod to have a "Running" status before deleting the next one.

    kubectl --namespace BrmNameSpace delete pods --selector=app.kubernetes.io/name=pdcrsm

The following shows an example configuration for OAuth 2.0 authentication.

Note:

All urlRegex values in the file must be properly escaped with \\. The characters that must be escaped are: \.[]{}()<>*+-=!? ^$|. 

configEnv:
    httpClients:
        - urlRegex: "http://hostname:port/mobile/custom/catalogManagement/.*"
          security:
              oauth2:
                  tokenEndpoint: "https://idcs_hostname/oauth2/v1/token"
                  clientId: "fcb3443f6c504ed789ba38a78341b88a"
                  scope: "https://hostnameurn:opc:resource:consumer::all"
                  grantType: "password"
secretValue:
    httpClients:
        - urlRegex: "http://hostname:port/mobile/custom/catalogManagement/.*"
          security:
              oauth2:
                  clientSecret: client_secret
                  password: password

The following shows an example configuration for Basic authentication:

Note:

All urlRegex values in the file must be properly escaped with \\. The characters that must be escaped are: \.[]{}()<>*+-=!? ^$|. 

configEnv:
    httpClients:
        - urlRegex: "http://hostname:port/mobile/custom/PublishingAPI.*"
          security:
              basicAuth:
                 username: eccUser
secretValue:
    httpClients:
        - urlRegex: "http://hostname:port/mobile/custom/PublishingAPI.*"
          security:
              basicAuth:
                  password: password

Enabling TLS in PDC REST Services Manager

You can enable TLS encryption in PDC REST Services Manager to secure the communications it receives from your enterprise product catalog.

To enable TLS in PDC REST Services Manager:

  1. Generate a self-signed SSL certificate:

    1. Create a directory for storing your SSL certificate that is accessible by the BRM Helm chart, such as oc-cn-helm-chart/rsm_cert.

    2. Generate an SSL certificate. For example, this creates a certificate file named cert.pem: 

      openssl req -x509 -newkey rsa:4096 -keyout openSSLKey.pem -out cert.pem -days 365 -nodes

    3. Generate a PKCS12 KeyStore file. For example, this creates a KeyStore file named keystore.p12: 

      openssl pkcs12 -export -out keyStore.p12 -inkey openSSLKey.pem -in cert.pem

  2. Add these keys to your override-values.yaml file for oc-cn-helm-chart:

    • ocpdcrsm.configEnv.isTlsEnabled: Set this to true to enable TLS encryption for PDC REST Services Manager.

    • ocpdcrsm.configEnv.tlsVersions: Set this to the list of supported TLS versions, such as TLSv1.2,TLSv1.3.

    • ocpdcrsm.configEnv.tlsCertificateFile: Set this to the path to the TLS certificate bundle in the Helm chart. The certificate must be in PKCS12 format.

    • ocpdcrsm.secretValue.tlsCertificatePassphrase: Set this to the Base64-encrypted passphrase for the TLS certificate.

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

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

  4. To apply the changes, re-create any previously existing PDC REST Services Manager pods:

    kubectl --namespace BrmNameSpace delete pods --selector=app.kubernetes.io/name=pdcrsm

After you enable TLS, connect to PDC REST Services Manager services using HTTPS only.

Enabling T3S in PDC REST Services Manager

Enable the T3S protocol in PDC REST Services Manager to secure its communications to PDC.

To enable T3S in PDC REST Services Manager:

  1. Add these keys to your override-values.yaml file for oc-cn-helm-chart:

    • ocpdcrsm.configEnv.useT3s: Set this to true.

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

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

  3. To apply the changes, re-create any previously existing PDC REST Services Manager pods:

    kubectl --namespace BrmNameSpace delete pods --selector=app.kubernetes.io/name=pdcrsm

Configuring Mapping of TMF620 priceType to BRM Events

If you are using PDC REST Services Manager, you must configure the mappings of BRM event names to the values your enterprise product catalog sends in the priceType property of the ProductOfferingPrice element of the TMF620 payload.

The mappings are configured in configmap_pdcrsm_appeventCfg.yaml. You can add mappings as needed for your deployment or use the default mappings provided at installation.

To add or edit mappings:

  1. Open the configmap_pdcrsm_appeventCfg.yaml file.

  2. Edit the existing mappings, or use them as templates to add new ones. Use the following format:

    pricetype : "eventname"

    where:

    • pricetype is the value sent in the priceType property of the ProductOfferingPrice element of the TMF620 payload.

    • eventname is the name of the BRM event the price type should be mapped to.

    For example, the default mappings for one-time fees and usage events are:

    ONE_TIME : "EventBillingProductFeePurchase"
ONE_TIME_PRICE_PLAN : "EventBillingProductFeePurchase"
USAGE : "EventSession"
USAGE_PRICE_PLAN : "EventSession"

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

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

  4. Restart the PDC REST Services Manager pods. If downtime is not a concern, both pods can be deleted and re-created by running the following command. Otherwise, delete one pod at a time, waiting for its replacement pod to become "Running" before deleting the next one.

    kubectl --namespace BrmNameSpace delete pods --selector=app.kubernetes.io/name=pdcrsm