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

• Configuring PDC REST Services Manager

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 "Publishing Notifications for External Applications".

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

Publishing Notifications for External Applications

Use the BRM REST Services Manager notification framework to publish TM Forum (TMF) events to Apache Kafka topics so downstream applications, such as Siebel CRM or Order and Service Management (OSM), can retrieve and process them.

The framework publishes notifications when any of the following occur in BRM:

• A billing account is created or deleted.

• A billing account’s state or attributes have changed.

• A party account is created or deleted.

• A party account’s state or attributes have changed.

• A product is created or deleted.

• A product’s state or attributes have changed.

For details about the notification event content, see REST Services Manager API for Billing and Revenue Management.

Before you begin, ensure that your system meets the notification framework prerequisites. See "Notification Framework Prerequisites".

To configure BRM REST Services Manager to publish notifications:

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

2. Configure the connection profiles for Kafka brokers and the Oracle AQ database by uncommenting and setting the keys under ocrsm.rsm.connection-profiles. See "Setting Up Connection Profiles".

3. Configure one or more consumers to read messages from Kafka topics by uncommenting and setting the keys in ocrsm.rsm.consumers. See "Configuring Consumers for Kafka Topics".

4. Configure one or more consumers to read messages from the Oracle AQ database queue by uncommenting and setting the keys under ocrsm.rsm.consumers. See "Configuring Consumers for Database Queues".

5. Configure one or more producers to write messages to Kafka topics by uncommenting and setting the keys under ocrsm.rsm.producer. See "Setting Up Producers".

6. Store secrets in Base64-encoded format in the override-values.yaml file so they can be added to the wallet at runtime.

7. Save the configuration and verify that all folder paths referenced in the override-values.yaml file exist and are accessible to the REST Services Manager process.

8. Validate that topics, partitions, security settings, and service connections are correct. See "Performing Verification and Sanity Checks".

9. Use the helm upgrade command to deploy and start the REST Services Manager notification services.

10. Validate the service by reviewing logs and performing functional checks. If needed, customize event handling with mapper overrides. Follow the approved restart procedure for the REST Services Manager Notification Service after configuration updates.

11. Confirm that the service connects to the Kafka brokers and joins the expected consumer groups.

12. Restart REST Services Manager cloud native after applying configuration or credential changes.

Note:

To apply broker SSL/SASL parameters and store passphrases securely:

• Enter SSL configurations (KeyStore and TrustStore locations and types, and passwords) in override-values.yaml using wallet references.

• Do not store plain-text credentials in configuration files.

Notification Framework Prerequisites

Ensure that your environment satisfies all prerequisites for the REST Services Manager Notification Service:

1. Create your Kafka cluster and topics. Ensure that the configuration aligns with your environment and security standards. To do so, follow the instructions in "Configuring Your AQ Database Queues" in BRM System Administrator’s Guide.

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

   • Set the required number of partitions for each topic and apply appropriate access control lists (ACLs).

   • Record the host names and port numbers of all Kafka brokers.

   • Monitor Kafka server logs to validate connectivity and detect errors.

2. Configure the Enterprise Application Integration (EAI) Framework to convert TMF-related data into business events that can be sent to the Oracle Data Manager (DM).

   • Map BRM events to opcodes by using the event notification file. The default file (BRM_home/sys/data/config/pin_notify) includes TMF-related events. Update the event list as needed and load the file into the database. See "Using Event Notification" in BRM Developer's Guide.

   • Configure the Payload Generator External Module (EM) to assemble complete business events, generate required data, and send business events to the Oracle DM. The default file (BRM_home/sys/eai_js/payloadconfig_crm_sync) defines TMF-related business events. Update the list as needed. See "Configuring Business Events" in BRM Developer's Guide.

3. Create an Oracle Database Wallet for sensitive values.

   • Configure an Oracle Database Wallet to securely store sensitive credentials, such as SSL/TLS passphrases, KeyStore and TrustStore files, and database schema credentials.

   • The wallet contents and certificate requirements depend on the database listener and instance being preconfigured for SSL/TLS. Ensure database encryption is enabled before mapping KeyStore and TrustStore locations in the wallet.

   • Store wallet, KeyStore, and TrustStore files in a secure location with restrictive file permissions.

   • Do not place passwords or secrets in plain-text configuration files.

Setting Up Connection Profiles

Configure Kafka and database connection profiles by mapping the required parameters and integrating wallet-based secrets. Table 8-2 lists the keys that appear under ocrsm.rsm.connection-profiles. Apply the appropriate SSL/SASL parameters to secure access to Kafka brokers.

Note:

Store the KeyStore, TrustStore, and wallet files in the oc-cn-helm-chart/rsm/rsm_keystore directory. Store secrets in Base64-encoded format in the override-values.yaml file so they can be added to the wallet at runtime.

Table 8-2 Connection Profile Keys

Key Name	Description
id	A unique identifier for the connection profile.
profile-type	Whether the profile contains connection information for the Kafka broker (kafka) or database (database).
host	The host name or IP address of the Kafka broker or database.
port	The network port to connect to the Kafka broker or database.
username	The authentication user name, if required for SASL or similar mechanisms (often empty for SSL-only setups).
password	The key that references the Base64-encoded password (for example, stored in the Wallet) for authenticating this profile.
truststore-type	The type of TrustStore file used for SSL/TLS connections: PKCS12 or JKS.
truststore-name	The TrustStore file name that contains the trusted certificate authorities.
truststore-password	The Base64-encoded password key used to retrieve the TrustStore (for example, stored in the wallet) for secure access.
keystore-type	The type of the KeyStore file that holds client SSL certificates: PKCS12 or JKS.
keystore-name	The KeyStore file name that contains the client SSL certificate and private key.
keystore-password	The key used to retrieve the Base64-encoded password (for example, stored in the wallet) for secure access.
properties.*	(Kafka profile only) The Kafka client properties for offsets, timeouts, batching, and so on. Keys and values must follow standard Kafka property names and guidelines. auto.offset.reset: Where to start consuming messages if no offset is committed, such as latest to start from the latest message. enable.auto.commit: Whether the Kafka consumer auto-commits offsets (true) or requires manual management (false). session.timeout.ms: The timeout, in milliseconds, to detect consumer failures. heartbeat.interval.ms: The interval, in milliseconds, for sending heartbeats to the Kafka broker. connections.max.idle.ms: The maximum idle time for a connection before closing. max.poll.records: The maximum number of records returned in a single poll. max.poll.interval.ms: The maximum interval between poll calls before the Kafka broker considers the consumer failed. max.partition.fetch.bytes: The maximum bytes per partition fetched in a request. acks: The number of acknowledgments the producer requires for a request, such as all for full commits. retries: The maximum number of retry attempts for failed producer requests. batch.size: The Kafka producer’s batch memory size in bytes. linger.ms: The delay, in milliseconds, before sending records to allow batching. buffer.memory: The Kafka producer’s total buffer memory in bytes. compression.type: The compression algorithm to use, such as none or gzip.
properties.service-name	(Database profile only) The specific name of the database service (or SID) for establishing a connection.

The following shows sample settings for a Kafka profile:

connection-profiles:
     - id: "cp1"
       profile-type: "kafka"
       host: "host"
       port: port
       username: ""
       password: "base64EncodedPassword"
       truststore-type: PKCS12
       truststore-name: "truststore.p12"
       truststore-password: "base64EncodedPassword"
       keystore-type: PKCS12
       keystore-name: "keystore.p12"
       keystore-password: "base64EncodedPassword"
       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

The following shows sample settings for a database profile:

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

Configuring Consumers for Kafka Topics

Configure Kafka consumers by defining consumer properties, runtime behavior, and topic-event mappings under ocrsm.rsm.consumers. Table 8-3 lists the override-values.yaml keys for configuring consumers to read messages from Kafka topics.

Note:

When using multiple REST Services Manager replicas, ensure the number of partitions for each downstream consumer chain aligns with the parent consumer’s partitions to maintain ordering and parallelism.

Table 8-3 Kafka Consumer Keys

Key Name	Description
connection-profile-id	The unique ID for the consumer profile instance.
properties.group.id	The unique ID for the consumer group managing coordination and offsets. Note: Use a distinct consumer group ID for each independent consumer. Consumers in the same downstream chain may share a group ID as required.
configuration.*	The configuration for the consumer profile instance: max-retries: The maximum number of retry attempts for processing an event before routing it to the retry or DLQ topic. retry-delay-interval-ms: The delay, in milliseconds, between retry attempts after a processing failure. record-fetch-timeout-ms: 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: The interval, in milliseconds, to wait between attempts to reconnect to BRM services. (Also appears as brm.connection.retry.interval.ms.) strict-ordering: A flag indicating whether to enforce strict ordering for message keys (true) or not (false). buffer-strategy: The method used for buffering events within the consumer; this is implementation-specific.
topic-event-config.*	The configuration for a Kafka topic to consume messages from: source-topic: The name of the Kafka topic the consumer reads from. sink-topic: The name of the Kafka topic to which the consumer sends failed messages. key-state-topic: The name of an optional topic used to track and manage the message key states. consumer-thread-count: The number of worker threads allocated for polling messages from the source topic. worker-thread-count: The number of worker threads used for processing polled events. events: A list of event types that the consumer instance will process, such as ProductCreateEvent and ProductStateChangeEvent.
topic-event-config.downstream-consumers.*	A list of additional consumer stages for retry or DLQ handling, each with its own configuration.

The following shows keys for a sample Kafka consumer named cp1:

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

Configuring Consumers for Database Queues

Table 8-4 lists the override-values.yaml keys for configuring consumers to read messages from the Oracle AQ database queue. These keys appear under ocrsm.rsm.consumers.

Table 8-4 Consumer Keys for Database Queues

Parameter	Explanation
connection-profile-id	The ID for the database connection profile. This value must exactly match the ID of a profile with profile-type set to database.
properties.*	The properties for connecting to the database queue. username: The login name for authenticating the connection to the database or queue. password: The key used to securely retrieve the Base64-encoded authentication password (such as from a Kubernetes Secret or Oracle Wallet). queue-name: The name of the queue from which this consumer reads messages, such as for queue-based processing.
wallet-name	The name of the wallet or credential store used for secure connections to the database. If provided, wallet credentials take precedence over TrustStores and KeyStore files. Place the wallet in rsm/rsm_keystore.
configuration.worker-thread-count	The number of worker threads to process events from the database queue.

The following example shows a Kafka consumer configuration in the REST_home/scripts/override-values.yaml:

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

Setting Up Producers

Configure producers to publish supported TMF business events to one or more Kafka topics. Table 8-5 lists the keys under ocrsm.rsm.producer.

Table 8-5 Producer Keys

Parameter	Explanation
connection-profile-id	The name of the connection profile to use.
properties	The Kafka properties to override or producer-specific properties to add.
event-topics-config.*	The business events to publish to each Kafka topic. event-name: The business event type that triggers the producer to publish the message to the Kafka topic, such as ProductCreateEvent. topic-names: The list of one or more Kafka topics to which messages for the corresponding event are published.

The following shows keys for a sample Kafka producer named cp1:

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" ]

Performing Verification and Sanity Checks

Perform checks to ensure topics, partitions, security settings, and service connections are correct. Verify functional connectivity and end-to-end message flow.

• Confirm that all required topics exist with the correct partition counts and ACLs.

• Ensure that consumers join the correct consumer groups and receive expected partition assignments.

• Verify that SSL or SASL connections to brokers are successfully established and validated.

• Publish test messages and verify end-to-end flow from producers through consumers, including retry and DLQ paths.

• Use provided scripts and logs to verify wallet entry references and KeyStore/TrustStore integrity.

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

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

     Table 8-8 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: EncryptedPassword
secretValue:
    httpClients:
        - urlRegex: "http://hostname:port/mobile/custom/catalogManagement/.*"
          security:
              oauth2:
                  clientSecret: client_secret
                  password: EncryptedPassword

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: EncryptedPassword

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 TMF 620 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