Revenue Management Oracle® Communications Billing and · 2020-04-29 · Deploying Paymentech Data Manager in HA Mode 3-18 Configuring Elastic Charging Engine 3-19 Adding Elastic

Oracle® Communications Billing andRevenue ManagementCloud Native Installation and AdministrationGuide

Release 12.0F21893-03April 2020

Oracle Communications Billing and Revenue Management Cloud Native Installation and AdministrationGuide, Release 12.0

F21893-03

Copyright © 2019, 2020, Oracle and/or its affiliates.

This software and related documentation are provided under a license agreement containing restrictions onuse and disclosure and are protected by intellectual property laws. Except as expressly permitted in yourlicense agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.Reverse engineering, disassembly, or decompilation of this software, unless required by law forinteroperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. Ifyou find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it onbehalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software,any programs embedded, installed or activated on delivered hardware, and modifications of such programs)and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government endusers are "commercial computer software" or “commercial computer software documentation” pursuant to theapplicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use,reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/oradaptation of i) Oracle programs (including any operating system, integrated software, any programsembedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oraclecomputer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in thelicense contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloudservices are defined by the applicable contract for such services. No other rights are granted to the U.S.Government.

This software or hardware is developed for general use in a variety of information management applications.It is not developed or intended for use in any inherently dangerous applications, including applications thatmay create a risk of personal injury. If you use this software or hardware in dangerous applications, then youshall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure itssafe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of thissoftware or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks oftheir respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks areused under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc,and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registeredtrademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,and services from third parties. Oracle Corporation and its affiliates are not responsible for and expresslydisclaim all warranties of any kind with respect to third-party content, products, and services unless otherwiseset forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not beresponsible for any loss, costs, or damages incurred due to your access to or use of third-party content,products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

Audience vii

Documentation Accessibility vii

1 Overview of the BRM Cloud Native Deployment

About the BRM Cloud Native Deployment 1-1

BRM Cloud Native Deployment Architecture 1-1

Images and Containers 1-2

Images and Containers with Non-WebLogic Server Pattern 1-2

Images and Containers with a WebLogic Server Pattern 1-3

2 Planning Your Installation

Overview 2-1

Software Compatibility 2-4

Environment Setup 2-4

Moving from On-Premise BRM to BRM Cloud Native Deployment 2-6

Downloading the BRM Cloud Native Deployment Package 2-6

Merging Split TAR Files 2-8

Loading BRM Component Images 2-9

3 Installing the BRM Cloud Native Deployment Package

About Deploying into Kubernetes 3-1

Extracting the Helm Charts 3-3

Automatically Pulling Images from Private Docker Registries 3-3

Configuring the BRM Cloud Native Deployment Package 3-4

Configuring Global Values 3-4

Configuring BRM Server 3-5

Deploying BRM with a New Schema 3-5

Deploying BRM with an Existing Schema 3-7

Configuring the BRM Helm Chart 3-8

iii

Configuring BRM Server Components 3-12

Configuring a CM ConfigMap Directory 3-12

Configuring an EAI Publisher 3-13

Configuring the Configurator Job 3-13

Configuring the brm-apps Job 3-14

Configuring Multiple Replicas of Batch Controller 3-17

Deploying Paymentech Data Manager in HA Mode 3-18

Configuring Elastic Charging Engine 3-19

Adding Elastic Charging Engine Keys 3-19

Enabling SSL in Elastic Charging Engine 3-25

About Elastic Charging Engine Volume Mounts 3-26

Integrating Apache Kafka and ZooKeeper with ECE 3-26

Using Third-Party Library and Custom Mediation Specifications 3-27

Loading BRM Configuration XML Files 3-27

Using a Custom TLS Certificate for Secure Connections 3-28

Scaling Kubernetes Pods 3-28

Enabling Federation in ECE 3-29

Running SDK Jobs 3-30

Customizing SDK Source Code 3-32

Configuring Pricing Design Center 3-32

Adding PDC Keys 3-32

Enabling SSL in Your PDC Domain 3-39

Configuring Pipeline Configuration Center 3-39

Adding Pipeline Configuration Center Keys 3-40

Enabling SSL in Your Pipeline Configuration Center Domain 3-42

About Pipeline Configuration Center Logs 3-42

Configuring Billing Care 3-42

Adding Billing Care Keys 3-43

About Billing Care Volume Mounts 3-45

Creating a WebLogic Domain and Installing the Billing Care Application 3-46

Starting and Stopping WebLogic Servers 3-47

Exposing Billing Care Services Outside a Cluster 3-47

Configuring the Billing Care REST API 3-47

Adding Billing Care REST API Keys 3-48

About the Billing Care REST API Volume Mounts 3-51

Creating a WebLogic Domain and Installing the Billing Care REST API 3-51


Exposing Billing Care REST API Services Outside a Cluster 3-52

Configuring Business Operations Center 3-53

Adding Business Operations Center Keys 3-53

About Business Operations Center Volume Mounts 3-58

iv

Creating a WebLogic Domain and Installing the Business Operations CenterApplication 3-59


Exposing Business Operations Center Services Outside a Cluster 3-60

Installing BRM Cloud Native Services 3-60

4 Upgrading Your BRM Cloud Native Deployment

About Upgrading Your BRM Cloud Native Environment 4-1

Upgrading Your Database Schema 4-1

Upgrading Your BRM Cloud Native Deployment 4-2

Upgrading Your PDC Cloud Native Deployment 4-3

5 Customizing BRM Cloud Native Services

Customizing BRM Server 5-1

Customizing Billing Care 5-2

Customizing ECE 5-3

6 Maintaining Your BRM Cloud Native Deployment

Managing a Helm Release 6-1

Tracking a Release's Status 6-1

Updating a Helm Release 6-2

Checking a Release's Revision 6-2

Rolling Back A Release To A Previous Revision 6-2

Automatically Rolling Deployments by Using Annotations 6-3

Rotating the BRM Root Password 6-3

About Application Log Files 6-6

7 Uninstalling Your BRM Cloud Native Deployment

Uninstalling Selected BRM Cloud Native Services 7-1

Uninstalling Your BRM Cloud Native Deployment 7-1

8 Building Your Own Images

Building BRM Server Images 8-1

Building Your BRM Server Base Image 8-2

Building Images of BRM Server Components 8-3

Building Web Services Manager Images 8-4

Building and Deploying Web Services Manager for Apache Tomcat Image 8-4

v

Building and Deploying Web Services Manager for WebLogic Server Image 8-6

Containerization of Email Data Manager 8-9

Containerization of Roaming Pipeline 8-11

Building and Deploying Vertex Manager 8-11

Building PDC Images 8-13

Building the Base PDC Image 8-13

Building the PDC APP Image 8-14

Building the PDC BRM Integration Image 8-14

Building the PDC Kubectl Image 8-15

Building Pipeline Configuration Center Images 8-15

Pulling the Fusion Middleware Infrastructure Image 8-16

Building the Pipeline Configuration Center Image 8-16

Building Billing Care Images 8-16

Pulling the Fusion Middleware Infrastructure Image 8-16

Building the Billing Care Image 8-16

Building Business Operations Center Images 8-17

Building the Business Operations Center Image 8-17

Building the Oracle BRM Apps Image 8-17

Building the Kubectl Image 8-18

9 Deploying into Oracle Cloud Infrastructure

Deploying into Oracle Cloud Infrastructure 9-1

10

Integrating with Your BRM Cloud Native Deployment

Integrating with Thick Clients 10-1

Using a Custom TLS Certificate for Secure Connections 10-1

Integrating with JCA Resource Adapter 10-2

Integrating with BI Publisher 10-3

A Supported Utilities and Applications for brm-apps Jobs

B Supported Load Utilities for Configurator Jobs

vi

Preface

This guide describes how to install and administer Oracle Communications Billing andRevenue Management (BRM) Cloud Native Deployment Option.

AudienceThis document is intended for DevOps administrators and those involved in installingand maintaining an Oracle Communications Billing and Revenue Management (BRM)Cloud Native Deployment.

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the OracleAccessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic supportthrough My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are hearing impaired.

vii

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs

1Overview of the BRM Cloud NativeDeployment

This chapter provides an overview of the Oracle Communications Billing and RevenueManagement (BRM) cloud native deployment.

Topics in this chapter

• About the BRM Cloud Native Deployment

• BRM Cloud Native Deployment Architecture

About the BRM Cloud Native DeploymentOracle Communications Billing and Revenue Management (BRM), OracleCommunications Pricing Design Center (PDC), Oracle Communications ElasticCharging Engine (ECE), Oracle Communications Pipeline Configuration Center (PCC),Oracle Communications Billing Care, and Oracle Communications BusinessOperations Center (BOC) now support their deployment on a cloud nativeenvironment. This allows you to harness the benefits of cloud with the services ofBRM.

Note:

You can also deploy Oracle Communications Offline Mediation Controller ona cloud native environment. See Offline Mediation Controller Cloud NativeInstallation and Administration Guide for more information.

You can set up your own cloud native environments. You use the cloud nativedeployment package to automate the deployment of BRM products and speed up theprocess to get services up and running, with product deployments preconfigured tocommunicate with each other through Helm charts.

BRM Cloud Native Deployment ArchitectureFigure 1-1 shows the Pods and other components in a typical BRM cloud nativedeployment. The Pods shown with blue text were introduced in 12.0 Patch Set 3.

1-1

Figure 1-1 BRM Cloud Native Deployment Architecture

In this figure:

• Billing Care, BOC, PCC, and PDC are client applications. They connect to the CM,which represents the business logic layer of BRM, by using the PortalCommunications Protocol (PCP).

• The CM communicates with other Pods, which represent the data managementlayer of BRM, by using the PCP protocol.

• All PCP protocol communication is encrypted using TLS.

• The data managers (DMs) interact with other downstream products that run thebusiness logic.

The downstream products can be containers or an on-premise system.

• ECE rates events and applies charges.

• Rating files for the batch pipeline are fed in through a KubernetesPersistentVolumeClaim (PVC). The batch pipeline output is also available in aPVC for consumption by the Rated Event Loader Pod.

Images and ContainersEach BRM cloud native deployment image has been designed and hardened to serveonly the purpose it's supposed to. BRM cloud native deployment images are built bystacking multiple layers, extending an operating system image with a dependentlibrary image, and then with an image packing the application.

Images and Containers with Non-WebLogic Server PatternBRM cloud native images that don't use WebLogic, such as the BRM base image, usethe layering pattern shown in Figure 1-2.

Chapter 1BRM Cloud Native Deployment Architecture

1-2

If you want to build your own BRM images, you must layer the images in this pattern.

Figure 1-2 Base Image Layering with Non-WebLogic Server Pattern

Images and Containers with a WebLogic Server PatternWebLogic Server is a primary requirement for the Billing Care, PDC, PCC, and BOCcloud native deployments. Thus, all of these images share a similar image stack.

Figure 1-3 shows the stack for a Billing Care image.

Figure 1-3 Images and Containers with WebLogic Server Pattern

In this figure:

• Fusion Middleware Infrastructure is the base image. This image is available fromthe container-registry.oracle.com repository.

• The Fusion Middleware Infrastructure image is based on Oracle Linux and OracleJDK 8 (Server JRE). It's regularly patched with critical security fixes until therelease date.

• The Billing Care image extends the Fusion Middleware Infrastructure image, whichprovides WebLogic Server and JRF for OPSS for authorized access to theapplication.


1-3

The PDC image has an additional dependency on BRM applications. It references thebrm-apps and realtime-pipeline images for copying BRM applications and theLoadIfwConfig utility from Pipeline Manager.

Figure 1-4 shows the process for deploying Billing Care using WebLogic Operator.

Figure 1-4 Billing Care Image Flowchart with WebLogic Operator

This pattern applies to Billing Care, the Billing Care REST API, and BOC, which useWebLogic Operator for deploying and managing WebLogic domains. The Billing Care,Billing Care REST API, and BOC deployment is divided into two Helm charts:

• oc-cn-op-job-helm-chart: This chart creates the domain and installs applications.

• oc-cn-helm-chart: This chart starts the WebLogic Servers according to thedomain configuration for Billing Care and BOC and loads authorization policies toaccess their services.


1-4

2Planning Your Installation

This chapter describes how to plan your installation of the Oracle CommunicationsBilling and Revenue Management (BRM) cloud native deployment package.


• Overview

• Software Compatibility

• Environment Setup

• Moving from On-Premise BRM to BRM Cloud Native Deployment

• Downloading the BRM Cloud Native Deployment Package

• Merging Split TAR Files

• Loading BRM Component Images

OverviewThe BRM cloud native deployment package includes ready-to-use images and Helmcharts to help you orchestrate containers in Kubernetes. The package also includessample Dockerfiles and scripts if you want to build the images in your environment.

You can use the Docker images and Helm chart to help you deploy and manage Podsof BRM product services in Kubernetes. Communication between Pods of services ofBRM products are preconfigured in the Helm charts.

To improve security, the BRM services are not exposed outside of the cluster. OnlyPricing Design Center (PDC), Pipeline Configuration Center (PCC), BRM WebServices Manager, Billing Care, and Business Operations Center (BOC) are exposed.

Table 2-1 lists the Pods and images for BRM whose containers are created andservices are exposed through them. For the image name, replace 12.0.0.x.0 with thepatch set version number, such as 12.0.0.3.0. For example, for the 12.0.0.3.0 patchset, the dm-oracle Pod image name would be dm_oracle:12.0.0.3.0.

Table 2-1 BRM Pods and Images

Pod ReplicaType

Image Name ImageSize

Container Port

Service Type

cm Multiple cm:12.0.0.x.0

eai_js:12.0.0.x.0

1.31 GB

1.2 GB

11960 ClusterIP

dm-oracle Multiple dm_oracle:12.0.0.x.0 2.56 GB ClusterIP

init-db Single init_db:12.0.0.x.0 2.41 GB ClusterIP

dm-aq Multiple dm_aq:12.0.0.x.0 2.54 GB ClusterIP

dm-ifw-sync Multiple dm_ifw_sync12.0.0.x.0 2.54 GB ClusterIP

2-1

Table 2-1 (Cont.) BRM Pods and Images

Pod ReplicaType

Image Name ImageSize

Container Port

Service Type

dm-vertex Multiple dm_vertex:12.0.0.x.0 2.54 GB ClusterIP

dm-eai Multiple dm_eai:12.0.0.x.0 1.23 GB ClusterIP

dm-invoice Multiple dm_invoice:12.0.0.x.0 2.56 GB ClusterIP

dm-ldap Multiple dm_ldap:12.0.0.x.0 2.33 GB ClusterIP

dm-prov-telco

Multiple dm_prov_telco:12.0.0.x.0 1.32 GB ClusterIP

ecs

configloader

pricingupdater

customerupdater

emgateway

diametergateway

httpgateway

brmgateway

radiusgateway

ratedeventformatter

Multiple oc-cn-ece:12.0.0.x.0 1.34 GB 9999 NodePort

realtime-pipe Multiple realtimepipe:12.0.0.x.0 2.65 GB ClusterIP

batch-wireless-pipe

Single batch_pipeline:12.0.0.x.0 2.52 GB ClusterIP

roam-pipeline

Single roam_pipeline:12.0.0.x.0 2.48 GB ClusterIP

rel-daemon Multiple rel_daemon:12.0.0.x.0 2.77 GB ClusterIP

batch-controller

Multiple batch_controller:12.0.0.x.0

1.51 GB ClusterIP

formatter Multiple formatter:12.0.0.x.0 2.51 GB ClusterIP

fusa-simulator

Single answer:12.0.0.x.0 2.25 GB ClusterIP

dm-fusa Single dm_fusa:12.0.0.x.0 2.53 GB ClusterIP

upgrade Single upgrade:12.0.0.x.0 2.46 GB ClusterIP

dm-email Single dm_email:12.0.0.x.0 1.22 GB ClusterIP

config-jobs Single config_jobs:12.0.0.x.0 2.4 GB ClusterIP

wsm Multiple brm_wsm_wls:12.0.0.x.0

brm_wsm_wl_init:12.0.0.x.0

1.19 GB 30611(http)

NodePort

brm-apps Single brm_apps:12.0.0.x.0 3.1 GB N/A

Chapter 2Overview

2-2

Table 2-2 lists the Pods and images for Pricing Design Center (PDC), PipelineConfiguration Center, Billing Care, and Business Operations Center. For the imagename, replace 12.0.0.x.0 with the patch set version number, such as 12.0.0.3.0. Forexample, for the 12.0.0.3.0 patch set, the pdc Pod image name would be oracle/pdcapp:12.0.0.3.0.

Note:

For the list of Pods and images for Offline Mediation Controller, see OfflineMediation Controller Cloud Native Installation and Administration Guide.

Table 2-2 Client Pods and Images

Pod ReplicaType

Image Image Size ContainerPort

ServiceType

pdc Single oracle/pdcapp:12.0.0.x.0oracle/pdcbrminteg:12.0.0.x.0

4.37 GB

3.8 GB

8001 (http)1

8002(https)1

NodePort

pcc Single oracle/pcc:12.0.0.x.0 2.46 GB 7012 (https) NodePort

billingcare Multiple oracle/billingcare:12.0.0.x.0

2.54 GB 30711(http),

8001 (http)

NodePort,

ClusterIP

boc Multiple oracle/boc:12.0.0.x.0 2.83 GB 30811(http),

8001 (http)

NodePort,

ClusterIP

Note:

(1) If the PDC user sets the t3ChannelPort and t3sChannelPort keys in thevalues.yaml file, the http, https, t3Channel, and t3sChannel ports will beNodePort.

Table 2-3 lists the services associated with ECE.

Table 2-3 ECE Services

Service Service Type Port Description

ece-brmgateway NodePort External port BRM Gateway service

ece-dgw NodePort External port Diameter Gatewayservice

ece-emg NodePort External port EM Gateway service

ece-http NodePort External port HTTP Gatewayservice

ece-rgw NodePort External port RADIUS Gatewayservice

Chapter 2Overview

2-3

Software CompatibilityFor the software that is compatible with the BRM cloud native deployment package,see "BRM Cloud Native Deployment Software Compatibility".

For a full list of software that is compatible with BRM, see "BRM SoftwareCompatibility".

Environment SetupThe BRM cloud native deployment package works with these technologies:

• Docker: The Docker platform is used to containerize BRM products. Docker isneeded if you want to build images by writing your own Dockerfiles using thesample Dockerfiles from the BRM cloud native deployment package. You use theDocker container runtime to create and run containers of these images inKubernetes. You also host a repository for storing the images, which can later beaccessed by Kubernetes for creating Pods.

For more information about Docker, see Docker Reference (https://docs.docker.com/reference/).

• Kubernetes: Typically, a production-grade Kubernetes cluster is formed bymultiple systems distributing the resources. Being a container platform, it providesa container-centric management environment. The cloud native deploymentpackage contains YAML descriptors for creating Kubernetes objects and forallowing it to orchestrate containers of images from BRM products. Set up theKubernetes cluster and secure access to the cluster and its objects with the helpof service accounts and proper authentication and authorization modules. Also,choose volumes, a networking model, and logging services to be used in yourcluster.

For more information about Kubernetes, see Kubernetes Concepts (https://kubernetes.io/docs/concepts/).

Note:

Ensure that your cluster is secured according to standard DevOpspractices.

– Volumes: A container’s file system lives only as long as the container does.When a container terminates and restarts, filesystem changes are lost as well.You shouldn't access the container file system or Pods frequently, and it's noteasy to share data between container and host systems. Volumes appear as adirectory in the container file system and provide a way to share data. TheBRM cloud native deployment package uses persistent volumes for sharingdata in and out of containers, but doesn't enforce any particular type. You canchoose from the volume type options available in Kubernetes.

Chapter 2Software Compatibility

2-4

https://docs.docker.com/reference/

https://docs.docker.com/reference/

https://kubernetes.io/docs/concepts/

https://kubernetes.io/docs/concepts/

Note:

You can choose an external incubator to create persistent volumes,but ensure that it supports the ReadWriteMany access mode.

– Networking: Kubernetes assumes that Pods can communicate with otherPods, regardless of which host they land on. Every Pod gets its own IPaddress, so we don't need to explicitly create a link between Pods. We almostnever need to deal with mapping container ports to host ports. WhileKubernetes itself doesn't offer a solution to support its assumption, severalimplementations are available that meet the fundamental requirements ofKubernetes’ networking model. Choose the networking element depending onthe cluster requirement.

• Elasticsearch: Elasticsearch provides the storage and search engine for yourBRM cloud native deployment log files. You use it to index and search through allof your log data. Kibana adds a Web-based dashboard to Elasticsearch so youcan view and analyze your log data.

For more information about:

– Elasticsearch, see Getting Started with the Elastic Stack (https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html).

– Kibana, see Kibana Guide (https://www.elastic.co/guide/en/kibana/7.6/index.html).

• Fluentd: Fluentd forms your logging layer, collecting log files from your BRMservice Pods, transforming them, and then sending them to the Elasticsearchbackend. The Fluentd-concat plugin is used to concatenate multiline log files. Youset up Fluentd on your Kubernetes nodes. To allow Fluentd to parse your log files,all applications should redirect their logs to STDOUT.

Billing Care and BOC run Fluentd as a side-car application to collect logs fromeach WebLogic Server.

For more information about Fluentd, see Fluentd Overview (https://docs.fluentd.org/quickstart).

• WebLogic Operator: The WebLogic Operator assists with deploying andmanaging the WebLogic domain in your Kubernetes environment. The WebLogicoperator consists of several parts: the operator runtime, the model for aKubernetes custom resource definition (CRD), and a Helm chart for installing theoperator.

For more information about WebLogic Operator, see Oracle WebLogic KubernetesOperator User Guide (https://oracle.github.io/weblogic-kubernetes-operator/userguide/)

• Helm: Helm is the package manager for Kubernetes, and chart is a Helmpackage. Charts, which are packaged as part of the BRM cloud native deploymentpackage, help create Kubernetes objects like ConfigMap, Secrets, controller sets,and Pods with a single command. This feature of Helm makes it easy to handle allBRM configurations, deployments, and services.

For more information about Helm, see Helm Quickstart Guide (https://helm.sh/docs/using_helm/).

Chapter 2Environment Setup

2-5

https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html



https://www.elastic.co/guide/en/kibana/7.6/index.html

https://www.elastic.co/guide/en/kibana/7.6/index.html

https://docs.fluentd.org/quickstart

https://docs.fluentd.org/quickstart

https://oracle.github.io/weblogic-kubernetes-operator/userguide/


https://helm.sh/docs/using_helm/

https://helm.sh/docs/using_helm/

• Oracle Database: An Oracle database must be installed and accessible throughthe Kubernetes network, so that the Pods can perform database operations. It canbe either a CDB or a non-CDB.

• Oracle Unified Directory: The Billing Care, BOC, and PDC cloud nativedeployments support Oracle Unified Directory (OUD) as an LDAP solution forauthenticating users. You must have a standalone or containerized instance ofOUD running in the same network as the Kubernetes cluster.

Prepare your environment with these technologies installed, configured, and tuned forperformance, networking, security, and high-availability. Make sure there are backupnodes available in case of system failure in any of the cluster's active nodes.

Moving from On-Premise BRM to BRM Cloud NativeDeployment

If you're an existing BRM customer on BRM 7.5.x or BRM 12.x, perform these high-level tasks to move to the BRM cloud native deployment.

• Upgrade your BRM and PDC database schemas to 12.0.0.3.0. For moreinformation, see BRM Upgrade Guide.

Note:

If you're on BRM 12.0.0.2.0, see "Upgrading Your Database Schema" toupgrade the existing schema to 12.0.0.3.0.

To use an existing BOC database schema, point to your existing BOCschema in the override-values.yaml for oc-cn-op-job-helm-chart. See"Adding Business Operations Center Keys".

• If you customized BRM or Billing Care, layer your customizations on top of theDocker images provided with this release before deploying the images. Forguidelines about customization, see "Customizing BRM Cloud Native Services".

Downloading the BRM Cloud Native Deployment PackageThe BRM cloud native deployment package contains ready-to-use Docker images, aHelm package for deployment in Kubernetes, as well as sample Dockerfiles andscripts that you can use as a reference for building your own images. If you want tobuild your own images, you must also download these installers:

• Oracle Communications Billing and Revenue Management

• Oracle Communications Billing Care

• Oracle Communications Business Operations Center

• Oracle Communications Elastic Charging Engine

• Oracle Communications Pipeline Configuration Center

• Oracle Communications Pricing Design Center

Table 2-4 lists all of the component packages that are included with the BRM cloudnative deployment package.

Chapter 2Moving from On-Premise BRM to BRM Cloud Native Deployment

2-6

Table 2-4 BRM Component Packages

Component Package Name File Name

Oracle Communications Cloud Native Advanced QueuingData Manager

oc-cn-brm-dm-aq-12.0.0.x.0.tar

Oracle Communications Cloud Native Batch Controller oc-cn-brm-batch-controller-12.0.0.x.0.tar

Oracle Communications Cloud Native Batch Pipeline oc-cn-brm-batch-pipeline-12.0.0.x.0.tar

Oracle Communications Cloud Native Billing Care oc-cn-billingcare-12.0.0.x.0.tar

Oracle Communications Cloud Native BRM Applications oc-cn-brm-apps-12.0.0.x.0.tar

Oracle Communications Cloud Native BRM ConfiguratorJob

oc-cn-brm-config-jobs-12.0.0.x.0.tar

Oracle Communications Cloud Native Business OperationsCenter

oc-cn-boc-12.0.0.x.0.tar

Oracle Communications Cloud Native Connection Manager oc-cn-brm-cm-12.0.0.x.0.tar

Oracle Communications Cloud Native Database Initializer oc-cn-brm-init-db-12.0.0.x.0.tar

Oracle Communications Cloud Native Database Upgrade oc-cn-brm-upgrade-12.0.0.x.0.tar

Oracle Communications Cloud Native Email Data Manager oc-cn-brm-dm-email-12.0.0.x.0.tar

Oracle Communications Cloud Native EnterpriseApplication Integration Data Manager

oc-cn-brm-dm-eai-12.0.0.x.0.tar

Oracle Communications Cloud Native EnterpriseApplication Integration Java Server

oc-cn-brm-eai-js-12.0.0.x.0.tar

Oracle Communications Cloud Native Fusa Data Manager oc-cn-brm-dm-fusa-12.0.0.x.0.tar

Oracle Communications Cloud Native Fusa Simulator oc-cn-brm-fusa-simulator-12.0.0.x.0.tar

Oracle Communications Cloud Native Invoice DataManager

oc-cn-brm-dm-invoice-12.0.0.x.0.tar

Oracle Communications Cloud Native Invoice Formatter oc-cn-brm-invoice-formatter-12.0.0.x.0.tar

Oracle Communications Cloud Native LDAP Data Manager oc-cn-brm-dm-ldap-12.0.0.x.0.tar

Oracle Communications Cloud Native Oracle DatabaseManager

oc-cn-brm-dm-oracle-12.0.0.x.0.tar

Oracle Communications Cloud Native PipelineConfiguration Center

oc-cn-pcc-12.0.0.x.0.tar

Oracle Communications Cloud Native Pricing DesignCenter

oc-cn-pdc-12.0.0.x.0_part1of2.taroc-cn-pdc-12.0.0.x.0_part2of2.taroc-cn-pdcbrminteg-12.0.0.x.0.tar

Oracle Communications Cloud Native Provisioning DataManager

oc-cn-brm-dm-prov-telco-12.0.0.x.0.tar

Chapter 2Downloading the BRM Cloud Native Deployment Package

2-7

Table 2-4 (Cont.) BRM Component Packages

Component Package Name File Name

Oracle Communications Cloud Native Rated Event Loader oc-cn-brm-rel-12.0.0.x.0.tar

Oracle Communications Cloud Native Real-Time Pipeline oc-cn-brm-realtime-pipeline-12.0.0.x.0.tar

Oracle Communications Cloud Native Roaming Manager oc-cn-brm-roam-pipeline-12.0.0.x.0.tar

Oracle Communications Cloud Native SynchronizationQueue Data Manager

oc-cn-brm-dm-ifw-sync-12.0.0.x.0.tar

Oracle Communications Cloud Native Vertex DataManager

oc-cn-brm-dm-vertex-12.0.0.x.0.tar

Oracle Communications Cloud Native Web ServicesManager

oc-cn-brm-brm_wsm_wls-12.0.0.x.0.tar

oc-cn-brm-brm_wsm_wl_init-12.0.0.x.0.tar

Oracle Communications Cloud Native Database InitializerHelm Chart

oc-cn-init-db-helm-chart-12.0.0.x.0.tgz

Oracle Communications Cloud Native ECE Docker Image oc-cn-ece-12.0.0.x.0.tar

Oracle Communications Cloud Native Docker Build Files oc-cn-docker-files-12.0.0.x.0.tgz

Oracle Communications Cloud Native ECE Helm Chart oc-cn-ece-helm-chart-12.0.0.x.0.tgz

Oracle Communications Cloud Native Helm Chart oc-cn-helm-chart-12.0.0.x.0.tgz

Oracle Communications Cloud Native Operator Job Chart oc-cn-op-job-helm-chart-12.0.0.x.0.tgz

Merging Split TAR FilesTo improve download performance, BRM images that have TAR files larger than 4 GBhave been split into multiple parts. You can merge the split TAR files before taggingand pushing them to the registry by entering this command:

cat oc-cn-Component-12.0.0.x.0_part* > oc-cn-Component-12.0.0.x.0.tar

where Component is the short name of the BRM component, such as pdc for PricingDesign Center (PDC).

For example, to merge the PDC TAR files into a single TAR file, you'd enter thiscommand:

cat oc-cn-pdc-12.0.0.x.0_part* > oc-cn-pdc-12.0.0.x.0.tar

Chapter 2Merging Split TAR Files

2-8

Loading BRM Component ImagesImages shipped with the BRM cloud native deployment package are in the form ofTAR files. After downloading the TAR files, load them as images into the Dockersystem. For a list of images, see Table 2-4.

For example, to load the Oracle Communications Cloud Native Connection Managerimage into the Docker system, you would do this:

1. Download the oc-cn-brm-cm-12.0.0.x.0.tar file to the system where Docker isinstalled.

2. Enter this command:

docker load --input oc-cn-brm-cm-12.0.0.x.0.tar

3. Verify that the image is loaded correctly by entering this command:

docker images cm:12.0.0.x.0

The image details should be listed in one row.

If you use an internal registry to access images from different Kubernetes nodes, pushthe images from the local system to the registry server. For example, if the registry isidentified by RepoHost:RepoPort, you'd push the CM image to the registry like this:

1. Tag the image with the registry server by entering this command:

docker tag cm:12.0.0.x.0 RepoHost:RepoPort/cm:12.0.0.x.0

2. Push the image to the registry server by entering this command:

docker push RepoHost:RepoPort/cm:12.0.0.x.0

Chapter 2Loading BRM Component Images

2-9

3Installing the BRM Cloud NativeDeployment Package

This chapter describes how to install the BRM cloud native deployment package on acloud native environment.


• About Deploying into Kubernetes

• Extracting the Helm Charts

• Automatically Pulling Images from Private Docker Registries

• Configuring the BRM Cloud Native Deployment Package

• Installing BRM Cloud Native Services

About Deploying into KubernetesHelm is the recommended package manager for deploying BRM cloud native servicesinto Kubernetes. A Helm chart is a collection of files that describe a set of Kubernetesresources. It includes YAML template descriptors for all Kubernetes resources and avalues.yaml file that provides default configuration values for the chart.

When you install a Helm chart, it generates valid Kubernetes manifest files byreplacing default values from values.yaml with custom values from override-values.yaml, and creates Kubernetes resources. Helm calls this a new release. Youuse the release name to track and maintain this installation.

Table 3-1 describes the Helm charts that are included in the BRM cloud nativedeployment package.

3-1

Table 3-1 BRM Cloud Native Helm Charts

Chart Name Description When to Use:

oc-cn-init-db-helm-chart This chart initializes andupgrades the databaseschema for BRM server.

• In initialize mode, it:

– Creates tables,views, procedures,indexes, and otherdatabase objectsneeded by BRMServer

– Loads seed data• In upgrade mode, it

modifies the existingdatabase schema tomatch the current patchset data model.

Use this chart in initializemode when you are preparinga new setup of BRM and havean empty database schema.

Use this chart in upgrademode when you have toupgrade your schema from12.0 Patch Set 2 to Patch Set3.

oc-cn-op-job-helm-chart This chart does the following:

• Creates WebLogic serverdomains for Billing Careand BOC.

• Installs applications intheir respective domains.

• Populates persistentvolumes with domain andapplication files forsharing betweenWebLogic serverruntimes.

If you want to use Billing Care,BOC, or the Billing CareREST API, install this chartbefore you install oc-cn-helm-chart.

oc-cn-helm-chart This chart does the following:

• Deploys BRM server,PDC, and PCC.

• Starts the WebLogicservers for Billing Careand BOC.

• Exposes web clients asservices outside of thecluster.

• Shares persistentvolumes between itsservices throughpersistent volume claims

Install this chart to use theservices of BRM server, PDC,PCC, Billing Care, BOC, orthe Billing Care REST API.

oc-cn-ece-helm-chart This chart does the following:

• Deploys ECE and itsservices.

• Sets up the connectionwith BRM server andPDC.

• Configures sharing ofpersistent volumes withBRM server.

Install this chart to use ECEas your convergent chargingsolution.

Chapter 3About Deploying into Kubernetes

3-2

Extracting the Helm ChartsBefore you install BRM cloud native services, extract the Oracle CommunicationsCloud Native Helm charts. To do so, enter these commands:

tar xvzf oc-cn-helm-chart-12.0.0.x.0.tgz

tar xvzf oc-cn-ece-helm-chart-12.0.0.x.0.tgz

tar xvzf oc-cn-op-job-helm-chart-12.0.0.x.0.tgz

tar xvzf oc-cn-init-db-helm-chart-12.0.0.x.0.tgz

Automatically Pulling Images from Private Docker RegistriesYou can automatically pull images from your private Docker registry by creating anImagePullSecrets, which contains a list of authorization tokens (or Secrets) foraccessing a private Docker registry. You then add references to theImagePullSecrets in your BRM Helm chart's override-values.yaml file. This allowsPods to submit the Secret to the private Docker registry whenever they want to pullimages.

Automatically pulling images from a private Docker registry involves these high-levelsteps:

1. Create a Secret outside of the Helm chart by entering this command:

kubectl create secret docker-registry SecretName --docker-server=RegistryServer --docker-username=UserName --docker-password=Password -n NameSpace

where:

• SecretName is the name of your Kubernetes Secret.

• RegistryServer is the fully qualified domain name (FQDN) of your privateDocker registry (repoHost:repoPort).

• UserName and Password is the user name and password for your privateDocker registry.

• NameSpace is the name space you will use for installing BRM Helm charts.

For example:

kubectl create secret docker-registry cgbu-docker-registry --docker-server=mydockerimages.com:2660/ --docker-username=xyz --docker-password=xyzj451av -n oms

2. Add the imagePullSecrets key to your override-values.yaml file for oc-cn-helm-chart:

imagePullSecrets: SecretName

3. Add the ocbrm.imageRepository key to your override-values.yaml file:

imageRepository: "RegistryServer"

Chapter 3Extracting the Helm Charts

3-3

4. Deploy the oc-cn-helm-chart.

Configuring the BRM Cloud Native Deployment PackageThe oc-cn-helm-chart Helm chart configures and deploys all of your product services.YAML descriptors in the oc-cn-helm-chart/templates directory use the oc-cn-helm-chart/values.yaml file for most of the values. The values.yaml file itself includescomments that describe each key. You can override the values by creating anoverride-values.yaml file.

Oracle recommends that you read the values.yaml file at least once to becomefamiliar with all of the options available.

Configuring the BRM cloud native deployment package involves these high-levelsteps:

• Configuring Global Values

• Configuring BRM Server

• Configuring BRM Server Components

• Deploying Paymentech Data Manager in HA Mode

• Configuring Elastic Charging Engine

• Configuring Pricing Design Center

• Configuring Pipeline Configuration Center

• Configuring Billing Care

• Configuring the Billing Care REST API

• Configuring Business Operations Center

Configuring Global ValuesTable 3-2 lists the keys in the values.yaml file that apply to all BRM components.

Table 3-2 Global Keys in Values.yaml File

Key Description

imageRepository The registry server where you have pushedimages. Typically, in the format“RepoHost:RepoPort/”.

The value is added as a prefix to all imagenames when you install or upgrade Helmcharts.

This key is empty by default.

Chapter 3Configuring the BRM Cloud Native Deployment Package

3-4

Table 3-2 (Cont.) Global Keys in Values.yaml File

Key Description

imagePullSecrets The name of the Secret that containscredentials for accessing images from yourprivate image server.

This is added to each Pod to give itpermission to pull the image from your privateregistry server. See "Automatically PullingImages from Private Docker Registries" formore information.

This key is empty by default.

efkStack.isEnabled Whether to use Elasticsearch, Fluentd, andKibana for log management (true) or not(false).

efkStack.namespace The name of the namespace in which theElasticsearch service is running.

Configuring BRM ServerConfiguring your BRM Server involves these high-level steps:

1. Deploying the BRM database schema:

• Deploying BRM with a New Schema

• Deploying BRM with an Existing Schema

2. Configuring the Helm chart for deploying BRM cloud native services. See"Configuring the BRM Helm Chart".

Note:

Before you deploy the BRM Helm chart, you must deploy an NFS-basedstorage provisioner that has ReadWriteMany access and then update theprovisioner details in the override-values.yaml file.

Deploying BRM with a New SchemaTo deploy BRM with a new database schema, deploy the Helm chart for init-db andthen deploy the Helm chart for BRM.

Note:

• Pre-create the schema user with the required grants for both BRMServer and pipeline.

• After the init-db Helm chart deploys successfully, you will need to deletethe init-db helm chart from its namespace.


3-5

For the init-db container, create the BRM schema user and pipeline schema user withthe required grants. See "Setting Your Database for BRM" in BRM Installation Guide.

Table 3-3 lists the keys that directly impact the BRM database schema and pipelinedatabase schema. Add these keys to your override-values.yaml file with the samepath hierarchy.

Caution:

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

Table 3-3 oc-cn-init-db-helm-chart Keys

Key Purpose

ocbrm.is_upgrade Specify whether to perform a fresh database initializationor to upgrade the existing database.

• True: Upgrades your existing database schema from12.0.0.2.0 to 12.0.0.3.0.

• False: Performs a fresh database initialization.

ocbrm.ece_deployed Specify whether ECE is deployed in your BRM cloud nativeenvironment.

• True: ECE configurations will be loaded into yourenvironment. This is the default.

• False: ECE configurations will not be loaded into yourenvironment.

ocbrm.imagePullPolicy The default value is IfNotPresent, which specifies to notpull the image if it's already present.

Applicable values are IfNotPresent and Always.

ocbrm.logDir The path to the dm-oracle log files.

ocbrm.LOG_LEVEL The dm-oracle log level.

ocbrm.brm_root_pass The BRM root password. The value can be per user.

You must generate a secret. Add this key to your override-values.yaml file with the same path hierarchy.

ocbrm.wallet.client The password for the client wallet.


ocbrm.wallet.server The password for the server wallet.


ocbrm.wallet.root The password for the root wallet.


ocbrm.db.host The IP address or the host name of the machine on whichthe BRM database is configured.

ocbrm.db.port The port on which the BRM database is configured.

ocbrm.db.service The BRM database service name.


3-6

https://kubernetes.io/docs/concepts/configuration/secret/

Table 3-3 (Cont.) oc-cn-init-db-helm-chart Keys

Key Purpose

ocbrm.db.alias The name of the BRM database alias.

ocbrm.db.enable_partition Whether partitioning is enabled in your BRM database:

• True: Partitioning is enabled. This is the default.• False: Partitioning is disabled in your BRM database.

ocbrm.db.schemauser The BRM schema user name, which should be pre-createdwith all the required grants.

ocbrm.db.schemapass The BRM schema password.


ocbrm.db.schematablespace The name of the tablespace for the BRM schema. Thisfield is case-sensitive.

ocbrm.db.indextablespace The name of the Index tablespace for the BRM schema.This field is case-sensitive.

ocbrm.db.pipelineschemauser The BRM pipeline schema username, which should be pre-created with all the required grants.

ocbrm.db.pipelineschemapass The BRM pipeline schema password.


ocbrm.db.pipelineschematablespace

The name of the tablespace for the BRM pipeline schema.This field is case-sensitive.

ocbrm.db.pipelineindextablespace

The name of the Index tablespace for the BRM pipelineschema. This field is case-sensitive.

ocbrm.db.pipelinealias The name of the BRM pipeline database alias.

To commit seed data in the database:

1. Modify the init-db container before deploying the Helm chart. Theconfigmap_create_obj_2.yaml file needs to be modified to add thecorresponding PCM_OP_CREATE_OBJ input flist.

2. Modify the configmap_create_obj_2.yaml file to add the correspondingPCM_OP_CREATE_OBJ input flist. For example:

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

Deploying BRM with an Existing SchemaTo deploy BRM with an existing schema and with default Oracle images:


3-7

Note:

If the existing BRM schema is not up-to-date with 12.0.0.3.0, first upgradethe BRM schema by following the instructions in "Upgrading Your DatabaseSchema".

1. Copy the client wallet ($BRM_WALLET/client) files to the oc-cn-helm-chart/existing_wallet directory.

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

• ocbrm.existing_database: Set this to true.

• ocbrm.cm.load_localized: Set this to 0.

Alternatively, you could deploy BRM with an existing schema by doing this:

1. Create Docker images for each of the BRM Server components in the installedBRM staging area (using the same staging area that initialized the database).

2. In your override-values.yaml file for oc-cn-helm-chart, update the keys with theexisting schema credentials and set these keys:

• ocbrm.existing_database: Set this to true.

• ocbrm.use_oracle_brm_images: Set this to false.

• ocbrm.cm.load_localized: Set this to 0.

• ocbrm.db.queuename: Set this to match the queue name in the existingdatabase.

• obcrm.db.roamqueuename: If you want a database queue for RoamingPipeline, create another queue in the Oracle database by following theinstructions in "Creating Additional Account Synchronization Queues" in BRMInstallation Guide. Then, set the roamqueuename key to the name of thequeue you created.

3. Deploy oc-cn-helm-charts.

Configuring the BRM Helm ChartTable 3-4 lists the PVCs used by the BRM server.

Table 3-4 List of PVCs in BRM Server

PVC Name Pods

common-semaphore batch_pipeline

realtime_pipeline

roam_pipeline

ctqdir dm_vertex

custom-job-file brm_apps_job

cm

boc


3-8

Table 3-4 (Cont.) List of PVCs in BRM Server

PVC Name Pods

data batch_pipeline

roam_pipeline

fusa-temp dm_fusa

oms-rel-archive rel_daemon

oms-rel-input rel_daemon

oms-rel-reject rel_daemon

oms-uel-archive batch_controller

oms-uel-input batch_controller

oms-uel-reject batch_controller

outputcdr batch_pipeline

rel_daemon

outputreject batch_pipeline

rel_daemon

pipelinelog batch_pipeline

roam_pipeline

roamoutputcdr roam_pipeline

rel_daemon

roamoutputreject roam_pipeline

rel_daemon

service-order dm_prov_telco

brm_apps_job

virtual-time All Pods

Table 3-5 lists the keys that directly impact BRM Server Pods. Add these keys to youroverride-values.yaml file for oc-cn-helm-chart with the same path hierarchy.

Table 3-5 BRM Server Keys

Key Path in values.yamlFile

Description

ENABLE_SSL ocbrm For SSL-enabled deployment required inpin.conf.

isSSLEnabled ocbrm For SSL-enabled deployment required inInfranet.properties.

is_upgrade ocbrm Whether to upgrade the Helm chart from PatchSet 2 to Patch Set 3 (true) or not (false).

ece_deployed ocbrm Whether ECE is deployed in your BRM cloudnative environment (true) or not (false).


3-9

Table 3-5 (Cont.) BRM Server Keys


Description

cmSSLTermination ocbrm Whether to make the CM the SSL endpoint forthe BRM cloud native deployment.

• true: The CM is the SSL endpoint. In thiscase, TLS can be enabled only betweenBRM client applications and the CM. TLSis disabled between CM and alldownstream components such as DMs andEMs. Communication between externalclients and the CM will still be encrypted byTLS 1.2. This setting can increaseperformance, because it eliminates theoverhead needed to handle TLS beforeprocessing the PCP packets.

When set to true, also set theENABLE_SSL key to 1 and theisSSLEnabled key to true.

• false: SSL is enabled across allcomponents, from client to CM to DMs andEMs. This is the default.

customSSLWallet ocbrm Whether to use a custom TLS certificate for theCM. See "Using a Custom TLS Certificate forSecure Connections".

• true: A custom TLS certificate is used forthe CM.

When set to true, also set thecmSSLTermination key to true and movethe Oracle wallet (brm_custom_wallet)containing the custom TLS certificate to thetop level of the Helm chart.

• false: The default TLS certificate is usedfor the CM. This is the default.

rotate_password ocbrm Whether to rotate the BRM root password. See"Rotating the BRM Root Password".

• true: The BRM root password is replacedwith the one specified in thenew_brm_root_password key.

• false: The BRM root password is notchanged. This is the default.

new_brm_root_password

ocbrm The new BRM root password. Use this key onlywhen ocbrm.rotate_password is set to true.See "Rotating the BRM Root Password".

enable_publish ocbrm.cm.deployment Whether to publish events (1) or not (0).

The default is 0.

provisioning_enabled

ocbrm.cm.deployment Whether to enable the provisioning of serviceorders (true) or not (false).

The default is false.

simulate_agent ocbrm.cm.deployment Whether to publish service orders (0) or not (1).

The default is 1.


3-10

Table 3-5 (Cont.) BRM Server Keys


Description

dm_vertex.enabled ocbrm Whether to deploy dm_vertex (true) or not(false).


roampipe.enabled ocbrm Whether to deploy the Roaming Pipeline (true)or not (false).


weblogic.enabled ocbrm.wsm.deployment When set to true, deploys BRM Web ServicesManager in the Oracle WebLogic Server image.


tomcat.enabled ocbrm.wsm.deployment When set to true, deploys BRM Web ServicesManager in the Apache Tomcat image.


load_localized ocbrm.cm Set this to 0 if oc-cn-init-db-helm-chart isn'tdeployed and you're using an existingdatabase.

The default is 1.

custom_files.enable

ocbrm.cm Whether to expose the oc-cn-helm-chart/cm_custom_files directory as a ConfigMap(true) or not (false).

custom_files.path ocbrm.cm Set this to /oms/load.

smtp ocbrm.dm_email.deployment

Set this to your SMTP server name, such asocbrm.us.oracle.com.

enabled ocbrm.virtual_time Set this to true to enable pin_virtual_time.

sync_pvt_time ocbrm.virtual_time The number of seconds between eachsynchronization of pin_virtual_time with allPods. The default is 0 seconds.

client_location ocbrm.wallet The location of the Oracle wallet containingTLS certificates used by client applications liketestnap.

Set this to the same values in theocbrm.wallet.* keys from oc-cn-init-db-helm-chart if deployed.

If you built the Docker images, update theexisting wallet location.

server_location ocbrm.wallet The location of the Oracle wallet containingTLS certificates presented by serverapplications (CM/DM/EM).

ocbrm.db* ocbrm.db.* Set this to the same values as the ocbrm.db.*keys from oc-cn-init-db-helm-chart.

mountOptions ocbrm.storage_class Set this to the NFS-based provisioner version.

provisioner ocbrm.nfs_provisioner Set this to the NFS-based provisioner name.

By default, all optional managers are enabled. If you don't want to use an optionalmanager, remove its corresponding YAML files from the templates directory andcomment out its related CM pin.conf file entries. For example, to disable dm-fusa,


3-11

you'd remove the dm_fusa_pvc.yaml, dm_fusa.yaml,configmap_env_dm_fusa.yaml, and configmap_pin_conf_fusa_simulator.yamlfiles from the templates directory. You'd also comment out the entry for dm-fusa fromthe CM pin.conf file.

The fusa simulator is added for testing purposes only. In a production environment,dm-fusa will be connected to a Paymentech server rather than a fusa simulator. Thus,in a production environment, remove the fusa simulator YAML files(configmap_pin_conf_fusa_simulator.yaml, config_env_fusa_simulator.yaml,and fusa_simulator.yaml).

Deploy the oc-cn-init-db-helm-chart and oc-cn-helm-chart charts in differentnamespaces.

Before you deploy BRM Server, do this:

• Deploy your storage provisioner with ReadWriteMany access.

• In the override-values.yaml file for oc-cn-helm-chart, update the provisionerdetails.

Configuring BRM Server ComponentsYou can configure these BRM server components:

• CM ConfigMap. See "Configuring a CM ConfigMap Directory".

• EAI Publisher. See "Configuring an EAI Publisher".

• Configurator jobs. See "Configuring the Configurator Job".

• BRM-Apps jobs. See "Configuring the brm-apps Job".

• Batch Controller. See "Configuring Multiple Replicas of Batch Controller".

Configuring a CM ConfigMap DirectoryYou expose a CM directory as a ConfigMap so the BRM cloud native deployment canaccess your custom input files.

To expose the oc-cn-helm-chart/cm_custom_files directory as a ConfigMap, do this:

1. Move your custom input files to the oc-cn-helm-chart/cm_custom_filesdirectory.

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

• ocbrm.cm.custom_files.enable: Set this to true.

• ocbrm.cm.custom_files.path: Set this to the location of your custom inputfiles, such as /oms/load.

3. Set the path in the ConfigMap file configmap_pin_conf_cm.yaml.

4. If you have already installed the BRM cloud native deployment, do a Helmupgrade. See "Updating a Helm Release".

For example, to load new tax codes using the taxcodes_map file, you would do this:

1. Edit the taxcodes_map file and move it to the oc-cn-helm-chart/cm_custom_files directory.

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


3-12

ocbrm.cm.custom_files.enable=trueocbrm.cm.custom_files.path=/oms/load

3. Set the path in the ConfigMap file configmap_pin_conf_cm.yaml:

- fm_rate taxcodes_map /oms/load/taxcodes_map

4. Update your Helm release. See "Updating a Helm Release".

Configuring an EAI PublisherThe payload configuration file used by the EAI Java Server (eai_js) process can beloaded as a Kubernetes ConfigMap and consumed by eai_js from /oms/payload. Thepayload configuration file (payloadconfig_ifw_sync.xml) is available with the BRMHelm chart.

To use a different payload configuration XML file:

1. Copy the new payload configuration file to the oc-cn-helm-chart/payload_xmldirectory.

2. In your override-values.yaml file for oc-cn-helm-chart, set theocbrm.eai_js.eaiConfigFile key to the name of your new payload configurationfile.

3. Update the Helm release. See "Updating a Helm Release".

Configuring the Configurator JobYou use the configurator job to run BRM load utilities on demand without entering intothe Pod. See "Supported Load Utilities for Configurator Jobs" for a list of utilities thatare supported by the configurator job.

To set up the configurator job to run BRM load utilities:

1. Update the oc-cn-helm-chart/config_scripts/loadme.sh script with the loadutilities that you want to run.

2. Move any required input files to the oc-cn-helm-chart/config_scripts directory.

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

4. Update the Helm release (see "Updating a Helm Release").

If you need to restart the CM after the configurator job runs, you must update thesekeys in the override-values.yaml file and then update the Helm release (see"Updating a Helm Release"):

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

• ocbrm.config_jobs.run_apps: Set this to false

Example: load_pin_bus_params and load_pin_device_state

This example shows how to set up the configurator job to run load_pin_bus_paramsand load_pin_device_state utilities.

To run load_pin_bus_params with the bus_params_billing_flow.xml file as inputand then run load_pin_device_state, do this:


3-13

1. Create the oc-cn-helm-chart/config_scripts/loadme.sh script by entering this:

$ cat loadme.sh cd /oms/sys/data/config; load_pin_bus_params -v /oms/load/bus_params_billing_flow.xml cd /oms/sys/data/config; load_pin_device_state -v /oms/sys/data/config/pin_device_state_num exit 0

2. Move the bus_params_billing_flow.xml input file to the oc-cn-helm-chart/config_scripts directory.

If the input file is an XML file and it has an XSD path, modify the XML file to referto the container path. If the XML has just an XSD file name, move the XSD filealong with the XML file.

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


5. Since load_pin_bus_params requires a CM restart, set these keys in theoverride-values.yaml file and then update the Helm release (see "Updating aHelm Release").

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

• ocbrm.config_jobs.run_apps: Set this to false

Configuring the brm-apps JobYou use the brm-apps job to run applications and utilities on demand without enteringinto a Pod. See "Supported Utilities and Applications for brm-apps Jobs" for a list ofsupported utilities and applications.

To set up the brm-apps job to run BRM applications:

1. Update the oc-cn-helm-chart/brmapps_scripts/loadme.sh script to include theapplications and utilities that you want to run.

2. Move any required input files to the oc-cn-helm-chart/brmapps_scriptsdirectory.

3. In your override-values.yaml file for oc-cn-helm-chart, set theocbrm.brm_apps.job.enable key to true.


To make sure the brm-apps job is not run again in the next Helm upgrade, disable thebrm-apps job by updating this key in your override-values.yaml file and then updatingthe Helm release again (see "Updating a Helm Release"):

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

Running Custom Applications and Utilities through brm-appsRunning custom utilities through a brm-apps job involves these high-level steps:

1. Identifying all binaries, libraries, and configuration files that are required for thecustom utility to run.

2. Layering the binaries and libraries on top of the brm-apps image.


3-14

If any configuration needs to be done when the container starts, modify theentrypoint.sh script and layer it while building the brm-apps image.

3. Converting configuration files into ConfigMaps, if required.

Example: pin_billing_custom

This example shows how to set up a custom utility named pin_billing_custom to runthrough a brm-apps job.

1. Convert the utility's pin.conf configuration file into a ConfigMap, which will bemounted inside the container in the path /oms/custom_pin.conf.

For information about converting a pin.conf file into a ConfigMap, refer to anyconfigmap_pin_conf file in the oc-cn-helm-chart/template directory.

2. Copy the entrypoint.sh script from the oc-cn-docker-files directory to the /omsdirectory.

3. In the entrypoint.sh script, under the brm-apps section, add a line for copyingthe /oms/custom_pin.conf file to the apps/pin_billing_custom directory.

4. Layer the pin_billing_custom binary, the modified entrypoint.sh script, and theapps/pin_billing_custom directory into a brm-apps image by creating thisdockerfile_custom_brm_apps file:

Note:

Ensure that the scripts and binaries have execute permission.

vi dockerfile_custom_brm_apps FROM brm_apps:12.0.0.x.0 USER root COPY pin_billing_custom /oms/bin/ RUN mkdir /oms/apps/pin_billing_custom COPY entrypoint.sh /oms/ RUN chown -R omsuser:oms /oms/bin/pin_billing_custom /oms/apps/pin_billing_custom /oms/entrypoint.sh && \ chmod -R 755 /oms/bin/pin_billing_custom /oms/apps/pin_billing_custom /oms/entrypoint.sh USER omsuser

5. Build the Docker image by entering this command:

docker build –t brm_apps:12.0.0.x.0-custom –f dockerfile_custom_brm_apps .

6. Update the oc-cn-helm-chart/template/brm_apps_job.yaml file to mount theConfigMap in the container:

volumeMounts:- name: brm-apps-custom-pin-conf mountPath: /oms/custom_pin.conf subPath: pin.confvolumes:- name: brm-apps-custom-pin-conf


3-15

configMap: name: brm-apps-custom-conf

7. Add the pin.conf file entries to the ConfigMap:

apiVersion: v1kind: ConfigMapmetadata: name: brm-apps-custom-conf namespace: {{ .Release.Namespace }} labels: application: {{ .Chart.Name }}data: pin.conf: | #************************************************************************ pin.conf content here #************************************************************************

8. Update the Docker image tag in your override-values.yaml file.

Running Custom Applications and Utilities through BOCRunning a custom utility from BOC involves these high level steps:

1. Building a custom brm-apps image by following the instructions in "RunningCustom Applications and Utilities through brm-apps".

2. (Optional) Building a custom BOC image.

The default BOC image includes system libraries such as glibc, libaio, andlibstdc. See the BOC Dockerfile in oc-cn-docker-files for a list of all packagedlibraries.

If the custom utility requires any system libraries that are not packaged in thepackaged BOC image, perform these steps:

• Build a custom BOC image by layering the default BOC image with therequired system libraries.

• Update the BOC image name and tag in the override-values.yaml keysunder the ocboc.boc.deployment path.

3. Updating the brm-apps image name and tag for the initContainer in the override-values.yaml keys under ocboc.boc.initContainer.

4. Updating the oc-cn-helm-chart/template/domain_boc.yaml file to mount theConfigMap in the container:

• Add the ConfigMap name under the volumes section:

volumes: - name: brm-apps-custom-pin-conf configMap: name: brm-apps-custom-conf


3-16

• Add the volumeMount to the initContainer:

volumeMounts:- name: brm-apps-custom-pin-conf mountPath: /oms/custom_pin.conf subPath: pin.conf

Note:

In the domain_boc.yaml file, add volumeMounts after pin-conf-config-brm-apps-volume-2.

Setting Utility ParametersYou can configure MTA applications such as pin_bill_accts and pin_export_priceoutside of the Kubernetes cluster. To do so, you edit these keys underocbrm.brm_apps.deployment.ApplicationName in your override-values.yaml file:

• mtaChildren: Specify the number of worker threads to spawn to perform thespecified work.

• mtaPerBatch: Specify the number of account objects to process by each workerthread in batch mode.

• mtaPerStep: Specify the number of account objects to return by each search step.

• mtaFetchSize: Specify the number of objects to receive from the database in ablock and cached in system memory for processing.

For example:

mtaChildren: 5mtaPerBatch: 500mtaPerStep: 1000mtaFetchSize: 5000

After you edit the keys in the YAML file, update the Helm release. See "Updating aHelm Release".

Configuring Multiple Replicas of Batch ControllerIf you load event files into the BRM cloud native deployment through Universal Event(UE) Loader, you can improve the throughput by running multiple replicas of the batch-controller Pod. In this case, each Pod can select a file from those available in the UELoader input PersistentVolumeClaim (PVC). When an individual Pod copies the fileinto its local file system for processing, the other input files are distributed among theremaining batch-controller Pod replicas. The time a file arrives in the input PVCdetermines which Pod gets to process the file.

To configure the number of replicas:

1. Set this key in your override-values.yaml file for oc-cn-helm-chart:

Values.ocbrm.batch_controller.deployment.replicaCount: Set this to thenumber of replicas to create of the batch-controller Pod.


3-17

2. If you have already installed the BRM Helm chart, update the Helm release. See"Updating a Helm Release".

For more information about UE Loader, see BRM Loading Events.

Deploying Paymentech Data Manager in HA ModePaymentech supports only one connection to its batch port at any one time. Therefore,to support high availability and increase the throughput to the Paymentech server,deploy two Paymentech Data Manager (dm-fusa) images, with each image using adifferent batch port for connecting to the Paymentech server.

Deploying two images provides failover support for dm-fusa. If one dm-fusadeployment goes down, the traffic from CM to dm-fusa will be redirected to the otherdm-fusa deployment. The load is also distributed among all dm-fusa deployments.

To deploy two dm-fusa images:

1. Edit the keys in the configmap_pin_conf_dm_fusa.yaml file for your system.

2. Edit these keys in the configmap_env_dm_fusa.yaml file:

DMF_BATCH_PORT_2: "8781" DMF_BATCH_SRVR_2: fusa-simulator-2 DMF_ONLINE_PORT_2: "9781" DMF_ONLINE_SRVR_2: fusa-simulator-2

Note:

Unlike the batch port, simultaneous transactions can be sent to thePaymentech online port. Thus, the values of DMF_ONLINE_PORT_2and DMF_ONLINE_SRVR_2 can be the same as or different from that ofthe first dm-fusa deployment.

3. Rename the _dm_fusa_2.yaml file to dm_fusa_2.yaml.


Using the FUSA Simulator

For testing purposes, a second deployment of the FUSA simulator is provided in thetemplates directory. To deploy a second version of the FUSA simulator, rename the_fusa_simulator_2.yaml file to fusa_simulator_2.yaml and then update the Helmrelease (see "Updating a Helm Release").

Note:

The deployment scripts and configuration files for the FUSA simulator areprovided for testing purposes only. In a production environment, removethese files: fusa_simulator.yaml, fusa_simulator_2.yaml,configmap_pin_conf_fusa_simulator.yaml, andconfigmap_env_fusa_simulator.yaml.


3-18

Configuring Elastic Charging EngineConfiguring Elastic Charging Engine (ECE) involves these high-level steps:

1. Overriding the ECE-specific keys in the oc-cn-ece-helm-chart/values.yaml file.See "Adding Elastic Charging Engine Keys".

2. Enabling SSL in ECE. See "Enabling SSL in Elastic Charging Engine".

3. Setting up volume mounts for ECE. See "About Elastic Charging Engine VolumeMounts".

4. Integrating Apache Kafka and Apache ZooKeeper with ECE. See "IntegratingApache Kafka and ZooKeeper with ECE".

5. Using third-party library and custom mediation specs. See "Using Third-PartyLibrary and Custom Mediation Specifications".

6. Loading BRM_CONFIG XMLs. See "Loading BRM Configuration XML Files".

7. Using a Custom TLS Certificate for Secure Connections. See "Using a CustomTLS Certificate for Secure Connections".

8. Scaling of Pods. See "Scaling Kubernetes Pods".

9. Enabling Federation in ECE. See "Enabling Federation in ECE".

10. Executing SDK Sample Scripts. See "Running SDK Jobs".

11. Customizing SDK source code. See "Customizing SDK Source Code".

Before installing the ECE Helm chart, you must first publish the metadata, config, andpricing data from the PDC Pod.

Note:

Kubernetes looks for the CPU limit setting for Pods. If it's not set, Kubernetesallocates a default value of 1 CPU per Pod, which causes CPU overheadand Coherence scalability issues. To prevent this from happening, overrideeach ECE Pod's CPU limit to be the maximum CPU available on the node.

Adding Elastic Charging Engine KeysTable 3-6 lists the keys that directly impact ECE deployment. Add these keys to youroverride-values.yaml file for oc-cn-ece-helm-chart.

Table 3-6 Elastic Charging Engine Keys

Key Path invalues.yamlFile

Description

imagePullPolicy container The default value is IfNotPresent, which specifiesto not pull the image if it's already present.Applicable values are IfNotPresent and Always.

containerPort container The port number that is exposed by this container.


3-19

Table 3-6 (Cont.) Elastic Charging Engine Keys


Description

DNAME sslconnectioncertificates

The domain name. For example: "CN=Admin,OU=Oracle Communication Application, O=OracleCorporation, L=Redwood Shores, S=California,C=US"

SSLKEYSTOREVALIDITY sslconnectioncertificates

The validity of the KeyStore, in days. A value of200 indicates that the validity is 200 days.

jmxexporterport charging.jmxexporter

The JMX exporter port used to monitor the state ofthe ECE components. By default, the value is9090.

jmxConfigYaml charging.jmxexporter

The configuration YAML file is by default emptysince there are no filters applied while accessingthe JMX exporter port for the data. A blacklist andwhitelist of mbean names can be added if filteringis needed.

jmx_prometheus_jar charging.jmxexporter

The JAR file used for running the JMX exporter. Bydefault, thejmx_prometheus_javaagent-0.12.0.jar is used.To change to a different version of the JAR file, itcan be added to the external mount PVC for third-party JAR files, and the new JAR name can beprovided here.

pod_state_id_tag charging.jmxexporter

The format of the mBean stateManagerstateidentifier, which identifies the current status ofthe ECE deployment. This is the default format forthe current version of the JMX exporter JAR that isbeing used. Update this value with the new formatif the JMX exporter JAR version is upgraded.

pod_partition_unbalanced_tag

charging.jmxexporter

The format of the mBean partition unbalanced,which identifies the unbalanced partition count.This is the default format for the current version ofthe JMX exporter JAR that is being used. Updatethis value with the new format if the JMX exporterJAR version is upgraded.

replicas charging.<component-name>

The number of replicas to be created whiledeploying the chart. The default replica count is 3for ecs server, and 1 for all other components.

coherenceMemberName charging.<component-name>

The Coherence member name under which thiscomponent will be added to the Coherence cluster.

jmxEnabled charging.<component-name>

Whether the component is JMX-enabled (true) ornot (false).

coherencePort charging.<component-name>

The optional value indicating the Coherence portused the component.

jvmGCOpts charging.<component-name>

This field gives an option to provide the Java JVMoptions such as GC details, max memory, and minmemory.


3-20



Description

jvmJMXOpts charging.<component-name>

This field gives an option to provide the JMX-related option.

jvmCoherenceOpts charging.<component-name>

This field gives an option to provide theCoherence-related options such as the overridefile and cache config file.

jvmOpts charging.<component-name>

This field is empty by default, and any additionalJVM arguments can be provided here.

labels charging The label for all Pods in the deployment. Thedefault value is ece.

jmxport charging The JMX port exposed by the ece, which can beused to log in to the Jconsole.

terminationGracePeriodSeconds

charging Used for graceful shutdown of the Pods. Thedefault value is 180 seconds.

sdkEnabled charging Whether the SDK job needs to be run as part ofthe deployment (true) or not (false). The defaultvalue is false.

If set to true, a default SDK job is executed as partof the Helm installation.

isFederation charging This option is to be used during disaster recovery,when the primary and secondary clusters areinvolved. The default value is false.

primaryCluster charging Whether the deployment machine is a primarycluster (true) or not (false).If true, all of the components will be installed in themachine. The default is true.

This value should be set to false while deployingECE in the secondary site.

secondaryCluster charging Whether the deployment machine is a secondarycluster (true) or not (false).If true, only ecs, the gateways, and REF areinstalled.

customSSLWallet charging This field indicates whether to use the custom SSLwallet or not. Applicable values are true and false.By default, this value is set to false.

secretCustomWallet.name charging The secret custom wallet name.

clusterName charging The name of the cluster in which to deploy ECE.

This same cluster name will be used for the HTTPGateway and Diameter Gateway as well.

eceWalletLocation charging The location where the ECE wallet needs to becreated. The default is /home/charging/opt/ECE/oceceserver/wallet.


3-21



Description

brmWalletServerLocation charging The location of the BRM installation servercwallet.sso file. For example: /home/charging/opt/ECE/oceceserver/brmwallet/server/cwallet.sso.

brmWalletClientLocation charging The location of the BRM installation clientcwallet.sso file. For example:/home/charging/opt/ECE/oceceserver/brmwallet/client/cwallet.sso.

brmWalletLocation charging The location of the BRM wallet directory. Forexample: /home/charging/wallet/brmwallet.

brmrellocation charging The location of the RE Loader input directory. Thedefault is /home/charging/rel_input.

<tags> charging The remaining tags indicate the values that will bestored under charging-settings.xml. The tagnames are the same as the ones used in thecharging-settings.xml file for ease of mapping.

eceServiceName charging.cluster.primary

The ECE service name that creates theKubernetes cluster with all of the ECE componentsin the primary cluster. The default is ece-server.

eceServicefqdn charging.cluster.primary

The fully qualified domain name (FQDN) of theECE service running in the primary cluster. Forexample: ece-server.NameSpace.svc.cluster.local.

eceServiceName charging.cluster.secondary

The ECE service name that creates theKubernetes cluster with all of the ECE componentsin the secondary cluster.

eceServicefqdn charging.cluster.secondary

The fully qualified domain name (FQDN) of theECE service in the secondary cluster. Forexample: ece-server.NameSpace.svc.cluster.local.

<tags> migration The different tags indicating the values that will bestored under migration-configuration.xml. Thetag names are the same as the ones used in themigration-configuration.xml file for ease ofmapping.

<tags> testtools The different tags indicating the values that will bestored under test-tools.xml. The tag names arethe same as the ones used in the test-tools.xmlfile for ease of mapping.

<module> log4j2.logger The different log levels for each module representsthe logging level for the corresponding module.

<tags> eceproperties The different tags indicating the values that will bestored under ece.properties. The tag names arethe same as the ones used in the ece.propertiesfile for ease of mapping.


3-22



Description

<tags> JMSConfiguration

The different tags indicating the values that will bestored under JMSConfiguration.xml. The tagnames are the same as the ones used in theJMSConfiguration.xml file for ease of mapping.

chargingSettingManagementPath

volume The location of the management folder, whichcontains the charging-settings.xml, test-tools.xml, and migration-configuration.xml files.

The default is /home/charging/opt/ECE/oceceserver/config/management.

chargingSettingPath volume The location of the configuration folder for ECE.The default is /home/charging/opt/ECE/oceceserver/config.

name secretEnv The user-defined name to give for the Secrets.The default is secret-env.

INFRANET_CONNECTION

secretEnv The infranet connection string to connect to BRM.

walletPassword secretEnv The string password for opening the wallet.

JMSQUEUEPASSWORD secretEnv The password for the JMS queue, which is storedunder the key jms.queue.notif.pwd in the wallet.

RADIUSSHAREDSECRET

secretEnv The RADIUS secret password, which is stored asradius.secret.pwd in the wallet.

BRMDATABASEPASSWORD

secretEnv The database password for the BRM database.

BRMGATEWAYPASSWORD

secretEnv The BRM Gateway password.

PDCPASSWORD secretEnv The PDC password, which is stored as pdc.pwd inthe wallet.

PDCKEYSTOREPASSWORD

secretEnv The PDC KeyStore password, which is stored aspdc.keystore.pwd in the wallet.

ECEHTTPGATEWAYSERVERSSLKEYSTOREPASSWORD

secretEnv The server SSL KeyStore password for the HTTPGateway.

BRM_SERVER_WALLET_PASSWD

secretEnv The password to open the BRM server wallet.

BRM_ROOT_WALLET_PASSWD

secretEnv The root wallet password of the BRM wallet.

SSLENABLED sslconnectioncertificates

Whether to install ECE under SSL mode (true) ornot (false). The default is true.

name pv.external The name of the external PV. The default isexternal-pv.

hostpath pv.external The location on the host system of the externalPV. The default is /scratch/qa/ece_config/.

accessModes pv.external The access mode for the PV. The default isReadWriteMany.


3-23



Description

capacity pv.external The maximum capacity of the external PV.

name pvc.logs The name for the ECE log files. The default islogs-pv.

hostPath pvc.logs The location on the host system for the ECE logfiles.

accessModes pvc.logs The access mode for the PVC. The default isReadWriteMany, since all of the differentcomponent Pods will be writing their respective logfiles into a single logs directory.

storage pvc.logs The storage space required initially to create thisPVC. If the storage specified here is not availablein the machine, ensure that the PVC is not createdand that the Pods do not get initialized.

name pvc.brmconfig

The name of the BRM Config PVC, in which allBRM configuration files such as the payload configfile are exposed outside of the Pod.

accessModes pvc.brmconfig

The access mode for the PVC. The default isReadWriteMany.

storage pvc.brmconfig

The storage space required initially to create thisPVC. If the storage specified here is not availablein the machine, ensure that the PVC is not createdand that the Pods do not get initialized.

name pvc.sdk The name for the SDK PVC, in which all of theSDK files such as the config, sample scripts, andsource files are exposed to the user.

accessModes pvc.sdk The access mode for the PVC. The default isReadWriteMany.

storage pvc.sdk The storage space required initially to create thisPVC. If the storage specified here is not availablein the machine, ensure that the PVC is not createdand that the Pods do not get initialized.

name pvc.wallet The name for the wallet PVC, in which the walletdirectory will be stored and shared by all of the ecsPods. The default is ece-wallet-pvc.

accessModes pvc.wallet The access mode for the PVC. The default isReadWriteMany.

storage pvc.wallet The storage space required initially to create thisPVC. If the storage specified here is not availablein the machine, ensure that the PVC is not createdand that the Pods do not get initialized.

name pvc.external The name for the external PVC, in which the third-party JARs can be placed to share with the Pods.The default is external-pvc.

accessModes pvc.external The access mode for the PVC. The default isReadWriteMany.


3-24



Description

storage pvc.external The storage space required initially to create thisPVC. If the storage specified here is not availablein the machine, ensure that the PVC is not createdand that the Pods do not get initialized.

name pvc.rel The name of the RE Loader PVC as created in theBRM deployment.

name storageClass The name of the storage class.

Enabling SSL in Elastic Charging EngineTo complete the configuration for SSL setup in ECE:

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

• sslconnectioncertificates.SSLENABLED: Set this to true.

• sslEnabled: Set this to true in emGatewayConfigurations,httpGatewayConfigurations, and BRMConnectionConfiguration.

• migration.pricingUpdater.keyStoreLocation: Set this to /home/charging/opt/ECE/oceceserver/config/client.jks.

• charging.brmWalletServerLocation: Set this to /home/charging/wallet/brmwallet/server/cwallet.sso.

• charging.brmWalletClientLocation: Set this to /home/charging/wallet/brmwallet/client/cwallet.sso.

• charging.brmWalletLocation: Set this to /home/charging/wallet/brmwallet.

• charging.emGatewayConfigurations.emGatewayConfigurationList.emGateway1Config.wallet: Set this to the BRM wallet location.

• charging.emGatewayConfigurations.emGatewayConfigurationList.emGateway2Config.wallet: Set this to the BRM wallet location.

• charging.radiusGatewayConfigurations.wallet: Set this to the BRM walletlocation.

• charging.connectionConfigurations.BRMConnectionConfiguration.brmwallet: Set this to the BRM wallet location.

2. Copy the SSL certificates, such as client.jks and public-admin.cer, generatedfrom PDC to the pdc_ssl_keystore directory in the external PVC.

3. Configure the connectionURL, port, and protocol as per the PDC-configured t3schannel.


3-25

About Elastic Charging Engine Volume Mounts

Note:

You must use a provisioner that has ReadWriteMany access and sharingbetween Pods.

The ECE container requires Kubernetes volume mounts for third-party libraries. Thethird-party volume mount shares the third-party libraries required by ECE from the hostsystem with the container file system. For the list of third-party libraries to download,see "ECE Software Compatibility" in BRM Compatibility Matrix. Place the library filesunder the third-party volume mount.

The default configuration comes with a hostPath PersistentVolume. For moreinformation, see "Configure a Pod to Use a PersistentVolume for Storage" inKubernetes Tasks.

To use a different type of PersistentVolume, such as NFS, modify the oc-cn-ece-helm-chart/templates/ece-pvc.yaml file.

Integrating Apache Kafka and ZooKeeper with ECE

Note:

In an ECE cloud native environment, only Apache Kafka is supported fornotification handling.

Apache Kafka is used for notification handling in the ECE cloud native environment.

To integrate Apache Kafka and ZooKeeper with ECE, do this:

1. Create these Kafka topics either in the Kafka entrypoint.sh script or after theKafka Pod is ready:

• kafka.topicName: ECENotifications

• kafka.suspenseTopicName: ECESuspenseQueue

2. Set zookeeper-cluster in a ZooKeeper runtime ConfigMap and refer to it in theZK_CLUSTER environment variable in the Kafka pod.

ece-zookeeper-0.ece-zookeeper.NameSpace.svc.cluster.local

3. Set these Kafka and ZooKeeper-related environment variables appropriately:

• KAFKA_PORT

• KAFKA_HOST_NAME

• REPLICATION_FACTOR

• PARTITIONS

• TOPIC_NAME


3-26

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

• SUSPENSE_TOPIC_NAME

• ZK_CLUSTER

• ZK_CLIENT_PORT

• ZK_SERVER_PORT

4. Ensure that the Kafka and ZooKeeper Pods are in a READY state.

5. Set these keys in your override-values.yaml file for oc-cn-ece-helm-chart:

• charging.server.kafkaEnabledForNotifications: Set this to true.

• charging.server.kafkaConfigurations.name: Set this to the name of yourECE cluster.

• charging.server.kafkaConfigurations.hostname: Set this to the host nameof the machine on which Kafka is up and running.

• charging.server.kafkaConfigurations.topicName: Set this to the name ofthe ECE Notification topic.

• charging.server.kafkaConfigurations.suspenseTopicName: Set the to thename of the ECE Suspense topic.

Using Third-Party Library and Custom Mediation SpecificationsTo use third-party libraries and custom mediation specifications with ECE:

1. Place all third-party libraries in the 3rdparty_jars directory inside external-pvc.

2. Place your custom mediation specifications in the ece_custom_data directoryinside external-pvc.

3. Install the ECE Helm chart.

Note:

If you need to load the mediation specification after the initial ECE set up,delete the configloader job and the perform a Helm upgrade. The mediationspecifications will be loaded into ECE cache from the config loader job.

Loading BRM Configuration XML FilesBRM configuration consists of pin_notify and payload_config_ece_sync.xml. Toensure that the BRM Pod can access these files for configuring the EAI Java Server(eai_js), they are exposed through the brm_config PVC within the pricingupdater Pod.When new metadata is synchronized with ECE, if there are updates to the payloadconfiguration file, it will create a new file in the location which can be accessed andconfigured in BRM.

For more information, see "Enabling Real-Time Synchronization of BRM and ECECustomer Data Updates" in ECE Implementing Charging.


3-27

Using a Custom TLS Certificate for Secure ConnectionsTo configure ECE to use a custom TLS certificate for communicating with externalservice providers, set these keys in the override-values.yaml file for oc-cn-ece-helm-chart:

• charging.customSSLWallet: Set this to true.

• charging.secretCustomWallet.name: Set this to the Secret name.

• charging.emGatewayConfigurations.emGatewayConfigurationList.emGateway1Config.wallet: Set this to /home/charging/wallet/custom/cwallet.sso.

• charging.emGatewayConfigurations.emGatewayConfigurationList.emGateway2Config.wallet: Set this to the custom wallet path.

• charging.brmWalletServerLocation: Set this to the custom wallet path.

• charging.brmWalletClientLocation: Set this to the custom wallet path.

• charging.brmWalletLocation: Set this to the custom wallet path.

• charging.radiusGatewayConfigurations.wallet: Set this to the custom walletpath.

• charging.connectionConfigurations.BRMConnectionConfiguration.brmwallet: Set this to the custom wallet path.

Note:

If the custom wallet is deployed after ECE is installed, perform a Helmupgrade. You can update the wallet location configured for ECE Pods suchas RADIUS, EM Gateway, and BRM Gateway by using JMX.

Scaling Kubernetes PodsKubernetes Pods that are created as part of the deployment can be scaled up ordown. By default, three ECE server replicas are created during the installationprocess.

To scale a Kubernetes Pod, enter this command:

Note:

Kubernetes Pods can be scaled only if the partitions are balanced.

kubectl scale statefulsets componentName --replicas=newReplicaCount

If scaling doesn't occur, check the partitionUnbalanced count underCoherence.service.partitionUnbalanced for all cache services.


3-28

Enabling Federation in ECEEnabling federation in ECE involves these high-level steps:

1. Setting up the primary cluster by updating these keys in your override-values.yaml file for oc-cn-ece-helm-chart:

Note:

Set the jvmCoherenceOpts keys in eachcharging.<coherenceMemberName> section with CoherenceFederation parameters for the primary and secondary cluster.

• charging.clusterName: Set this to the name of your primary cluster.

• charging.isFederation: Set this to true.

• charging.primaryCluster: Set this to true.

• charging.secondaryCluster: Set this to false.

• charging.cluster.primary.eceServiceName: Set this to the ECE servicename that creates the Kubernetes cluster with all ECE components in theprimary cluster.

• charging.cluster.primary.eceServicefqdn: Set this to the fully qualifieddomain name (FQDN) of the ECE service running in the primary cluster. Forexample: ece-server.NameSpace.svc.cluster.local.

• charging.cluster.secondary.eceServiceName: Set this to the ECE servicename that creates the Kubernetes cluster with all ECE components in thesecondary cluster.

• charging.cluster.secondary.eceServicefqdn: Set this to the FQDN of theECE service. For example: ece-server.NameSpace.svc.cluster.local.

2. Install oc-cn-ece-helm-chart by entering this command from the helmchartsdirectory:

helm install ReleaseName oc-cn-ece-helm-chart --namespace NameSpace --values OverrideValuesFile

This brings up the necessary Pods in the primary cluster.

3. Set up the secondary cluster by updating these keys in your override-values.yaml file for oc-cn-ece-helm-chart:

Note:

Set the jvmCoherenceOpts keys in eachcharging.<coherenceMemberName> section with CoherenceFederation parameters for the primary and secondary cluster.

• charging.clusterName: Set this to the name of your secondary cluster.


3-29

• charging.isFederation: Set this to true.

• charging.secondaryCluster: Set this to true.

• charging.primaryCluster: Set this to false.

• charging.cluster.primary.eceServiceName: Set this to the ECE servicename that creates the Kubernetes cluster with all ECE components in theprimary cluster.

• charging.cluster.primary.eceServicefqdn: Set this to the fully qualifieddomain name (FQDN) of the ECE service running in the primary cluster. Forexample: ece-server.NameSpace.svc.cluster.local.

• charging.cluster.secondary.eceServiceName: Set this to the ECE servicename that creates the Kubernetes cluster with all ECE components in thesecondary cluster.

• charging.cluster.secondary.eceServicefqdn: Set this to the FQDN of theECE service in the secondary cluster. For example: ece-server-2.NameSpace.svc.cluster.local.

4. Install oc-cn-ece-helm-chart by entering this command from the helmchartsdirectory:

helm install ReleaseName oc-cn-ece-helm-chart --namespace NameSpace --values OverrideValuesFile

This brings up the necessary Pods in the secondary cluster.

5. Connect to JMX with the ecs Pod on the primary cluster by running the followingcommand. Then, run the start and replicateAll methods from the coordinatornode of each ECE federation cache.

kubectl -n NameSpace port-forward ecs-pod jmx_port

Running SDK JobsTo set up the SDK job to run sample scripts:

1. In the override-values.yaml file for the ECE Helm chart, set thecharging.sdkEnabled key to true.

2. The SDK directory containing the SDK sample scripts, configuration files, sourcecode, and so on is exposed in the PVC defined under the pvc.sdk section of thevalues.yaml file.

3. In the launcher.sh script, under the OPTIONS parameter in the run() method, addthis line:

-Dtangosol.coherence.member=memberName -Dtangosol.coherence.wka=eceServiceName -Dcoherence.cluster=clusterName

where:

• memberName can be any user-defined name.

• eceServiceName is the name of the ECE headless service, as configured inthe values.yaml file under the same name.

• clusterName is the name of the coherence cluster, as configured in thevalues.yaml file under the same name.


3-30

4. During the Helm install, if the sdkEnabled key is set to true, it creates a defaultSDK job that prints this since you have not run the SDK job with any validparameters.

"Run the SDK job with script name and parameters. Usage - cd usage; sh <scriptname> build; sh <scriptname> run <parameters>"

5. The SDK job then goes into a Completed state. You can check the logs printed bythe job by running this command:

kubectl logs sdkJobName

6. After deployment completes and all of the Pods are in a healthy state, you can runany sample SDK script using the helm upgrade command in the following format:

`helm upgrade eceDeploymentName helmChartFolder --set jobname=SDKJobName --set command="cd <folder-name>; sh <script-name> build; sh <scriptname> run <parameters>"`

where:

• eceDeploymentName: is the deployment name given during "helm install". Thedeployment name can be retrieved by executing "helm ls" command.

• helmChartFolder: is the location where ece helm chart is located.

• SDKJobName is the user-defined name for this instance of the SDK job.

• command is the command to execute as part of the job. The SDK job runsfrom the ocecesdk/bin directory, so the user only needs to provide the scriptfile location from the reference point of the ocecesdk/bin directory.

For example:

helm upgrade ece . --set jobname=samplegprssessionjob --set command="cd usage; sh sample_gprs_session.sh build; sh sample_gprs_session.sh run 773-20190923 INITIATE 60 1024 1024 TelcoGprs EventDelayedSessionTelcoGprs 1.0 2020-02-10T00:01:00 1024 1024 sessionId CUMULATIVE 1"

This command will not affect any other running Pod in the namespace, except itcreates a job with the name set in the command with "jobname". The job executesthe command provided under the field "command".

7. After the job completes, it goes into a Completed state. You can check the logs byrunning this command:


sdkJobName will be available from the kubectl get po command. The job namewill be in the format:

JobName-IDfromKubernetes.

8. To view the logs created by the SDK script, check the sdk logs folder in the PVC.


3-31

Error Handling for SDK JobsAny error while running the SDK job, such as running sample usage when the ECEhas not reached UsageProcessing state, or invalid parameter values, will result in thejob going into an Error state. You can check the reason for the error by doing this:

1. Running this command, which prints the output of the script:


2. Checking the log file created under the SDK PVC location.

After correcting the error, upgrade the Helm release with a new job name. See"Running SDK Jobs".

If you don't provide any commands while running the Helm upgrade, the defaultcommand prints this:

Run the SDK job with script name and parameters. Usage - cd usage; sh <scriptname> build; sh <scriptname> run <parameters>

If you don't provide a job name, it uses the default job name of sdk. However, sinceKubernetes doesn't allow a completed job to be rerun, you would need to delete anyprevious job named sdk before running the Helm upgrade again.

Customizing SDK Source CodeIf you want to customize the ECE SDK source code for any of the sample scripts orJava code, the SDK directory with all of these files is exposed under the SDK PVC.You can change any file in the PVC, and the same will be reflected inside the Pod.

When you run the SDK job with the build and run options, the customized code isbuilt and run from the job.

Configuring Pricing Design CenterConfiguring PDC involves these high-level steps:

1. Overriding the PDC-specific keys in the values.yaml file. See "Adding PDC Keys".

2. Enabling SSL in the WebLogic domain. See "Enabling SSL in Your PDC Domain".

After PDC is deployed successfully, set the ocpdc.configEnv.useExistingData keyto true in the override-values.yaml file and then run a Helm upgrade using the samerelease name. When the PDC Pod gets deleted and restarted, the PDC Poddeployment will consider the ocpdc.configEnv.useExistingData key as true and willretain the existing data in the PDC database.

Adding PDC KeysTable 3-7 lists the keys that directly impact PDC deployment. Add these keys to youroverride-values.yaml file for oc-cn-helm-chart with the same path hierarchy.


3-32

Caution:

Keys with the path ocpdc.secretValue hold sensitive data. Handle themcarefully with controlled access to the file containing their values. Encode allof these values in base64. See "Secrets" in Kubernetes Concepts.

Table 3-7 Pricing Design Center Keys

Key Path invalues.yaml

Description

isEnabled ocpdc.Labels Whether to enable and deploy PDC and PDCJobs.

• true: Enables PDC, deploys the PDCapplication, and deploys PDC Jobs.

• false: Disables the PDC application and PDCJobs.

pdcHostPath ocpdc.volMnt Before you deploy PDC, ensure that this path hasread and write permissions

The path in which to create your PDC deploymentlog files.

Also, copy your SSL certificates to this path.

pdcIEHostPath ocpdc.volMnt Before you deploy PDC, ensure that this path hasread and write permissions

Copy your ImportExport XML files to this path.When the ImportExport operation completes, itcopies the ImportExport logs and XML files to thispath.

pdcBrmHostPath ocpdc.volMnt The path in which to:

• Create log files for the PDC-BRM integrationdeployment, the syncPDC utility, the real-timerating engine, and the batch rating engine.

• Copy payload XML files when the SyncPDCJob is run with the out option.

• Copy output XML files when persistOutFilesis enabled in the transformation engine

Before you deploy PDC, ensure that this path hasread and write permissions.

If ECE is enabled in your system, copy theEnrichment XML file to this directory.

storageSize ocpdc.volMnt The size of the storage paths for pdcHostPath,pdcIEHostPath, and pdcBrmHostPath.

exposePorts ocpdc.configEnv

Whether to expose the SSL HTTPS port, theHTTP port, or both.

• yes: Exposes the SSL HTTPS port only.• no: Exposes the HTTP port only.• all: Exposes both the HTTP port and the SSL

HTTPS port. This is the default.

adminUser ocpdc.configEnv

The WebLogic Server domain administrator username, which is usually weblogic.


3-33


Table 3-7 (Cont.) Pricing Design Center Keys


Description

t3ChannelPort ocpdc.configEnv

The port number for the t3 channel. The default is0.

Use this key if PDC needs to use the t3 protocol tocommunicate with an external system, such asElastic Charging Engine (ECE).

This key is mandatory.

t3ChannelAddress ocpdc.configEnv

The IP address for the master node or loadbalancer.

This key is optional.

t3sChannelPort ocpdc.configEnv

If SSL is enabled in the WebLogic domain, set thisto the port number of the t3s channel. The defaultis 0.

This key is mandatory.

t3sChannelAddress ocpdc.configEnv

If SSL is enabled in the WebLogic domain, set thisto the IP address for the master node or loadbalancer.

This key is optional.

supportECE ocpdc.configEnv

Whether to enable ECE in your BRM cloud nativedeployment.

• true: Enables ECE. This is the default.• false: Disables ECE.

rcuJdbcURL ocpdc.configEnv

The connection string for connecting to a databasewhere schemas needed by Oracle FusionMiddleware products will be created, especiallyOPSS. Use the format "host:port/service".

rcuSysDBAUser ocpdc.configEnv

The database user name. The default user namefor Oracle databases is SYS.

rcuPrefix ocpdc.configEnv

The prefix for the PDC domain RCU schema. Forexample, if the prefix is XYZ and the schemaname is STB, the PDC domain RCU schemaname will be XYZ_STB.

keyStoreType ocpdc.configEnv

The SSL KeyStore type for the PDC domain, suchas JKS.

keyStoreAlias ocpdc.configEnv

The alias name for the PDC domain SSLKeyStore.

keyStoreIdentityFileName ocpdc.configEnv

The name of the PDC domain SSL KeyStoreIdentity file.

keyStoreTrustFileName ocpdc.configEnv

The name of the PDC domain SSL TrustStore file.

crossRefDBHostName ocpdc.configEnv

The IP address or the host name of the machine inwhich the transformation cross-reference databaseis configured.

crossRefDBPort ocpdc.configEnv

The port number assigned to the transformationcross-reference database service.


3-34



Description

crossRefDBService ocpdc.configEnv

The name of the transformation cross-referencedatabase service.

crossRefDBUserName ocpdc.configEnv

The user name for the transformation cross-reference database.

This user should have these capabilities on thetransformation cross-reference database: createuser, grant any role, grant any privileges, selectany table for Enterprise edition, and DBA for XE.

crossRefSchemaPDCTableSpace

ocpdc.configEnv

The name of the PDC tablespace for thetransformation cross-reference schema. This fieldis case-sensitive.

crossRefSchemaTempTableSpace

ocpdc.configEnv

The name of the temporary tablespace for thetransformation cross-reference schema. This fieldis case-sensitive.

crossRefSchemaUserName

ocpdc.configEnv

The cross-reference database schema user name.

pdcAdminUser ocpdc.configEnv

The PDC admin user name, which includes thePricing Design Admin role.

pdcDBHostName ocpdc.configEnv

The IP address or the host name of the machine inwhich the PDC database is configured.

pdcDBPort ocpdc.configEnv

The port number assigned to the PDC databaseservice.

pdcDBService ocpdc.configEnv

The name of the PDC database service.

pdcDBUserName ocpdc.configEnv

The PDC database user name.

This should be the SYSDBA user, or the usershould have these capabilities on the PDCdatabase: create user, grant any role, grant anyprivileges, select any table for Enterprise edition,and DBA for XE.

pdcSchemaPDCTableSpace

ocpdc.configEnv

The tablespace name of the PDC schema. Thisfield is case sensitive.

pdcSchemaTempTableSpace

ocpdc.configEnv

The tablespace name of the temporary schema.This field is case sensitive.

pdcSchemaUserName ocpdc.configEnv

The PDC database schema user name.

useExistingData ocpdc.configEnv

When doing an upgrade, set this to true to use theexisting PDC database schema.


3-35



Description

IEComponent ocpdc.configEnv

The type of components and objects that theImportExportPricing utility can import and exportfrom the PDC database. Valid values include:

• config: Imports and exports setupcomponents, such as tax codes, businessprofiles, and general ledger IDs.

• pricing: Imports and exports pricingcomponents, such as events, charges, andchargeshares.

• metadata: Imports and exports the event,service, account, and profile attributespecifications.

• profile: Imports and exports pricing profiledata.

• customfields: Imports and exports customfields.

• brmobject: Exports the setup componentsthat are masted in PDC.

• all: Imports and exports all objects andcomponents.

Don't include the hyphen (-) prefix with the value.

See "ImportExportPricing" in PDC CreatingProduct Offerings for more information.

IE_FileName ocpdc.configEnv

The name of the XML file that contains the list ofcomponents and objects to import or export fromthe PDC database. This XML file is used by theImportExportPricing utility.

If importing or deleting components, copy the XMLfile to the HostPath specified in pdcIEHostPath.

extraCmdLineArgs ocpdc.configEnv

The extra command-line arguments for theImportExportPricing utility, apart from operation,component, and file name.

For example, -n ObjectName.


persistOutFiles ocpdc.configEnv

Whether to persist the output files generated bythe transformation engine.

• enabled: Keeps the output and payload filesin the out directory. This is not recommended.

• disabled: Removes the output and payloadfiles from the out directory. This is the default.


3-36



Description

SyncPDCStartAt ocpdc.configEnv

The scheduled time for running the syncPDCutility. Valid values include:

• startAt: The utility runs at the time the job wassubmitted.

• "HH:MM": The utility runs at the specifiedtime, where HH is an hour between 0 and 23,and MM is the minutes between 0 and 59. Forexample, enter "12:00" to schedule the utilityto run at noon.

See "About the SyncPDC Utility" in PDC CreatingProduct Offerings for more information.

SyncPDCInterval ocpdc.configEnv

The scheduled frequency for running thesyncPDC utility.

Enter a value in the format "N:U", where N is avalid number and U is one of these units: D (Daily),H (Hourly), or M (Minute).

For example, enter "2:D" to run the utility everyother day.

Note: A value of "24:H" is not the same as "1:D"due to daylight savings time (DST).

EnrichmentFileName ocpdc.configEnv

The name of the enrichment file.

Store the enrichment file in the path specified inpdcBrmHostPath. This is applicable at both PDCdeployment time and individual syncPdc run time.

PdcBrmOperation ocpdc.configEnv

Whether to start syncPDC, stop syncPDC, copythe payload and output XML files generated by thetransformation engine, or set a new BRM rootpassword in the BRM wallet.

• Empty value: No operation is performed. Thisis the default.

• start: Starts syncPDC. If the utility is alreadyrunning, the utility is stopped and restarted.

• stop: Stops the syncPDC utility.• out: Copies the output XML files from the

transformation directory to the directoryspecified in pdcBrmHostPath. The outputXML files are copied only if persistOutFiles isset to enabled.

• rotatepassword: Sets the new BRM rootpassword in the BRM wallet, which is part ofthe PDC Pod.

When you deploy PDC, ensure that this key hasan empty value.

Before doing a Helm upgrade to run SyncPDC,delete the pdc-sync-job Kubernetes job and thendo a Helm upgrade.


3-37



Description

PdcOperation ocpdc.configEnv

The operation for the ImportExportPricing utilityto perform. Valid values include:

• Empty value: No operation is performed. Thisis the default.

• export: The utility exports data from PDC.• import: The utility imports data to PDC.• publish: The utility publishes components

from PDC to the batch rating engine, real-timerating engine, or ECE.

• keep: The utility retains the latest version ofsuccessfully promoted PDC components.

• deleteprofile: The utility deletes pricingprofiles from PDC.

• type: The utility displays the pricing or setupcomponents available in PDC.

• log: The utility copies the Admin Server andPDC Server log files to the pdcHostPathfolder.

When you deploy PDC, ensure that this key hasan empty value.

Before doing a Helm upgrade to runImportExport, delete the pdc-ie-job Kubernetesjob and then do a Helm upgrade.

Don't include the hyphen (-) prefix with the value.


adminPassword ocpdc.secretValue

The password for the WebLogic domain'sadministrative user, which is used for accessingthe WebLogic Console for administrativeoperations.

rcuSysDBAPassword ocpdc.secretValue

The database administrator password for thedatabase in rcuJdbcURL.

rcuSchemaPassword ocpdc.secretValue

The password for the Oracle Fusion Middlewareproduct schemas that will be created by RCU,which is used by OPSS.

keyStoreIdentityKeyPass ocpdc.secretValue

The password for the PDC domain SSL identitykey.

keyStoreIdentityStorePass ocpdc.secretValue

The password for the PDC domain SSL identitystore.

keyStoreTrustStorePass ocpdc.secretValue

The password for the PDC domain SSLTrustStore.

crossRefSysDBAPassword

ocpdc.secretValue

The password for the transformation cross-reference database administrator user.

crossRefSchemaPassword

ocpdc.secretValue

The password for the transformation cross-reference database schema user.

pdcDBAPassword ocpdc.secretValue

The password for the PDC database administratoruser.


3-38



Description

pdcSchemaPassword ocpdc.secretValue

The password for the PDC database schema user.

walletPassword ocpdc.secretValue

The passwords for the PDC application wallet andPDC BRM integration wallet.

pdcAdminUserPassword ocpdc.secretValue

The password for the PDC admin user, whichincludes the Pricing Design Admin role.

Enabling SSL in Your PDC DomainTo access PDC over the HTTPS port, SSL must be enabled in the WebLogic domainwhere PDC is deployed. The BRM cloud native deployment package takes care of theconfiguration necessary to equip the WebLogic domain with SSL access.

As part of the PDC installation steps, enable SSL in your PDC domain:

1. If you have Java KeyStore (JKS) files with valid certificates, copy them to the pathset in the Values.ocpdc.volMnt.pdcHostPath key.

Note:

To generate JKS files and certificates, see "Using keytool to generate anIdentity Keystore" in Oracle WebLogic Server Administration ConsoleHelp.

2. Make certificate files available and accessible in all worker nodes, because PDCcan deploy in any of the worker nodes.

3. If you are moving from non-SSL to SSL, do this:

a. Add the SSL information to your override-values.yaml file, retaining the samePDC database details and setting the ocpdc.configEnv.useExistingData keyto true.

b. Redeploy PDC.

Configuring Pipeline Configuration CenterConfiguring Pipeline Configuration Center (PCC) involves these high-level steps:

1. Overriding the PCC-specific keys in the values.yaml file. See "Adding PipelineConfiguration Center Keys".

2. After PCC is deployed, enabling SSL in the WebLogic domain. See "Enabling SSLin Your Pipeline Configuration Center Domain".

3. Setting up your PCC log files. See "About Pipeline Configuration Center Logs".


3-39

https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/01-38-001-ConfiguringSSL/ConfiguringSSL.html

https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/01-38-001-ConfiguringSSL/ConfiguringSSL.html

Adding Pipeline Configuration Center KeysTable 3-8 lists the keys that directly impact PCC deployment. Add these keys to youroverride-values.yaml file for oc-cn-helm-chart.

Table 3-8 Pipeline Configuration Center Keys

Key Path inValues.yamlFile

Description

imageName ocpcc.pcc.deployment

The name of the PCC image, such as oracle/pcc.

imageTag ocpcc.pcc.deployment

The tag name for the PCC image, such as12.0.0.x.0.

httpPort ocpcc.pcc.configEnv

The container HTTP port on which PCC will berunning.

httpsPort ocpcc.pcc.configEnv

The container HTTPS port on which PCC will berunning.

isSSLEnabled ocpcc.pcc.configEnv

Set this to true if you want to run PCC on an SSL-enabled port. Otherwise, set this to false.

keyStoreType ocpcc.pcc.configEnv

The keystore type, such as JKS.

keyStoreAlias ocpcc.pcc.configEnv

The string alias used to store and retrieve theserver's private key. This is used for setting up theSSL-enabled domain.

keyStoreIdentityFileName ocpcc.pcc.configEnv

The name of your keystore file.

keyStoreTrustFileName ocpcc.pcc.configEnv

The name of your truststore file.

adminUser ocpcc.pcc.configEnv

The WebLogic Server domain administrator username, which is usually weblogic.

adminPort ocpcc.pcc.configEnv

The WebLogic Server domain administrator port.

isAdminPortEnabled ocpcc.pcc.configEnv

Set this to true if a separate admin port needs toenabled for PCC. Otherwise, set this to false.

rcuJdbcURL ocpcc.pcc.configEnv

The connection string for connecting to thedatabase where schemas needed by OracleFusion Middleware products are created,especially OPSS. Use the format "host:port/service".

rcuSysDBAUser ocpcc.pcc.configEnv

The database user name. The default user namefor Oracle databases is SYS.

rcuPrefix ocpcc.pcc.configEnv

The RCU prefix for the database schema name.

rcuRecreate ocpcc.pcc.configEnv

Set this to true to drop and re-create an existingdatabase schema. Otherwise, set this to false.

featureSets ocpcc.pcc.configEnv

The feature set and patch set you are deploying(that is, PCC:12.0.0.x.0).


3-40

Table 3-8 (Cont.) Pipeline Configuration Center Keys

Key Path inValues.yamlFile

Description

brmServicePoidId ocpcc.pcc.configEnv

The POID for the BRM service.

brmServiceType ocpcc.pcc.configEnv

The BRM service type (that is, /service/admin_client).

brmRootLogin ocpcc.pcc.configEnv

The BRM root login user name.

pccUser ocpcc.pcc.configEnv

The PCC user name to be created as part ofinstallation.

Table 3-9 lists the secret keys that directly impact PCC deployment. These keys holdsensitive data and must be handled carefully with controlled access to the filecontaining its values. See "Secrets" in Kubernetes Concepts.

Add these secret keys to your override-values.yaml file, and encode all of theirvalues in Base64.

Note:

• You can encode strings in Linux by using this command:

echo -n 'tmb' | base64

• You can decode strings in Linux by using this command:

echo 'dG1i' | base64 --decode

Table 3-9 Pipeline Configuration Center Secret Keys

Key Description

ocpcc.pcc.secretVal.adminPassword

The WebLogic Server administrative password encoded inBase64.

ocpcc.pcc.secretVal.walletPassword

The PCC wallet password encoded in Base64.

ocpcc.pcc.secretVal.rcuSysDBAPassword

The Database Administrator password encoded in Base64.

ocpcc.pcc.secretVal.rcuSchemaPassword

The password for schemas of Oracle Fusion Middlewareproducts that will be created by RCU, which is used byOPSS. The value must be Base64-encoded.

ocpcc.pcc.secretVal.keyStoreIdentityKeyPass

The KeyPass of Identity Keystore, which is used for settingup the SSL-enabled domain. The value must be Base64-encoded.

ocpcc.pcc.secretVal.keyStoreIdentityStorePass

The StorePass of Identity Keystore, which is used for settingup the SSL-enabled domain. This value must be Base64-encoded.


3-41


Table 3-9 (Cont.) Pipeline Configuration Center Secret Keys

Key Description

ocpcc.pcc.secretVal.keyStoreTrustStorePass

The StorePass of the Trust Keystore, which is used forsetting up the SSL-enabled domain. This value must beBase64-encoded.

ocpcc.pcc.secretVal.pccUserPassword

The PCC user password encoded in Base64.

Enabling SSL in Your Pipeline Configuration Center DomainTo access PCC over the HTTPS port, SSL must be enabled in the WebLogic domainwhere PCC is deployed. The BRM cloud native deployment package takes care of theconfiguration necessary to equip the WebLogic domain with SSL access.

To complete the configuration for SSL setup:

1. Create a keystore_pcc directory under oc-cn-helm-chart.

2. Copy these Java KeyStore (JKS) files with valid certificates to the oc-cn-helm-chart/keystore_pcc directory.

• identity.jks: Provides the certificate to identify the server.

• trust.jks: Establishes trust for the certificate.

If your KeyStore files have different file names, override thekeyStoreIdentityFileName and keyStoreTrustFileName keys in the override-values.yaml file.

During installation, Helm uses these KeyStore files to create a secret, which will bemounted as a volume inside the Pipeline Configuration Center Pod.

About Pipeline Configuration Center LogsLog files for Pipeline Configuration Center are stored in the container's /u01/logsdirectory. This directory also contains domain logs, server logs, and RCU logs.

Because the container's /u01/logs directory has an emptyDir volume mount, the logfiles will be deleted when a Pod is removed from a node. To retain your log files, youcan either:

• Attach a side-car application logging service, which copies the log files outside ofthe container for analysis.

• Change the type of volume mount and directly persist the log files on permanentstorage disk.

Configuring Billing CareYou deploy Billing Care in a cloud native environment by using these charts:

• op-cn-op-job-helm-chart: Creates the Billing Care domain and installs theapplication with all the files residing on Persistent Volumes.

• oc-cn-helm-chart: Starts the WebLogic servers that are hosting the Billing Careapplication.


3-42

• WebLogic Operator chart: Manages the Billing Care domain, controlling theservice availability when managed server Pods are scaled up or down.

Configuring Billing Care involves these high-level steps:

1. Overriding the Billing Care-specific keys from the values.yaml file for oc-cn-op-job-helm-chart and oc-cn-helm-chart. See "Adding Billing Care Keys".

2. Setting up volume mounts for Billing Care. See "About Billing Care VolumeMounts".

3. Creating a WebLogic domain and installing Billing Care. See "Creating aWebLogic Domain and Installing the Billing Care Application".

4. Starting and stopping WebLogic servers. See "Starting and Stopping WebLogicServers".

5. Exposing Billing Care services outside of a cluster. See "Exposing Billing CareServices Outside a Cluster".

Note:

To set up Billing Care, ensure that you successfully complete the installationof oc-cn-op-job-helm-chart before you install or upgrade oc-cn-helm-chart.

Adding Billing Care KeysTable 3-10 lists a few important keys that directly impact Billing Care. Add these keysto your override-values.yaml file with the same path hierarchy.

For the complete set of keys to personalize your Billing Care deployment, see the keyswith the path ocbc.bc in the oc-cn-op-job-helm-chart/values.yaml and oc-cn-helm-chart/values.yaml files.

Caution:

Keys with the path ocbc.bc.secretVal hold sensitive data. Handle themcarefully with controlled access to the override file containing their values.Encode all of these values in base64. See "Secrets" in KubernetesConcepts.


3-43


Table 3-10 Billing Care Keys


Chart Description

isEnabled ocbc.bc oc-cn-op-job-helm-chart

oc-cn-helm-chart

Whether to deploy, configure, and start BillingCare services:

• false: Does not create the Kubernetesresources for using Billing Care.

• true: Creates the Kubernetes resourcesfor using Billing Care. This is the default.

nodeSelector ocbc.bc oc-cn-op-job-helm-chart

oc-cn-helm-chart

The node selector rules for schedulingWebLogic Server Pods on particular nodesusing simple selectors.

affinity ocbc.bc oc-cn-op-job-helm-chart

oc-cn-helm-chart

The affinity rules for scheduling WebLogicServer Pods on particular nodes using morepowerful selectors.

imageTag ocbc.bc.deployment

oc-cn-op-job-helm-chart

oc-cn-helm-chart

The tag associated with the image. This isgenerally the patch set number. Prefix thevalue with a colon (:). For example, :12.0.0.3.0.

rcuJdbcURL ocbc.bc.configEnv


The connection string for connecting to thedatabase where schemas needed by OracleFusion Middleware products will be created,especially OPSS.

ldapHost ocbc.bc.configEnv


The host name or IP address of the LDAPServer (for example, OUD) where users andgroups will be configured for access to BillingCare.

ldapPort ocbc.bc.configEnv


The port number on which the LDAP server islistening.

ldapGroupBase

ocbc.bc.configEnv


The LDAP base DN that contains groups.

ldapUserBase ocbc.bc.configEnv


The LDAP base DN that contains users.

bipUrl ocbc.bc.configEnv


The URL for PublicReportService_v11 fromyour BI Publisher instance, which is used byBilling Care to show invoices.

bipUserId ocbc.bc.configEnv


The name of the user with access to the BIPublisher instance for viewing invoices fromBilling Care.

adminPassword

ocbc.bc.secretVal


The password of the WebLogic domain'sadministrative user, which is used foraccessing the WebLogic Console foradministrative operations.

ldapPassword ocbc.bc.secretVal


The password of the LDAP Server admin user.


3-44

Table 3-10 (Cont.) Billing Care Keys


Chart Description

walletPassword

ocbc.bc.secretVal


The password for storing wallet sensitive datafor BRM connections.

bipPassword ocbc.bc.secretVal


The password of the BI Publisher instance.

rcuSysDBAPassword

ocbc.bc.secretVal


The password for the rcuJdbcURL databaseadministrator.

rcuSchemaPassword

ocbc.bc.secretVal


The passwords for the schemas of OracleFusion Middleware products that will becreated by RCU, which is used by OPSS.

domainUID ocbc.bc.wop oc-cn-op-job-helm-chart

oc-cn-helm-chart

The name of the domain. The default isbillingcare-domain.

adminChannelPort

ocbc.bc.wop oc-cn-op-job-helm-chart

oc-cn-helm-chart

The NodePort where the admin-server's httpservice will be accessible.

domainVolHostPath


oc-cn-helm-chart

The location with shared grant permissionsbetween worker nodes. The domain will becreated and stored here for sharing betweenservers in a cluster.

appVolHostPath


oc-cn-helm-chart

The location with shared grant permissionsbetween worker nodes. Applications will beinstalled and stored here for sharing betweenservers in a cluster.

serverStartPolicy


oc-cn-helm-chart

The WebLogic servers that the Operator startswhen it discovers the domain:

• NEVER: Does not start any server in thedomain.

• ADMIN_ONLY: Starts only theadministration server (no managed serverswill be started.)

• IF_NEEDED: Starts the administrationserver and clustered servers up to thereplica count.

appLogLevel ocbc oc-cn-helm-chart

The logging level at which application logsmust be captured in log files: SEVERE,WARNING, INFO, CONFIG, FINE, FINER,FINEST, and ALL.

About Billing Care Volume MountsThe Billing Care container requires Kubernetes volume mounts for sharing the domainand application file system between the WebLogic Cluster servers. These volumes aredomainVolHostPath and appVolHostPath.


3-45

• The WebLogic domain is created on the domainVolHostPath volume mount byoc-cn-op-job-helm-chart and used when the servers are started by oc-cn-helm-chart.

• The Billing Care application home is created on the appVolHostPath/billingcarevolume mount by oc-cn-op-job-helm-chart, which is referred to by the serversstarted by oc-cn-helm-chart.

• The batch payment file system is also set up on appVolHostPath volume mountunder lockbox directory

• All logs are persisted on domainVolHostPath/logs/billingcare-domain directory


Note:

The selected location must be accessible on all worker nodes across whichWebLogic Servers will be distributed based on defined nodeSelector oraffinity rules.

To use a different type of PersistentVolume, such as NFS, modify the following:

• The oc-cn-op-job-helm-chart/templates/volume_domain_billingcare.yaml filefor the domain file system.

• The oc-cn-op-job-helm-chart/templates/volume_app_billingcare.yaml file forBilling Care and batch payments file system.

Creating a WebLogic Domain and Installing the Billing Care ApplicationThe WebLogic domain is created by a Kubernetes Job when oc-cn-op-job-helm-chart is installed. The same job also installs the Billing Care application and deploysthe application WAR file onto the WebLogic Cluster.

The oc-cn-op-job-helm-chart chart also:

• Creates a Kubernetes ConfigMap and Secrets, which are used throughout the life-cycle of the WebLogic domain.

• Initializes the PersistentVolumeClaim for the domain and application file systemas well as third-party libraries.

Note:

The override-values.yaml file that you use for this chart must include BRMoverride values.

After you install oc-cn-op-job-helm-chart, wait until the Kubernetes Job completessuccessfully. Then, you can install or upgrade oc-cn-helm-chart for Billing Care


3-46


services. The STATUS of its Pod should be Completed, and its READY state shouldbe 0/1.

After the jobs are completed successfully, don't delete the chart. Its resources will beused for starting and stopping the servers through oc-cn-helm-chart.

If you want to re-install the Billing Care domain, ensure that you delete the chart andempty the domainVolHostPath and appVolHostPath volumes before you reinstallthe charts.

Starting and Stopping WebLogic ServersWhen you install oc-cn-op-job-helm-chart, the default configuration sets up aWebLogic Cluster with five Managed Servers. When you install or upgrade oc-cn-helm-chart for the Billing Care service, two of the Managed Servers and one AdminServer are started.

By modifying the override-values.yaml file for oc-cn-helm-chart, you can control:

• The total number of Managed Servers and the initial server start up by using thetotalManagedServers and initialServerCount keys.

• Whether the servers are started or stopped by using the serverStartPolicy key.To start the Admin Servers and the Managed Servers in a Cluster, set the key toIF_NEEDED. To stop all servers, set the key to NEVER.

Note:

The keys in the override-values.yaml file should be the same as the onesused in oc-cn-op-job-helm-chart for keys that are common in both charts

After you modify the override-values.yaml file, update the Helm release for thechanges to take effect. See "Updating a Helm Release".

Exposing Billing Care Services Outside a ClusterWebLogic Operator creates a minimum of one service per WebLogic Server and oneservice for a WebLogic Cluster. To access Billing Care, you expose the WebLogicCluster service outside of the Kubernetes cluster.

To expose Billing Care outside of the Kubernetes cluster, you must add a loadbalancer with path-based routing for the WebLogic Cluster service. The load balanceryou select must support sticky sessions. That is, if the load balancer redirected aclient’s login request to Managed Server 1, all subsequent requests from that clientshould be redirected to Managed Server 1.

To secure communications outside of the cluster, enable TLS between the client andthe load balancer.

Configuring the Billing Care REST APIYou deploy the Billing Care REST API in a cloud native environment by using thesecharts:


3-47

• op-cn-op-job-helm-chart: Creates the Billing Care REST API domain and installsthe REST API with all of the files residing on Persistent Volumes.

You provide Oracle Access Manager details in this chart for token generation andauthorization.

• oc-cn-helm-chart: Starts the WebLogic servers that are hosting the Billing CareREST API.

• WebLogic Operator chart: Manages the Billing Care REST API domain,controlling the service availability when managed server Pods are scaled up ordown.

Configuring the Billing Care REST API involves these high-level steps:

1. Overriding the Billing Care REST API-specific keys from the values.yaml file. See"Adding Billing Care REST API Keys".

2. Setting up volume mounts for the Billing Care REST API. See "About the BillingCare REST API Volume Mounts".

3. Creating a WebLogic domain and installing the Billing Care REST API. See"Creating a WebLogic Domain and Installing the Billing Care REST API".


5. Exposing Billing Cares REST API services outside of a cluster. See "ExposingBilling Care REST API Services Outside a Cluster".

Note:

To set up the Billing Care REST API, ensure that you successfully completethe installation of op-cn-op-job-helm-chart before you install or upgrade oc-cn-helm-chart.

Adding Billing Care REST API KeysTable 3-11 lists a few important keys that directly impact the Billing Care REST API.Add these keys to your override-values.yaml file with the same path hierarchy.

For the complete set of keys to personalize your Billing Care REST API deployment,see the keys with the path ocbc.bcws in the oc-cn-op-job-helm-chart/values.yamland oc-cn-helm-chart/values.yaml files.

Caution:

Keys with the path ocbc.bcws.secretVal hold sensitive data. Handle themcarefully with controlled access to the override file containing their values.Encode all of these values in base64. See "Secrets" in KubernetesConcepts.


3-48


Table 3-11 Billing Care REST API Keys


Chart Description

isEnabled ocbc.bcws oc-cn-op-job-helm-chart

oc-cn-helm-chart

Whether to deploy, configure, and start BillingCare REST API services:

• false: Does not create the Kubernetesresources for using the Billing Care RESTAPI.

• true: Creates the Kubernetes resourcesfor using the Billing Care REST API. Thisis the default.

nodeSelector ocbc.bcws oc-cn-op-job-helm-chart

oc-cn-helm-chart

The node selector rules for schedulingWebLogic Server Pods on particular nodesusing simple selectors.

affinity ocbc.bcws oc-cn-op-job-helm-chart

oc-cn-helm-chart

The affinity rules for scheduling WebLogicServer Pods on particular nodes using morepowerful selectors.

imageTag ocbc.bcws.deployment


oc-cn-helm-chart

The tag associated with the image. This isgenerally the patch set number. Prefix thevalue with a colon (:). For example, :12.0.0.3.0.

rcuJdbcURL ocbc.bcws.configEnv


The connection string for connecting to thedatabase where schemas needed by OracleFusion Middleware products will be created,especially OPSS.

ldapHost ocbc.bcws.configEnv


The host name or IP address of the LDAPServer (for example, OUD) where users andgroups will be configured for access to theBilling Care REST API.

ldapPort ocbc.bcws.configEnv


The port number on which the LDAP server islistening.

ldapGroupBase

ocbc.bcws.configEnv


The LDAP base DN that contains groups.

ldapUserBase ocbc.bcws.configEnv


The LDAP base DN that contains users.

bipUrl ocbc.bcws.configEnv


The URL for PublicReportService_v11 fromyour BI Publisher instance, which is used bythe Billing Care REST API to show invoices.

bipUserId ocbc.bcws.configEnv


The name of the user with access to the BIPublisher instance for viewing invoices from theBilling Care REST API.

oauthIdDomain

ocbc.bcws.configEnv


The name of the identity domain created inOracle Access Manager.

oauthResource

ocbc.bcws.configEnv


The name of the resource server created inOracle Access Manager.


3-49

Table 3-11 (Cont.) Billing Care REST API Keys


Chart Description

oauthUrl ocbc.bcws.configEnv


The URL to the Oracle Access Managermanaged server. For example: http(s)://hostname:port/oauth2/rest.

adminPassword

ocbc.bcws.secretVal


The password of the WebLogic domain'sadministrative user, which is used foraccessing the WebLogic Console foradministrative operations.

ldapPassword ocbc.bcws.secretVal


The password of the LDAP Server admin user.

walletPassword

ocbc.bcws.secretVal


The password for storing wallet sensitive datafor BRM connections.

bipPassword ocbc.bcws.secretVal


The password of the BI Publisher instance.

rcuSysDBAPassword

ocbc.bcws.secretVal


The password for the rcuJdbcURL databaseadministrator.

rcuSchemaPassword

ocbc.bcws.secretVal


The passwords for the schemas of OracleFusion Middleware products that will becreated by RCU, which is used by OPSS.

domainUID ocbc.bcws.wop


oc-cn-helm-chart

The name of the domain. The default is bcws-domain.

adminChannelPort

ocbc.bcws.wop


oc-cn-helm-chart

The NodePort where the admin-server's HTTPservice will be accessible.

domainVolHostPath

ocbc.bcws.wop


oc-cn-helm-chart

The location shared between worker nodes inwhich the domain will be created and stored forsharing between servers in a cluster.

appVolHostPath

ocbc.bcws.wop


oc-cn-helm-chart

The location shared between worker nodes inwhich applications will be installed and storedfor sharing between servers in a cluster.

serverStartPolicy

ocbc.bcws.wop


oc-cn-helm-chart

The WebLogic servers that the Operator startswhen it discovers the domain:

• NEVER: Does not start any server in thedomain.

• ADMIN_ONLY: Starts only theadministration server (no managed serverswill be started.)

• IF_NEEDED: Starts the administrationserver and clustered servers up to thereplica count.


3-50

Table 3-11 (Cont.) Billing Care REST API Keys


Chart Description

appLogLevel ocbc oc-cn-helm-chart

The logging level at which application logsmust be captured in log files: SEVERE,WARNING, INFO, CONFIG, FINE, FINER,FINEST, and ALL.

About the Billing Care REST API Volume MountsThe Billing Care REST API container requires Kubernetes volume mounts for sharingthe domain and application file system between the WebLogic Cluster servers. Thesevolumes are domainVolHostPath and appVolHostPath.


• The Billing Care REST API home is created on the appVolHostPath/bcws volumemount by oc-cn-op-job-helm-chart, which is referred to by the servers started byoc-cn-helm-chart.

• The batch payment file system is also setup on appVolHostPath volume mountunder lockbox directory

• All logs are persisted on domainVolHostPath/logs/bcws-domain directory


Note:



• The oc-cn-op-job-helm-chart/templates/volume_domain_bcws.yaml file forthe domain file system.

• The oc-cn-op-job-helm-chart/templates/volume_app_bcws.yaml file for theBilling Care REST API and batch payments file system.

Creating a WebLogic Domain and Installing the Billing Care REST APIThe WebLogic domain is created by a Kubernetes Job when oc-cn-op-job-helm-chart is installed. The same job also installs the Billing Care REST API and deploysthe application WAR file onto the WebLogic Cluster.



3-51




Note:


After you install oc-cn-op-job-helm-chart, wait until the Kubernetes Job completessuccessfully. Then, you can install or upgrade oc-cn-helm-chart for Billing CareREST API services. The STATUS of its Pod should be Completed, and its READYstate should be 0/1.


If you want to re-install the Billing Care REST API domain, ensure that you delete thechart and empty the domainVolHostPath and appVolHostPath volumes before youreinstall the charts.

Starting and Stopping WebLogic ServersWhen you install oc-cn-op-job-helm-chart, the default configuration sets up aWebLogic Cluster with five Managed Servers. When you install or upgrade oc-cn-helm-chart for the Billing Care REST API service, two of the Managed Servers andone Admin Server are started.




Note:

The keys in the override-values.yaml file should be the same as the onesused in oc-cn-op-job-helm-chart for keys that are common in both charts


Exposing Billing Care REST API Services Outside a ClusterWebLogic Operator creates a minimum of one service per WebLogic Server and oneservice for a WebLogic Cluster. To access the Billing Care REST API, you expose theWebLogic Cluster service outside of the Kubernetes cluster.


3-52

To expose the Billing Care REST API outside of the Kubernetes cluster, you must adda load balancer with path-based routing for the WebLogic Cluster service. The loadbalancer you select must support sticky sessions. That is, if the load balancerredirected a client’s login request to Managed Server 1, all subsequent requests fromthat client should be redirected to Managed Server 1.


Configuring Business Operations CenterYou deploy BOC in a cloud native environment by using these charts:

• op-cn-op-job-helm-chart: Creates the BOC domain and installs the applicationwith all of the domain and application files residing on Persistent Volumes.

• oc-cn-helm-chart: Starts the WebLogic servers that are hosting the BOCapplication.

• WebLogic Operator: Manages the BOC domain, controlling the serviceavailability when managed server Pods are scaled up or down.

Configuring BOC involves these high-level steps:

1. Overriding the BOC-specific keys in the values.yaml file. See "Adding BusinessOperations Center Keys".

2. Setting up volume mounts. See "About Business Operations Center VolumeMounts".

3. Creating a WebLogic domain and installing the BOC application. See "Creating aWebLogic Domain and Installing the Business Operations Center Application".


5. Exposing BOC services outside of the cluster. See "Exposing Business OperationsCenter Services Outside a Cluster".

Note:

To set up BOC, ensure that you successfully complete the installation of op-cn-op-job-helm-chart before you install or upgrade oc-cn-helm-chart.

Deploying BOC using oc-cn-helm-chart requires kubectl and the brm-appsimage. These images must be ready before you install or upgrade oc-cn-helm-chart for BOC. See "Building Business Operations Center Images" formore information.

Adding Business Operations Center KeysTable 3-12 lists the keys that directly impact BOC. Add these keys to your override-values.yaml file with the same path hierarchy.

For a complete set of keys to personalize BOC deployment, see the keys with the pathocboc.boc in the oc-cn-op-job-helm-chart/values.yaml and oc-cn-helm-chart/values.yaml files.


3-53

Caution:

Keys with the path ocboc.boc.secretVal hold sensitive data. Handle themcarefully with controlled access to the file containing their values. Encode allof these values in base64. See Secrets in Kubernetes Concepts.

Table 3-12 Business Operations Center Keys

Key Path in Values.yamlfile

Chart Description

isEnabled ocboc.boc oc-cn-op-job-helm-chart

oc-cn-helm-chart

Whether to deploy,configure, and startBusiness OperationCenter services.

• false: Kubernetesresources meantfor the BusinessOperation Centerapplication willnot be created.

• true: Creates thenecessaryKubernetesresources forusing BusinessOperation Center.This is thedefault.

nodeSelector ocboc.boc oc-cn-op-job-helm-chart

oc-cn-helm-chart

The rules forscheduling WebLogicServer Pods onparticular nodes usingsimple selectors usingNode Selector rules.

affinity ocboc.boc oc-cn-op-job-helm-chart

oc-cn-helm-chart

The rules forscheduling WebLogicServer Pods onparticular nodes usingmore powerfulselectors using affinityrules.

imageTag ocboc.boc.deployment


oc-cn-helm-chart

The tag associatedwith the image. This isgenerally the patchset number. Prefix thevalue with a colon (:).For example, :12.0.0.3.0


3-54


Table 3-12 (Cont.) Business Operations Center Keys


Chart Description

dbURL ocboc.boc.configEnv oc-cn-op-job-helm-chart

Used to create theWebLogic data sourcefor connecting to theBusiness OperationsCenter schema.

This is also theconnection string forthe database whereschemas needed byOracle FusionMiddleware productsare created,especially OPSS.

Use one of theseformats:"DatabaseHost:DatabasePort/ServiceName" or"DatabaseHost:DatabasePort:ServiceID".

ldapHost ocboc.boc.configEnv oc-cn-op-job-helm-chart

The hostname or IPaddress of the LDAPServer (for example,OUD) where usersand groups areconfigured for accessto BusinessOperations Center.

ldapPort ocboc.boc.configEnv oc-cn-op-job-helm-chart

The port number onwhich the LDAPserver is listening.

ldapGroupBase ocboc.boc.configEnv oc-cn-op-job-helm-chart

The LDAP base DNthat contains groups.

ldapUserBase ocboc.boc.configEnv oc-cn-op-job-helm-chart

The LDAP base DNthat contains users.

bocSchemaUserName

ocboc.boc.configEnv oc-cn-op-job-helm-chart

The BusinessOperations Centerdatabase schemauser name.

bocSchemaBocTablespace


The defaulttablespace for theBusiness OperationsCenter databaseadministrator.

bocSchemaTempTablespace


The temp tablespacefor the BusinessOperations Centerdatabaseadministrator.


3-55



Chart Description

billingCareUrl ocboc.boc.configEnv oc-cn-op-job-helm-chart

The URL of the BillingCare instance that isused with your BRMServer.

Leave this blank ifBilling Care isn'tinstalled in yourenvironment.

logoutUrl ocboc.boc.configEnv oc-cn-op-job-helm-chart

The redirect URLwhere BusinessOperations Centersends users after theylog out and thesession ends.

The default islogin.html.

adminPassword ocboc.boc.secretVal oc-cn-op-job-helm-chart

The Base64-encodedpassword for theWebLogic domain'sadministrative user.This is used foraccessing theWebLogic Console foradministrativeoperations.

ldapPassword ocboc.boc.secretVal oc-cn-op-job-helm-chart

The Base64-encodedpassword of the LDAPServer admin user.

walletPassword ocboc.boc.secretVal oc-cn-op-job-helm-chart

The Base64-encodedpassword for storingwallet-sensitive datafor BRM connections.

sysDBAPassword ocboc.boc.secretVal oc-cn-op-job-helm-chart

The Base64-encodeddatabaseadministrator'spassword.

bocSchemaPassword ocboc.boc.secretVal oc-cn-op-job-helm-chart

The Base64-encodedBusiness OperationsCenter databaseschema password.

rcuSchemaPassword ocboc.boc.secretVal oc-cn-op-job-helm-chart

The Base64-encodedpassword forschemas of OracleFusion Middlewareproducts that will becreated by RCU,which is used byOPSS.


3-56



Chart Description

domainUID ocboc.boc.wop oc-cn-op-job-helm-chart

oc-cn-helm-chart

The name of thedomain.

The default is boc-domain.

adminChannelPort ocboc.boc.wop oc-cn-op-job-helm-chart

oc-cn-helm-chart

The NodePort wherethe admin-server'shttp service will beaccessible.

t3ChannelAddr ocboc.boc.wop oc-cn-op-job-helm-chart

oc-cn-helm-chart

The public address forthe t3 channel of theNetwork AccessPoint. This valueshould be set to theKubernetes serveraddress, which youcan get by runningkubectl cluster-info.

If the value is not setto that address, WLSTwill not be able toconnect from outsideof the Kubernetescluster.

serverStartPolicy ocboc.boc.wop oc-cn-op-job-helm-chart/

oc-cn-helm-chart

The WebLogicservers that theOperator starts whenit discovers thedomain:

• NEVER: Doesnot start anyserver in thedomain.

• ADMIN_ONLY:Starts only theadministrationserver (nomanaged serverswill be started.)

• IF_NEEDED:Starts theadministrationserver andclustered serversup to the replicacount.

domainVolHostPath ocboc.boc.wop oc-cn-op-job-helm-chart

The location on hostsystems in which thedomain will be createdand stored.


3-57



Chart Description

appVolHostPath ocboc.boc.wop oc-cn-op-job-helm-chart

The location on thehost system in whichapplications will beinstalled and storedfor sharing betweenservers in a cluster.

thirdPartyVolHostPath ocboc.boc.wop oc-cn-op-job-helm-chart

The location on thehost system in whichthird-party librariesrequired by the BOCapplication are stored.

imageName ocboc.boc.initContainer

oc-cn-helm-chart The name of BRMApplications image.The default isbrm_apps.

This is the same asthe brm_apps imageprovided in Table 2-1.

imageTag ocboc.boc.initContainer

oc-cn-helm-chart The tag associatedwith the image, whichis generally the patchset number. Prefix thevalue with a colon (:).For example,12.0.0.3.0.

imageName ocboc.boc.kubeCont oc-cn-helm-chart The name of thekubectl image. Thedefault iskubectl_img.

imageTag ocboc.boc.kubeCont oc-cn-helm-chart The tag associatedwith the image,prefixed with a colon(:). For example, :v2.

The default is :v1.

About Business Operations Center Volume MountsThe Business Operations Center container requires Kubernetes volume mounts forsharing the domain and application file system between the WebLogic Cluster servers.These volumes are domainVolHostPath and appVolHostPath.


• The Business Operations Center application home is created on theappVolHostPath/BOC volume mount by oc-cn-op-job-helm-chart, which isreferred to by the servers started by oc-cn-helm-chart.

• The third-party volume mount shares third-party libraries required by the BusinessOperations Center application from the host system to the container file system.


3-58

For the list of third-party libraries to download, see "List of Additional RequiredSoftware for Production Installations" in BRM Compatibility Matrix. Place libraryfiles under the third-party volume mount.


Note:



• The oc-cn-op-job-helm-chart/templates/volume_domain_boc.yaml file for thedomain file system.

• The oc-cn-op-job-helm-chart/templates/volume_app_boc.yaml file for theBusiness Operations Center application file system.

• The op-cn-op-job-helm-chart/templates/volume_thirdparty_boc.yaml file forthird-party libraries required by the Business Operations Center application.

Creating a WebLogic Domain and Installing the Business Operations CenterApplication

The WebLogic domain is created by a Kubernetes Job when oc-cn-op-job-helm-chart is installed. The same job also installs the BOC application and deploys theapplication WAR file onto the WebLogic Cluster.




Note:


After you install oc-cn-op-job-helm-chart, wait until the Kubernetes Job completessuccessfully. Then, you can install or upgrade oc-cn-helm-chart for BusinessOperations Center services. The STATUS of its Pod should be Completed, and itsREADY state should be 0/1.



3-59


If you want to re-install the Business Operations Center domain, ensure that youdelete the chart and empty the domainVolHostPath and appVolHostPath volumesbefore you reinstall the charts.

Starting and Stopping WebLogic ServersWhen you install oc-cn-op-job-helm-chart, the default configuration sets up aWebLogic Cluster with five Managed Servers. When you install or upgrade oc-cn-helm-chart for the BOC service, two of the managed servers and one Admin Serverare started.




Note:

The keys in the override-values.yaml file should be the same as the onesused in oc-cn-op-job-helm-chart for keys that are common in both charts.

Before installing or upgrading oc-cn-helm-chart for BOC, ensure that the brm_appsvalues are configured correctly. If there is a change in any brm_apps values, useserverStartPolicy to restart and have the changes take effect.


Exposing Business Operations Center Services Outside a ClusterWebLogic Operator creates a minimum of one service per WebLogic Server and oneservice for a WebLogic Cluster. To access BOC, you expose the WebLogic Clusterservice outside of the Kubernetes cluster.

To expose BOC outside of the Kubernetes cluster, you must add a load balancer withpath-based routing for the WebLogic Cluster service. The load balancer you selectmust support sticky sessions. That is, if the load balancer redirected a client’s loginrequest to Managed Server 1, all subsequent requests from that client should beredirected to Managed Server 1.


Installing BRM Cloud Native ServicesTo install BRM cloud native services and optionally initialize the BRM databaseschema, do this:

1. Create a name space for the BRM Helm chart:

Chapter 3Installing BRM Cloud Native Services

3-60

kubectl create namespace BrmNameSpace

where BrmNameSpace is the name space in which to create BRM Kubernetesobjects for the BRM Helm chart.

2. If you pushed the images to a private registry, each worker node needs credentialsto the registry to log in to it and pull the images. One way to do this is to useimagePullSecrets, which is a type of Secret.

When added to the service account of a name space or at each Pod,imagePullSecrets specifies that Kubernetes should get the credentials for aprivate registry from a Secret. See "Automatically Pulling Images from PrivateDocker Registries" for more information. To create a Secret in a name space:

kubectl create secret docker-registry SecretName --docker-server=RegistryServer --docker-username=UserName --docker-password=Password --docker-email=Email --namespace BrmNameSpace

where:

• SecretName is the name of the secret.

• RegistryServer is the fully qualified domain name (FQDN) of your privateDocker registry (RepoHost:RepoPort).

• UserName and Password is the user name and password for your privateDocker registry.

• Email is the email on your private Docker registry (optional).

If you can't add imagePullSecrets to the service account of your name space, youcan add it at the Pod level by overriding the imagePullSecrets key with theSecretName value in the override-values.yaml file for each Helm chart.

3. To initialize the BRM database schema, enter this command from the helmchartsdirectory:

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

where:

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

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

• OverrideValuesFile is the path to a YAML file that overrides the defaultconfigurations in the chart's values.yaml file.

4. After the init-db Helm chart is deployed successfully, delete the Helm chart fromyour name space by entering this command from the helmcharts directory:

helm delete InitDbReleaseName -n InitDbNameSpace


3-61

5. Validate the content of your charts by entering these commands from thehelmcharts directory:

helm lint --strict oc-cn-helm-charthelm lint --strict oc-cn-ece-helm-charthelm lint --strict oc-cn-op-job-helm-chart

You'll see this if the command completes successfully:

3 chart(s) linted, no failures

6. For Billing Care, the Billing Care REST API, and BOC, install and set up WebLogicOperator to maintain the application's domains and services:

a. Install the latest supported version of WebLogic Operator.

For the list of supported versions, see "BRM Cloud Native DeploymentSoftware Compatibility" in BRM Compatibility Matrix.

For information about installing WebLogic Operator, see Oracle WebLogicKubernetes Operator Quick Start (https://oracle.github.io/weblogic-kubernetes-operator/quickstart/).

b. Direct WebLogic Operator to monitor the name space used by the Billing Careinstallation.

helm upgrade sample-weblogic-operator kubernetes/charts/weblogic-operator \ --namespace Operator_NS \ --reuse-values \ --set "domainNamespaces={BrmNameSpace}" \ --wait

where Operator_NS is the name space you created for the WebLogicOperator.

7. Create WebLogic domains for Billing Care, the Billing Care REST API, and BOCby entering this command from the helmcharts directory. Use the sameNameSpace you will use for installing the BRM cloud native service.

helm install OpJobReleaseName oc-cn-op-job-helm-chart --namespace BrmNameSpace --values OverrideValuesFile

where OpJobReleaseName is the release name for oc-cn-op-job-helm-chart andis used to track this installation instance. It must be different from the one used forthe BRM Helm chart.

8. Install BRM cloud native services by entering this command from the helmchartsdirectory:

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

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


3-62

https://oracle.github.io/weblogic-kubernetes-operator/quickstart/

https://oracle.github.io/weblogic-kubernetes-operator/quickstart/

9. To install the ECE cloud native service, enter this command from the helmchartsdirectory:

helm install EceReleaseName oc-cn-ece-helm-chart --namespace BrmNameSpace --values OverrideValuesFile

where EceReleaseName is the release name for oc-cn-ece-helm-chart and isused to track this installation instance. It must be different from the one used forthe BRM Helm chart.


3-63

4Upgrading Your BRM Cloud NativeDeployment

This chapter describes how to upgrade your Oracle Communications Billing andRevenue Management (BRM) cloud native deployment.


• Upgrading Your Database Schema

• Upgrading Your BRM Cloud Native Deployment

• Upgrading Your PDC Cloud Native Deployment

About Upgrading Your BRM Cloud Native EnvironmentUpgrading your BRM cloud native environment from 12.0 Patch Set 2 to Patch Set 3involves these high-level steps:

• Upgrade your database schema. See "Upgrading Your Database Schema".

• Upgrade your BRM cloud native deployment. See "Upgrading Your BRM CloudNative Deployment".

• Upgrade your PDC cloud native deployment. See "Upgrading Your PDC CloudNative Deployment".

Upgrading Your Database SchemaTo upgrade your database schema from BRM cloud native 12.0 Patch Set 2 to PatchSet 3:

1. Download the latest version of the Oracle Communications Cloud Native DBInitializer Helm Chart (oc-cn-init-db-helm-chart-12.0.0.x.0.tgz).

2. Extract the Helm chart from oc-cn-init-db-helm-chart-12.0.0.x.0.tgz:

tar xvzf oc-cn-init-db-helm-chart-12.0.0.x.0.tgz

3. Create an override-init-db.yaml file and set the ocbrm.is_upgrade key to true.

4. Set the other keys in Table 3-3 as needed.

Note:

The BRM root password, wallet passwords, and database details shouldbe the same as your Patch Set 2 deployment.

5. Validate the chart's content by entering this command from the helmchartsdirectory:

helm lint --strict oc-cn-init-db-helm-chart

4-1

You'll see this if the command completes successfully:

1 chart(s) linted, no failures

6. Upgrade the BRM Patch Set 2 database schema by entering this command fromthe helmcharts directory. Ensure that you run the Helm chart with a new releasename and namespace cluster.

helm install oc-cn-init-db-helm-chart --name ReleaseName --namespace NameSpace --values OverrideValuesFile

where:

• ReleaseName is the name for your Patch Set 3 release. This name must bedifferent from your Patch Set 2 release name.

• NameSpace is the name space in which to create BRM Kubernetes objects forPatch Set 3. This name space must be different from your Patch Set 2 namespace.

• OverrideValuesFile is the path to a YAML file that overrides the defaultconfigurations in the chart's values.yaml file.

The upgrade container gets launched to upgrade the database schema from PatchSet 2 to Patch Set 3.

To determine if the upgrade was successful, enter the following:

kubectl -n NameSpace get pods

If it was successful, you will see something similar to this:

1/1 RUNNING

Note:

To upgrade the BOC database schema from BRM cloud native 12.0 PatchSet 2 to Patch Set 3, point to your existing BOC schema in the override-values.yaml for oc-cn-op-job-helm-chart. When you install oc-cn-op-job-helm-chart, it will upgrade the BOC database schema to Patch Set 3.

Upgrading Your BRM Cloud Native DeploymentUpgrading your BRM cloud native deployment from 12.0 Patch Set 2 to Patch Set 3involves these high-level steps:

Note:

The steps for upgrading your BRM cloud native deployment are the same forboth existing schemas and new schemas.

1. Create an oc-cn-helm-chart/override-brm.yaml file and set theocbrm.is_upgrade key to true.

Chapter 4About Upgrading Your BRM Cloud Native Environment

4-2

2. Override additional keys to configure the services as per your requirement. See"Installing the BRM Cloud Native Deployment Package".

3. The BRM cloud native deployment package uses Helm v3.0.1. Because Helmv3.0.1 doesn't readily understand the releases created by Helm v2.x, you mustmigrate your BRM cloud native Helm charts to v3.0.1 format by using thehelm2to3 utility. For more information, see Migrating Helm v2 to v3 in the Helmdocumentation (https://helm.sh/docs/topics/v2_v3_migration/). The documentationalso contains references to the migration plugin and to a blog with acomprehensive walk-through of steps using a sample chart.

4. Run the Helm upgrade using the same release name as when you installed the12.0 Patch Set 2 oc-cn-helm-chart Helm chart.

helm upgrade ReleaseName oc-cn-helm-chart --values OverridingValueFile --values NewOverridingValueFile -n Namespace

where:

• ReleaseName is the name assigned to your 12.0 Patch Set 2 oc-cn-helm-chart installation.

• OverridingValueFile is the path to the YAML file that overrides the defaultconfigurations in the oc-cn-helm-chart/values.yaml file.

• NewOverridingValueFile is the path to the YAML file that has updated values.The values in this file are newer than those defined in values.yaml andOverridingValueFile.

• Namespace is the same name space as for the BRM 12.0 Patch Set 2deployment.

Note:

• Keep the ocbrm.is_upgrade key set to true for further release and chartupgrades with the same release name.

• The upgrade process deletes your 12.0.0.2.0 Billing Care and 12.0.0.2.0BOC deployments along with their related Kubernetes objects, such asConfigMaps, Secrets, and persistent volume claims. Ensure that youback up all files to their persistent volumes, because they may getdeleted if the volume is not HostPath and is dynamically provisioned.

Upgrading Your PDC Cloud Native DeploymentUpgrading your PDC cloud native deployment from 12.0 Patch Set 2 to Patch Set 3involves these high-level steps:

Note:

Upgrading the PDC Patch Set 2 cloud native deployment to Patch Set 3 alsoupgrades your PDC database.


4-3

https://helm.sh/docs/topics/v2_v3_migration/

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

• Values.ocpdc.configEnv.useExistingData: Set this to true.

• Values.ocpdc.configEnv.rcuPrefix: Set this with a new value. If you want touse the same value, set the Values.ocpdc.configEnv.rcuRecreate key totrue.

• Values.ocpdc.configEnv.supportECE: Set this to false.

• All other keys in the override-values.yaml file should retain their PDC PatchSet 2 values.

If PDC is enabled with SSL, also edit these keys:

• Values.ocpdc.configEnv.keyStoreType

• Values.ocpdc.configEnv.keyStoreAlias

• Values.ocpdc.configEnv.keyStoreIdentityFileName

• Values.ocpdc.configEnv.keyStoreTrustFileName

• Values.ocpdc.secretValue.keyStoreIdentityKeyPass

• Values.ocpdc.secretValue.keyStoreIdentityStorePass

• Values.ocpdc.secretValue.keyStoreTrustStorePass

2. If PDC is enabled with SSL, copy the certificates to the hostPath of PDC 12.0Patch Set 3. This is the value of the Values.ocpdc.volMnt.pdcHostPath key.

The PDC hostPath must have read and write permissions.

3. Delete the PDC deployment.

4. Delete the PDC PV and PVC because, in Patch Set 3, PDC is split into twocontainers each with different hostPaths.

5. Run the Helm upgrade using the same release name as you did when installingoc-cn-helm-chart for 12.0 Patch Set 2:

helm upgrade ReleaseName oc-cn-helm-chart --values OverridingValuesFile --values NewOverridingValuesFile -n NameSpace

where:

• ReleaseName is the release name you assigned to your 12.0 Patch Set 2Docker images.

• OverridingValuesFile is the path to the YAML file that overrides the defaultconfigurations in the oc-cn-helm-chart/values.yaml file or the oc-cn-ece-helm-chart/values.yaml file.

• NewOverridingValuesFile is the path to the YAML file that has updated values.The values in this file are newer than those defined in values.yaml andOverridingValuesFile.

• NameSpace is the same name space as for the BRM 12.0 Patch Set 2deployment.


4-4

5Customizing BRM Cloud Native Services

This chapter describes how to customize your Oracle Communications Billing andRevenue Management (BRM) server and clients in a cloud native environment.

The Docker build commands in this chapter reference Dockerfile and related scripts asis from the oc-cn-docker-files-12.0.0.x.0.tgz package. Ensure that you use your ownversion of Dockerfile and related scripts before running the build command.


• Customizing BRM Server

• Customizing Billing Care

• Customizing ECE

WARNING:

The Dockerfiles and related scripts are provided for reference only. You canrefer to them to build or extend your own Docker images. Support isrestricted to core product issues only and no support will be provided forcustom Dockerfiles and scripts.

Customizing BRM ServerYou can customize the BRM Server by doing one of these:

• Layering the BRM cloud native Docker image with a customized library file.

• Creating the BRM cloud native Docker image with the default Dockerfile and thenlayering a customized library.

For example, you could extend fm_subsciption_pol_custom.so by doing this:

1. Create the Docker image by going to the $PIN_HOME directory and entering this:

cat Dockerfile_cm

FROM cm:12.0.0.x.0USER rootCOPY lib/fm_subscription_pol_custom.so $PIN_HOME/lib/fm_subscription_pol_custom.soRUN chown -R omsuser:oms $PIN_HOME/lib/fm_subscription_pol_custom.so && \ chmod 755 ${PIN_HOME}/lib/fm_subscription_pol_custom.soUSER omsuser

2. Customize the lib/fm_subscription_pol_custom.so library file.

3. Copy the customized library file to $PIN_HOME/lib.

5-1

4. Build the BRM Server image by entering this command:

docker build -t cm_custom:12.0.0.x.0 -f Dockerfile_cm .

5. Update the custom Docker image name in the override-values.yaml file.

Customizing Billing CareExtensibility is one of the biggest features of on-premise Billing Care, and this sameextensibility is available in the Billing Care cloud native deployment. You can overridethe existing Billing Care behavior, such as change labels and icons, add new flowsand screens, and so on, by using the Billing Care SDK.

To use the Billing Care SDK in a cloud native environment, do this:

1. Build the Billing Care SDK WAR the same way as described in Billing Care SDKGuide.

2. Create a Billing Care SDK image by using the Billing Care image as a base.

3. Update the override-values.yaml file to direct oc-cn-op-job-helm-chart todeploy the SDK WAR file and link it with Billing Care or the Billing Care REST APIWAR after deploying them.

The cloud native package includes all of the scripts necessary to prepare and run anSDK image. For example, if your SDK WAR is namedBillingCareCustomizations.war, you would build the Billing Care SDK image likethis:

1. Go to the oc-cn-docker-files/ocbc/billing_care_sdk directory.

2. Copy the BillingCareCustomizations.war file to your current working directory(oc-cn-docker-files/ocbc/billing_care_sdk).

3. Build the SDK image by entering this command:

docker build --build-arg SDK_WAR=BillingCareCustomizations.war --build-arg BASE_TAG=12.0.0.x.0 -t oracle/billingcare_sdk:12.0.0.x.0 .

4. In your override-values.yaml file for oc-cn-op-job-helm-chart, edit the keysshown in Table 5-1. This directs oc-cn-op-job-helm-chart to deploy the BillingCare SDK image rather than the Billing Care image and to include additional filesthat are needed for successful deployment of SDK.

Table 5-1 Billing Care SDK Keys

Key Path Description

imageName ocbc.bc.deployment

ocbc.bcws.deployment

Set this to oracle/billingcare_sdk.

This is the name of theimage, which must be usedfor the Billing Care Pod.

imageTag ocbc.bc.deployment

ocbc.bcws.deployment

Set this to 12.0.0.x.0.

This tags the image used forthe Billing Care Pod.

Chapter 5Customizing Billing Care

5-2

Table 5-1 (Cont.) Billing Care SDK Keys

Key Path Description

isEnabled ocbc.bc.configEnvSDK

ocbc.bcws.configEnvSDK

Set this key to true if youwant to deploy SDK.

deployName ocbc.bc.configEnvSDK

ocbc.bcws.configEnvSDK

The name of the SDKLibrary in the Manifest.MFfile. The default isBillingCareCustomizations.

5. Install oc-cn-op-job-helm-chart followed by oc-cn-helm-chart to customizeBilling Care or the Billing Care REST API with SDK.

Customizing ECEYou can customize the ECE image by layering the native Docker image with thecustomized code.

For example:

> cat Dockerfile_custom_eceFROM oc-cn-ece:12.0.0.x.0USER root#commands that need to be executedUSER eceuser

To build the image, run this Docker command:

docker build -t customECE:12.0.0.x.0 -f customECEDockerfile .

where customECE is the name of your custom ECE Helm chart, andcustomECEDockerfile is the name of your custom Dockerfile.

For the Helm chart to take the new custom image for installation, set these key in youroverride-values.yaml file for the ECE Helm chart:

imageRepository: "docker-repo:docker-port"container: image: "customECEImageName"

Chapter 5Customizing ECE

5-3

6Maintaining Your BRM Cloud NativeDeployment

This chapter describes how to maintain your Oracle Communications Billing andRevenue Management (BRM) cloud native deployment.


• Managing a Helm Release

• Automatically Rolling Deployments by Using Annotations

• Rotating the BRM Root Password

• About Application Log Files

Managing a Helm ReleaseAfter you install a Helm chart, Kubernetes manages all of its objects and deployments.All Pods created through oc-cn-helm-chart and oc-cn-ece-helm-chart are wrappedin a Kubernetes controller, which creates and manages the Pods and performs healthchecks. For example, if a node fails, a controller can automatically replace a Pod byscheduling an identical replacement on a different node.

Administrators can perform these maintenance tasks on a Helm chart release:

• Tracking a Release's Status

• Updating a Helm Release

• Checking a Release's Revision

• Rolling Back A Release To A Previous Revision

• Rotating the BRM Root Password

Tracking a Release's StatusWhen you install a Helm chart, it creates a release. A release contains Kubernetesobjects, such as ConfigMap, Secret, Deployment, Pod, PersistentVolume, and so on.Not every object is up and running immediately. Some objects have a start delay, butthe Helm install command completes immediately.

To track the status of a release and its Kubernetes objects, enter this command:

helm status ReleaseName -n Namespace

where:

• ReleaseName is the name you assigned to this installation instance.

• NameSpace is the name space in which the BRM Kubernetes objects reside.

6-1

Updating a Helm ReleaseTo update any key value after a release has been created, enter this command. Thiscommand updates or re-creates the impacted Kubernetes objects, without impactingother objects in the release. It also creates a new revision of the release.

Note:

If you are updating an ECE release, you must delete any configLoader jobsbefore you do the Helm update.

helm upgrade ReleaseName Chart --values OverridingValueFile --values NewOverridingValueFile -n Namespace

where:


• Chart is the location of the chart, which is oc-cn-helm-chart for the BRM cloudnative services, oc-cn-ece-helm-chart for ECE cloud native services, or oc-cn-init-db-helm-chart for initializing the BRM database schema.

• OverridingValueFile is the path to the YAML file that overrides the defaultconfigurations in the oc-cn-helm-chart/values.yaml file or the oc-cn-ece-helm-chart/values.yaml file.

• NewOverridingValueFile is the path to the YAML file that has updated values. Thevalues in this file are newer than those defined in values.yaml andOverridingValueFile.

• Namespace is the name space in which the BRM Kubernetes objects reside.

Checking a Release's RevisionHelm keeps track of the revisions you make to a release. To check the revision for aparticular release, enter this command:

helm history ReleaseName -n Namespace

where:


• Namespace is the name space in which the BRM Kubernetes objects reside.

Rolling Back A Release To A Previous RevisionTo roll back a release to any previous revision, enter this command:

helm rollback ReleaseName RevisionNumber -n Namespace

Chapter 6Managing a Helm Release

6-2

where:


• RevisionNumber is the value from the Helm history command.

• Namespace is the name space is which the BRM Kubernetes objects reside.

Automatically Rolling Deployments by Using AnnotationsWhenever a ConfigMap entry or a Secret file is modified, you must restart itsassociated Pod. This updates the container's configuration, but the application isnotified about the configuration updates only if the Pod's deployment specification haschanged. Thus, a container could be using the new configuration, while the applicationkeeps running with its old configuration.

You can configure a Pod to automatically notify an application when a Container'sconfiguration has changed. To do so, configure a Pod to automatically update itsdeployment specification whenever a ConfigMap or Secret file changes by using thesha256sum function. Add an annotations section similar to this one to the Pod'sdeployment specification:

kind: Deploymentspec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

For more information, see Chart Development Tips and Tricks in the Helmdocumentation (https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments).

Rotating the BRM Root PasswordThe BRM root password is the password of service with the login ID root.0.0.0.1,which is used by all clients to connect to the Connection Manager (CM). For securityreasons, you should change this password at regular intervals.

When you change the BRM root password, it impacts all clients that connect to the CMservice: Billing Care, the Billing Care REST API, BOC, and BRM Web Services.Therefore, you must provide the new password to your clients so they can continue toconnect to the CM service.

This shows the procedure for changing the current BRM root password(RootPassword1) to a new root password (RootPassword2) and then providingRootPassword2 to all of your clients:

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

Chapter 6Automatically Rolling Deployments by Using Annotations

6-3

https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments

https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments

Key Value Description

ocbrm.rotate_password true Specify that the password isbeing changed.

ocbrm.new_brm_root_password

RootPassword2 Set a new password for theroot.0.0.0.1 service.

ocbrm.cm.deployment.load_localized

0 Specify to not reload thelocalized strings into thedatabase.

This was already doneduring installation.

ocbc.bc.wop.serverStartPolicy

NEVER Specify to shut down theWebLogic servers for BillingCare.

ocbc.bcws.wop.serverStartPolicy

NEVER Specify to shut down theWebLogic servers for theBilling Care REST API.

ocboc.boc.wop.serverStartPolicy

NEVER Specify to shut down theWebLogic servers for BOC.

2. Specify to shut down the WebLogic servers for BRM Web Services. In the oc-cn-helm-chart/templates/domain_brm_wsm.yaml file, set the serverStartPolicykey to NEVER.

3. Upgrade the release of oc-cn-helm-chart:

helm upgrade --namespace NameSpace ReleaseName oc-cn-helm-chart --values OverrideValuesFile

where:

• ReleaseName is name of the release you used when installing oc-cn-helm-chart.

• NameSpace is the name space in which oc-cn-helm-chart is installed.

Upgrading the release does the following:

• Changes the password for service root.0.0.0.1.

• Spins off new PODs for the CM and a few other services

• Stops services for Billing Care, the Billing Care REST API, BOC, and BRMWeb Services.

4. Specify to turn off the password rotation indicator and to update the password. Inthe same override-values.yaml file, set these keys to the following values:

Key Value Description

ocbrm.rotate_password false Turn off password rotation.This specifies that thepassword is not beingchanged.

ocbrm.brm_root_password

RootPassword2 Provide the updatedpassword for the root.0.0.0.1 service.

Chapter 6Rotating the BRM Root Password

6-4

5. Update the password in the Infranet.properties file and wallet for Billing Care,the Billing Care REST API, and BOC by either reinstalling oc-cn-op-job-helm-chart or updating the wallet in-place in the persistent volume (PV).

To reinstall oc-cn-op-job-helm-chart, do this:

a. Delete the release of oc-cn-op-job-helm-chart:

helm delete --namespace NameSpace OpJobReleaseName

where OpJobReleaseName is the name of the oc-cn-op-job-helm-chartrelease.

b. Clean up the domain home from PV for Billing Care, Billing Care REST, andBOC:

rm -rf DomainHome/domains/DomainUID

where:

• DomainHome is the location specified in the domainVolHostPath keyunder groups ocbc.bc.wop, ocbc.bcws.wop, and ocboc.boc.wop.

• DomainUID is the domain name specified in the domainUID key undergroups ocbc.bc.wop, ocbc.bcws.wop, and ocboc.boc.wop. Typically,the defaults are billingcare-domain, bcws-domain, and boc-domainrespectively.

c. Clean up the application home from PV for Billing Care and the Billing CareREST API:

rm -rf ApplicationHome/billingcare

where ApplicationHome is the location specified in the appVolHostPath keyunder groups ocbc.bc.wop and ocbc.bcws.wop.

d. Clean up the application home from PV for BOC:

rm -rf ApplicationHome/BOC

where ApplicationHome is the location specified in the appVolHostPath keyunder group ocboc.boc.wop.

e. Install oc-cn-op-job-helm-chart again:

helm install OpJobReleaseName oc-cn-op-job-helm-chart --namespace NameSpace --values OverrideValuesFile

Wait for the jobs to complete their tasks.

f. Delete the policy job for Billing Care, the Billing Care REST API, and BOC:

kubectl --namespace NameSpace delete job DomainUID-policy-job

where DomainUID is the domain name specified in the domainUID key undergroups ocbc.bc.wop, ocbc.bcws.wop, and ocboc.boc.wop in the override-values.yaml file. Typically, the defaults are billingcare-domain, bcws-domain, and boc-domain respectively.

To update the wallet in-place in the PV, do this:

a. For Billing Care and the Billing Care REST API, update the password in thewallet by following the instructions in "Storing Configuration Entries in the

Chapter 6Rotating the BRM Root Password

6-5

Billing Care Wallet" in BRM Security Guide. The wallet for these clients islocated at ApplicationHome/billingcare/wallet/client.

b. For BOC, update the password in the wallet by following the instructions in"Storing Configuration Entries in the Business Operations Center Wallet" inBRM Security Guide. The wallet for BOC is located at ApplicationHome/BOC/wallet/client.

where ApplicationHome is the location specified in the appVolHostPath key undergroups ocbc.bc.wop, ocbc.bcws.wop, and ocboc.boc.wop.

6. Delete the PDC and PCC deployments:

kubectl --namespace NameSpace delete deploy pdc-deployment pcc-deployment

7. Specify to start the WebLogic servers for BRM Web Services. In the oc-cn-helm-chart/templates/domain_brm_wsm.yaml file, set the serverStartPolicy key toIF_NEEDED.

8. Upgrade the release of oc-cn-helm-chart to bring up all client services with theupdated CM connection details:

helm upgrade --namespace NameSpace ReleaseName oc-cn-helm-chart --values OverrideValuesFile

9. Update the BRM root password in your ECE pods by doing this:

a. Connect via JMX to any of the charging server (ecs) pods.

b. Navigate to the BRM Connection MBean.

c. Navigate to the Operations section.

d. Enter the new BRM root password (RootPassword2) along with the existingwallet password in the setPassword method and then execute.

e. Perform a test connection to validate that the connection is successful.

f. Rebounce the BRM Gateway PODs for the new password to take effect andfor the connection pool to BRM to be re-created.

About Application Log FilesBRM cloud native services forwards log files to Elasticsearch by using Fluentd. Youcan then view the log files from the Kibana dashboard.

Billing Care, the Billing Care REST API, and BOC run Fluentd as a side car to collectlogs from individual WebLogic Servers while Fluentd is running. DaemonSet forwardslog files from other services in BRM.

Setting up application logging in your BRM cloud native deployment involves thesehigh-level steps:

1. Configuring and launching a scalable Elasticsearch cluster.

2. Creating the Kibana Kubernetes service and deployment.

3. Deploying and configuring the Fluentd patterns as a ConfigMap.

kubectl -n NameSpace apply -f oc-cn-helm-chart/fluentd-patterns-configmap.yaml

4. Deploying Fluentd as a DaemonSet on the Kubernetes cluster, typically in thekube-system namespace.

Chapter 6About Application Log Files

6-6

5. In your override-values.yaml file for oc-cn-helm-chart, setting theefkStack.isEnabled key to true. This specifies to start the Fluentd side-car in therelevant Pods.

After you set up application logging, your batch and roaming pipeline logs are presentunder the pipelinelog PVC. Your application log files are stored in the Kubernetescluster in the /var/log/containers directory. The log files use this file naming format:PodName_NameSpace.log.

where:

• PodName is the name of a Pod such as cm, ece, or dm-oracle.


For example, if NameSpace is ocgbu, your Oracle Data Manager log files would benamed ocgbu_dm-oracle.

The Fluentd concat plugin is used to concatenate multiline log files. To allow Fluentdto parse your log files, all applications should redirect their logs to STDOUT. Thisallows the Fluentd in_tail plugin to read events from the tail end of the log files.

To retrieve the complete logs, use this command:

kubectl -n NameSpace logs -f PodName -c ContainerName

Chapter 6About Application Log Files

6-7

7Uninstalling Your BRM Cloud NativeDeployment

This chapter describes how to uninstall your Oracle Communications Billing andRevenue Management (BRM) cloud native deployment.


• Uninstalling Selected BRM Cloud Native Services

• Uninstalling Your BRM Cloud Native Deployment

Uninstalling Selected BRM Cloud Native ServicesDepending on the scenario, you might need to temporarily or permanently uninstallBRM cloud native services, such as Billing Care, the Billing Care REST API, or BOC,while retaining other BRM services. To do this, you upgrade your oc-cn-helm-chartrelease by disabling the service you intend to remove.

For example, to remove only the Billing Care REST API service, you would set theocbc.bcws.isEnabled key to false in your override-values.yaml file and thenupgrade your release of oc-cn-helm-chart:

helm upgrade -n NameSpace ReleaseName oc-cn-helm-chart --values override-values.yaml

This would bring down the WebLogic servers that are hosting the Billing Care RESTAPI and remove all resources created for this service through oc-cn-helm-chart.

Uninstalling Your BRM Cloud Native DeploymentWhen you uninstall a Helm chart from your BRM cloud native deployment, it removesonly the Kubernetes objects that it created during installation.

To uninstall, enter this command:

helm delete ReleaseName -n Namespace

where:



7-1

8Building Your Own Images

This chapter provides guidance on how you can build your own Docker images fromthe Dockerfiles and related scripts that you create. This covers OracleCommunications Billing and Revenue Management (BRM), Elastic Charging Engine(ECE), Pipeline Configuration Center, Pricing Design Center (PDC), Billing Care, andBusiness Operations Center applications.

The Docker build commands in this chapter reference Dockerfile and related scripts asis from the oc-cn-docker-files-12.0.0.x.0.tgz package. Ensure that you use your ownversion of Dockerfile and related scripts before running the build command.


• Building BRM Server Images

• Building PDC Images

• Building Pipeline Configuration Center Images

• Building Billing Care Images

• Building Business Operations Center Images

Sample Dockerfiles included in the BRM cloud native deployment package (oc-cn-docker-files-12.0.0.x.0.tgz) are examples that depict how default images are built forBRM. If you want to build your own images, refer to the sample Dockerfiles shippedwith the product as a reference. Create your own Dockerfiles and then build yourimages.

WARNING:

The Dockerfiles and related scripts are provided for reference only. You canrefer to them to build or extend your own Docker images. Support isrestricted to core product issues only and no support will be provided forcustom Dockerfiles and scripts.

Building BRM Server ImagesTo build images for BRM Server, your staging area ($PIN_HOME) must be availablefrom where the Docker images are built. After you unpack oc-cn-docker-files-12.0.0.x.0.tgz, the BRM Server directory structure will be oc-cn-docker-files/ocbrm.

Building your own BRM Server images involves these high-level steps:

1. You build the BRM Server base image. See "Building Your BRM Server BaseImage".

2. You build images for each BRM Server component. See "Building Images of BRMServer Components".

8-1

3. You build the Web Services Manager image. See "Building Web ServicesManager Images".

4. You containerize the Email Data Manager. See "Containerization of Email DataManager".

5. You containerize the roaming pipeline. See "Containerization of RoamingPipeline".

6. You build and deploy Vertex Manager. See "Building and Deploying VertexManager".

Building Your BRM Server Base ImageTo make your directory structure ready for building base images:

1. Edit the $PIN_HOME/bin/orapki binary to replace the staging Java path with ${JAVA_HOME}.

2. Create the $PIN_HOME/installer directory.

3. If you're behind a proxy server, set the $PROXY variable:

export PROXY=ProxyHost:Port

4. Download the Java binary and then copy it to $PIN_HOME. See "BRM SoftwareCompatibility" for the latest supported version of Java.

5. Download the Perl binary and then copy it to $PIN_HOME. See "BRM SoftwareCompatibility" for the latest supported version of Perl.

6. For your database client:

a. Copy client_install.rsp (32 bit), oracle_client_response_file.rsp (64 bit),downloadOracleClient.sh, and waitForOracleClientInst.sh from oc-cn-docker-files/ocbrm/base_images to $PIN_HOME.

b. Modify these parameters in the downloadOracleClient.sh file:

• ORACLE_CLIENT_ZIP: Enter the binary name.

• REPOSITORY_URL: Enter the location to fetch the database client binary.

c. If the db_client binary is already downloaded, copy the binary tothe $PIN_HOME/installer directory.

After preparing your directory structure, build your BRM Server base image:

• For database client 12CR2 (64 Bit) + Java + Perl, enter this command:

docker build --build-arg PROXY=$PROXY -t db_client_and_java_perl:12.0.0.x.0 -f DockerFileLocation/Dockerfile_db_client_and_java_perl .

• For database client 12CR2 (64 Bit) + Java, enter this command:

docker build --build-arg PROXY=$PROXY -t db_client_and_java:12.0.0.x.0 -f DockerFileLocation/Dockerfile_db_client_and_java .

Chapter 8Building BRM Server Images

8-2

• For Java, enter this command:

docker build --build-arg PROXY=$PROXY -t java:12.0.0.x.0 -f DockerFileLocation/Dockerfile_java .

• For Java + Perl, enter this command:

docker build --build-arg PROXY=$PROXY -t java_perl:12.0.0.x.0 -f DockerFileLocation/Dockerfile_java_perl .

• For database client 12CR2 (32 Bit) + Java, enter this command:

docker build --build-arg PROXY=$PROXY -t db_client_32_and_java:12.0.0.x.0 -f DockerFileLocation/Dockerfile_db_client_32_and_java .

Note:

If the existing database is used with custom build Docker images, do this:

• Override the ocbrm.use_oracle_brm_images key in the Helm chartwith a value of false.

• Set the ocbrm.existing_database key to true.

• Copy your client wallet files to the oc-cn-helm-chart/existing_walletdirectory.

Building Images of BRM Server ComponentsThe oc-cn-docker-files-12.0.0.x.0.tgz package includes references to all of theDockerfiles and scripts needed to build images of BRM Server components (except fororaclelinux:7-slim).

To build an image of a BRM Server component:

1. Copy these scripts from the oc-cn-docker-files/ocbrm directory to your stagingarea at $PIN_HOME:

• entrypoint.sh

• createWallet.sh

• cm/preStopHook.sh_cm

• cm/postStartHook.sh

• cm/updatePassword.sh

• eai_js/preStopHook.sh_eai

2. Do one of these:

• For the batch pipeline, roaming pipeline, and real-time pipeline, copyentrypoint.sh and createWallet.sh to $PIN_HOME/.., andcopy $PIN_HOME/../setup/BRMActions.jar to the $PIN_HOME/jars directoryfor building the images.


8-3

• For all other components, copy the $PIN_HOME/../setup/BRMActions.jar fileto $PIN_HOME.

3. Set these environment variables:

• $PIN_HOME: Set this to your staging area.

• $PERL_HOME: Set this to the path of Perl. See "BRM Software Compatibility"for the latest supported version of Perl.

• $JAVA_HOME: Set this to the path of Java. See "BRM SoftwareCompatibility" for the latest supported version of Java.

4. Build the image for your BRM component.

For example, to build a CM image, you'd enter this:

docker build -t cm:12.0.0.x.0 --build-arg STAGE_PIN_HOME=$PIN_HOME --build-arg STAGE_JAVA_HOME=$JAVA_HOME --build-arg STAGE_PERL_HOME=$PERL_HOME -f DockerfileLocation/Dockerfile .

To build a roaming pipeline image, you'd enter this:

docker build -t roam_pipeline:$BRM_VERSION --build-arg STAGE_PERL_HOME=StagePerlPath .

where StagePerlPath is the path to the Perl files in your staging areaat $PIN_HOME.

To build a dm-oracle image, you'd enter this:

docker build --force-rm=true --no-cache=true -t dm_oracle:12.0.0.x.0 -f DockerfileLocation/Dockerfile .

where DockerfileLocation is the path to the Dockerfiles for your BRM component.

Note:

Build batch and realtime pipeline images from $PIN_HOME/...

Building Web Services Manager ImagesTo containerize images for Web Services Manager, your staging area ($PIN_HOME)must be available from where the Docker images are built.

You can create one of these Web Services Manager containers:

• Building and Deploying Web Services Manager for Apache Tomcat Image

• Building and Deploying Web Services Manager for WebLogic Server Image

Building and Deploying Web Services Manager for Apache Tomcat ImageThe Web Services Manager Dockerfile is based on the official Apache Tomcat image(9.0.31 based on Open JDK 8). The sample Web Services Manager Dockerfileincludes both the XML element-based and XML string-based SOAP Web Services


8-4

implementation. Use this Dockerfile to build a Docker image that can call any standardBRM opcode that is exposed as a SOAP Web service.

The Web Services Manager Infranet.properties configuration is available as aKubernetes ConfigMap. To expose a custom opcode as a Web service, place yourcustomized WAR filepath in the Dockerfile. When multiple Pod replicas are configured,each Pod runs its own copy of Apache Tomcat. By default, Web Services Manager isexposed as a Kubernetes NodePort service running on port 30080.

Containerizing the Web Services Manager for Tomcat image involves these high-levelsteps:

1. Building the Web Services Manager Tomcat Image

2. Deploying the Web Services Manager Tomcat Image in Kubernetes

Building the Web Services Manager Tomcat Image

To build the Web Services Manager for Apache Tomcat image:

1. Download the JAX-WS reference implementation JARs from JAX-WS Java API forXML Web Services (https://javaee.github.io/metro-jax-ws/).

2. Copy the jaxws-ri-2.3.x.zip file to your staging area at $PIN_HOME.

3. Unzip the jaxws-ri-2.3.x.zip file.

4. Copy these files from the oc-cn-docker-files directory to your staging areaat $PIN_HOME.

• wsm_entrypoint.sh

• Dockerfile

• context.xml

• BRMActions.jar

5. Build the Web Services Manager image by entering this command:

docker build -t brm_wsm:12.0.0.x.0 --build-arg STAGE_JAVA_HOME=$JAVA_HOME .

Deploying the Web Services Manager Tomcat Image in Kubernetes

To deploy the Web Services Manager for Tomcat image in Kubernetes:

1. Configure your Web services by updating theconfigmap_infranet_properties_wsm.yaml file.

2. In the override-values.yaml file for oc-cn-helm-chart, setthe .Values.ocbrm.wsm.deployment.tomcat.enabled key to true.

3. Deploy the BRM Helm chart:

helm install ReleaseName oc-cn-helm-chart --namespace NameSpace --values OverrideValuesFile

where:

• ReleaseName is the release name, which is used to track this installationinstance.


8-5

https://javaee.github.io/metro-jax-ws/

• NameSpace is the name space in which to create BRM Kubernetes objects.

• OverrideValuesFile is the path to a YAML file that overrides the defaultconfigurations in the BRM chart's values.yaml file.

Building and Deploying Web Services Manager for WebLogic Server ImageTo deploy and use Web Services Manager on WebLogic Server, you should befamiliar with:

• Oracle WebLogic Server 12.2.1.3. See the Oracle WebLogic Server 12.2.1.3documentation (https://docs.oracle.com/middleware/12213/wls/index.html).

• Oracle WebLogic Kubernetes Operator. See Oracle WebLogic KubernetesOperator User Guide (https://oracle.github.io/weblogic-kubernetes-operator/userguide/).

The Docker image for deploying BRM Web Services Manager on Oracle WeblogicServer 12.2.1.3 uses the domain in image approach. The Docker image includes aWebLogic domain named brmdomain. When you build the Docker image, the BRMSOAP Web Services application WAR files get deployed in this domain.

Containerizing the Web Services Manager for WebLogic Server image involves thesehigh-level steps:

1. Building the Web Services Manager WebLogic Image

2. Deploying the Web Services Manager WebLogic Image in Kubernetes

3. Updating the BRM Web Services Manager Configuration

4. Restarting the WebLogic Server Pods

5. Scaling Your WebLogic Managed Server

Building the Web Services Manager WebLogic Image

The BRM Web Services Manager on WebLogic Server image uses two images thatrun two containers inside each WebLogic Server Pod.

To build the brm_wsm_wls12.0.0.x.0 image:

1. Copy the contents of the oc-cn-docker-files/ocbrm/brm_soap_wsm/weblogic/dockerfiles directory to your staging area at $PIN_HOME.

2. Customize the WebLogic domain-related properties by editing the dockerfiles/properties/docker-build/domain.properties file. For example:

DOMAIN_NAME=brmdomainADMIN_PORT=7111ADMIN_NAME=admin-serverADMIN_HOST=wlsadminMANAGED_SERVER_PORT=8111MANAGED_SERVER_NAME_BASE=managed-serverCONFIGURED_MANAGED_SERVER_COUNT=3CLUSTER_NAME=cluster-1DEBUG_PORT=8453DB_PORT=1527DEBUG_FLAG=truePRODUCTION_MODE_ENABLED=trueCLUSTER_TYPE=DYNAMIC


8-6

https://docs.oracle.com/middleware/12213/wls/index.html



JAVA_OPTIONS=-Dweblogic.StdoutDebugEnabled=falseT3_CHANNEL_PORT=30012T3_PUBLIC_ADDRESS=kubernetesIMAGE_TAG=brm_wsm_wls:$BRM_VERSION

3. Set the WebLogic domain user name and password by editing the dockerfiles/properties/docker-build/domain_security.properties file. For example:

username=UserNamepassword=Password

Note:

It is strongly recommended that you set a new user name and passwordwhen building the image.

For details about securing the domain_security.properties file, see https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-home-in-image.

4. Build the brm_wsm_wls:12.0.0.x.0 image by running the build.sh script.

The script creates a Docker image based on the custom tag defined indockerfiles/properties/docker-build/domain.properties. By default, it createsthe brm_wsm_wls:12.0.0.x.0 image and then deploys the BRMWebServices.warand infarnetwebsvc.war files.

Note:

If you don't want to deploy either BRMWebServices.war orinfarnetwebsvc.war, modify the dockerfiles/container-scripts/app-deploy.py script.

5. Build the brm_wsm_wl_init:12.0.0.x.0 image by running this command:

docker build -t brm_wsm_wl_init:12.0.0.x.0 -f Dockerfile_init_wsm .

This image runs an init container, which populates the Oracle wallet that is usedby Web Services Manager to connect to the CM.

Deploying the Web Services Manager WebLogic Image in Kubernetes

You deploy the WebLogic Operator Helm chart so that Web Services Manager canwork in a Kubernetes environment.To deploy the Web Services Manager for WebLogic Server image in Kubernetes:

1. Clone the Oracle WebLogic Kubernetes Operator Git project:

git clone https://github.com/oracle/weblogic-kubernetes-operator

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


8-7

https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-home-in-image



Note:

Ensure that you set the wsm.deployment.weblogic.enabled key totrue.

wsm: deployment: weblogic: enabled:true imageName:brm_wsm_wls initImageName:brm_wsm_wl_init imageTag:$BRM_VERSION username:d2VibG9naWM= password:d2VibG9naWMxMjM= replicaCount:1 adminServerNodePort:30611 log_enabled:false minPoolSize:1 maxPoolSize:8 poolTimeout:30000

3. If the WebLogic user name and password was updated when building thebrm_wsm_wls:12.0.0.x.0 image, also update the base64-encoded WebLogicuser name and password in these keys:

.Values.ocbrm.wsm.deployment.weblogic.username

.Values.ocbrm.wsm.deployment.weblogic.password

4. Add the BRM WebLogic Server name space in the kubernetes/charts/weblogic-operator/values.yaml file:

domainNamespaces: - "default" - "NameSpace"

5. Deploy the WebLogic Operator Helm chart:

helm install weblogic-operator kubernetes/charts/weblogic-operator --namespace WebOperatorNameSpace --values WebOperatorOverrideValuesFile --wait

where:

• WebOperatorNameSpace is the name space in which to create WebLogicOperator Kubernetes objects.

• WebOperatorOverrideValuesFile is the path to a YAML file that overrides thedefault configurations in the WebLogic Operator Helm chart's values.yaml file.

6. Deploy the BRM helm chart:


where:

• ReleaseName is the release name, which is used to track this installationinstance.


8-8

• NameSpace is the name space in which oc-cn-helm-chart will be installed.

• OverrideValuesFile is the path to a YAML file that overrides the defaultconfigurations in the BRM Helm chart's values.yaml file.

Updating the BRM Web Services Manager Configuration

Update the basic configurations for BRM Web Services Manager by editing theKuberentes ConfigMap (configmap_infranet_properties_wsm_wl.yaml). Afterupdating the configuration, restart your WebLogic Server Pods.

Restarting the WebLogic Server Pods

To restart your WebLogic Server Pods:

1. Stop the WebLogic Server Pods by doing this:

a. In the domain_brm_wsm.yaml file, set the serverStartPolicy key to NEVER.

b. Update your Helm release.

helm upgrade ReleaseName oc-cn-helm-chart --namespace NameSpace --values OverrideValuesFile

where NameSpace is the name space in which oc-cn-helm-chart will beinstalled.

2. Start the WebLogic Server Pods by doing this:

a. In the domain_brm_wsm.yaml file, set the serverStartPolicy key toIF_NEEDED.

b. Update your Helm release:


Scaling Your WebLogic Managed Server

The default configuration starts one WebLogic Managed Server Pod. To modify theconfiguration to start up to three Pods, do this:

1. In the oc-cn-helm-chart/values.yaml file, setthe .Values.ocbrm.wsm.deployment.weblogic.replicaCount key to 1, 2, or 3WebLogic Managed Server Pods.

2. Update your Helm release:


You set the maximum number of managed servers in the BRM Web Services ManagerDocker image by modifying the CONFIGURED_MANAGED_SERVER_COUNTproperty in the dockerfiles/properties/docker-build/domain.properties file.

Containerization of Email Data ManagerThe Email Data Manager (DM) enables you to send customer notifications andinvoices to your customers through email automatically. The Email DM uses theSendmail client to forward emails to Postfix, which is the SMTP server. In-turn, Postfixsends the emails to your customers.


8-9

The Email DM will have the Sendmail client, and the Kubernetes host will have Postfixrunning. You must install and configure Postfix on your Kubernetes host.

To configure your CM Pod to point to the Email DM, add this key to the oc-cn-helm-chart/values.yaml file:

ocbrm.dm_email.deployment.smtp: EmailHostName

where EmailHostName is the hostname of the server on which the Email DM isdeployed. For example: em389.us.company.com.

To configure the Kubernetes host or SMTP server to accept data from the Email DM,do this:

1. Log in as the root user to the Kubernetes host.

2. Add the IP address for the Kubernetes host to the /etc/postfix/main.cf file:

inet_interfaces=localhost, HostIPAddress

For example, if the Kubernetes host is 10.242.155.149.

inet_interfaces=localhost, 10.242.155.149

3. Retrieve the container network configuration by running this command on theKubernetes host:

/sbin/ifconfig cni0 | grep netmask | awk '{print$2"\n"$4}'

The output will be similar to this:

10.244.0.1 ← The Kubernetes host IP, which is in the container network.255.255.255.0

4. Edit the mynetworks field in the /etc/postfix/main.cf file to include theKubernetes network in the list of trusted SMTP clients. If the Kubernetes host IPand Email DM container IP are in different networks, add both networks to themynetworks field:

mynetworks = TrustedNetworks

where TrustedNetworks is the IP addresses for the SMTP clients that are allowedto relay mail through Postfix.

For example:

mynetworks = 168.100.189.0/28, 127.0.0.0/8, 10.244.0.0/24

5. Do one of these:

• If Postfix is already running in the host, run this command:

systemctl restart postfix.service

• If Postfix isn't running in the host, run this command:

systemctl start postfix.service


8-10

Note:

In case of a multi-node environment, you can configure Postfix on the masternode (or any one node).

Containerization of Roaming PipelineRoaming allows a wireless network operator to provide services to mobile customersfrom another wireless network. For example, when a mobile customer makes a phonecall from outside the home network, roaming allows the customer to access the samewireless services that he has with his home network provider through a visited wirelessnetwork operator. See BRM Implementing Roaming for more information.

You feed the input files for the roaming pipeline through the Kubernetes PersistentVolume Claim (PVC). The EDR output files will be available in a PVC for consumptionof the REL Pod. When building the roaming pipeline image, pass the Perl path in thesefiles as part of build-arg.

To containerize the roaming pipeline, update theconfigmap_infranet_properties_rel_daemon.yaml file to specify how to load yourrated CDR output files. For example:

batch.random.events TEL, ROAMROAM.max.at.highload.time 4ROAM.max.at.lowload.time 2ROAM.file.location /oms/ifw/data/roamoutROAM.file.pattern test*.outROAM.file.type STANDARD

Note:

The input file to the splitter pipeline must start with Roam_.

Building and Deploying Vertex ManagerTo deploy Vertex Manager (dm-vertex), you layer the dm-vertex image with thelibraries for Vertex Communications Tax Q Series (CTQ) or Vertex Sales Tax Q Series(STQ). For the list of supported library versions, see "Additional BRM SoftwareRequirements" in BRM Compatibility Matrix.

The general steps for deploying Vertex Manager with CTQ include:

1. Copying the libctq.so file from your CTQ installation directory to the dm-verteximage's $PIN_HOME/lib directory, where $PIN_HOME is set to the path of yourstaging area.

By default, $PIN_HOME is set to /oms.

2. Copying the library files from your CTQ installation directory to $PIN_HOME/lib inthe new layered image.


8-11

https://docs.oracle.com/cd/E51000_01/doc.120/e51027/toc.htm

3. Changing all of the paths in your dm-vertex configuration files, such as cfgctq.xmland odbc.ini, to $PIN_HOME/vertex. For example, if Vertex Manager is installedin the /home/user/vertex directory, you would change all references to thatdirectory to $PIN_HOME/vertex.

4. Creating the image stack by using dm_vertex:12.0.0.x.0 as the base image andthen layering the CTQ library.

5. In your override-values.yaml file for oc-cn-helm-chart, updating these first twokeys to the name for the dm-vertex image stack, such as brm_dm_vertex, and thethird key to true.

ocbrm.dm_vertex.deployment.imageNameocbrm.dm_vertex.deployment.imageTagocbrm.dm_vertex.enabled: true

6. Updating the BRM Helm release. See "Updating a Helm Release".

Deploying Vertex Manager with STQ

To deploy Vertex Manager with STQ, layer your dm_vertex images as described forCTQ except include these steps:

1. Copy these library files from the STQ installation directory to $PIN_HOME/lib inthe layered image:

• libctx300.so

• libloc.so

• libvst.so

2. Update these entries in the configmap_env_dm_vertex.yaml file:

• quantumdb_server: Set this to the network identifier for the database on theserver.

• quantumdb_user: Set this to a valid Oracle login name.

• quantumdb_passwd: Set this to the user password.

Building Custom dm-vertex Docker Images

To build custom dm-vertex Docker images:

1. Layer the default images provided by Oracle. For example, to layer dm-vertex withCTQ, you could add these sample commands to its Dockerfile:

FROM dm_vertex:12.0.0.x.0

USER rootRUN mkdir -p $PIN_HOME/vertex/cfgCOPY ./vertex/ $PIN_HOME/vertexCOPY vertex/32bit/lib/libctq.so $PIN_HOME/lib

RUN chown -R omsuser:oms $PIN_HOME/vertex $PIN_HOME/libctq.soUSER omsuser

In this example, the CTQ installation directory is copied to $PIN_HOME/vertex,and the libctq.so file is copied to $PIN_HOME/lib.


8-12

Note:

If the CTQ directory is copied to a location other than $PIN_HOME/vertex, modify these environment variables in the dm_vertex.yaml file:

- name: LD_LIBRARY_PATH value: "/oms/vertex/32bit/bin/odbc:/oms/lib:/oms/sys/dm_vertex:/oms/vertex/32bit/lib" - name: CTQ_CFG_HOME value: "/oms/vertex/32bit/bin" - name: ODBCINI value: "/oms/vertex/32bit/bin/odbc/odbc.ini"

2. In your override-values.yaml file, set this parameter to the shared library versionto be used by dm-vertex to connect to the Vertex CTQ database. The supportedvalues are dm_vertex_ctq30102.so and dm_vertex_ctq300.so.

.Values.ocbrm.dm_vertex.deployment.ctqSmObj

3. In your override-values.yaml file, set these keys:

• commtax_config_path: Set it to the directory path where the ctqcfg.xml fileis located.

• commtax_config_name: Set it to the name of the file that configures the CTQdatabase, such as ctqcfg.xml.

Using CTQ Utilities

The CTQ utilities that are used to maintain the Vertex database can be run fromoutside the cluster, connecting directly to the Vertex database.

If you need to run the CTQ utilities, such as ctqupdate, from the Pod itself, copy theentire contents of the untarred CTQ.tar to the Vertex Pod. Also, set the tnsnames.oraentry for the CTQ database in the configmap_tns_admin.yaml file.

Building PDC ImagesBuilding your own PDC images involves these high-level steps:

1. You build the base image for PDC. See "Building the Base PDC Image".

2. You build the Oracle PDC APP image. See "Building the PDC APP Image".

3. You build the Oracle PDC BRM integration image. See "Building the PDC BRMIntegration Image".

4. You build the PDC Kubectl image. See "Building the PDC Kubectl Image".

Building the Base PDC ImageAll images from the BRM cloud native deployment package use Oracle Linux as thebase image. Oracle Linux is available from both Docker Hub (https://hub.docker.com/)

Chapter 8Building PDC Images

8-13

https://hub.docker.com/

and Oracle Container Registry (http://container-registry.oracle.com). You can pull theimage from either of these repositories.

To build the base PDC image, do this:

1. Ensure that the Oracle Linux image is present in your local system, where you willbuild other images, with the name oraclelinux:7-slim.

2. Download these packages to the ParentFolder/Docker_files/BasePDCImage/container-scripts directory:

• server-jre-8u241-linux-x64.tar.gz

• ojdbc8.jar

• orai18n.jar

3. Build the base PDC image by going to ParentFolder/Docker_files/PDCBaseImage and entering this command:

docker build --force-rm=true --no-cache=true -t oracle/pdcbase:12.0.0.x.0 -f Dockerfile .

Building the PDC APP ImageTo build the PDC APP image, do this:

1. Download pdcserver-12.0.0.x.0_generic_full.jar to the ParentFolder/Docker_files/PDCAPPImage/container-scripts directory.

2. Download these packages to the ParentFolder/Docker_files/PDCAPPImage/container-scripts directory:

• fmw_12.2.1.3.0_infrastructure_Disk1_1of1.zip

• p26045997_122130_Generic.zip

• p28186730_139400_Generic.zip

• p29016089_122130_Generic.zip

• p29921455_12213190416_Generic.zip

3. Build the PDC APP image by entering this command from the ParentFolder/Docker_files/PDCAPPImage directory:

docker build --force-rm=true --no-cache=true -t oracle/pdcapp:12.0.0.x.0 -f Dockerfile .

Building the PDC BRM Integration ImageTo build the PDC BRM integration image:

1. Download the brm-apps and realtimepipe Docker images from the repository byentering this command:

docker pull RepoHost:RepoPort/ImageName

where:

Chapter 8Building PDC Images

8-14

http://container-registry.oracle.com

• RepoHost is the IP address or hostname of the repository.

• RepoPort is the port number for the repository.

• ImageName is either brm_apps:12.0.0.x.0 or realtimepipe:12.0.0.x.0.

2. Tag the Docker images by entering these commands:

docker tag RepoHost:RepoPort/brm_apps:12.0.0.x.0 brm_apps:12.0.0.x.0 docker tag RepoHost:RepoPort/realtimepipe:12.0.0.x.0 realtimepipe:12.0.0.x.0

3. Download pdcserver-12.0.0.x.0_generic_full.jar to the ParentFolder/Docker_files/PDCBRMIntegImage/container-scripts directory.

4. Download perl-5.x1.tar.gz to the ParentFolder/Docker_files/PDCBRMIntegImage/container-scripts directory.

5. Build your Oracle PDC BRM integration image by entering this command from theParentFolder/Docker_files/PDCBRMIntegImage directory:

docker build --force-rm=true --no-cache=true -t oracle/pdcbrminteg:12.0.0.x.0 -f Dockerfile .

Building the PDC Kubectl ImageTo build the PDC Kubectl image, do this:

1. Set these environment variables:

• $KUBECTL: Set this to the path of the Kubectl binary file.

• $HTTP_PROXY: Set this to the IP address of your HTTP proxy server.

• $HTTPS_PROXY: Set this to the IP address of your HTTPS proxy server.

• $NO_PROXY: Set this to localhost.

2. Build the PDC Kubectl image by entering this command from the ParentFolder/Docker_files/PDCJob directory:

docker build --force-rm=true --no-cache=true --build-arg HTTP_PROXY=$HTTP_PROXY --build-arg HTTPS_PROXY=$HTTPS_PROXY --build-arg NO_PROXY=$NO_PROXY --build-arg KUBECTL=$KUBECTL -t oracle/pdckubectl:12.0.0.x.0 -f Dockerfile .

Building Pipeline Configuration Center ImagesThe Pipeline Configuration Center image extends the Fusion Middleware Infrastructureimage by packaging its own installer PipelineConfigurationCenter_12.0.0.x.0_generic.jar file along with scripts and configurations.

To build your own image of Pipeline Configuration Center, you must have these baseimages ready. The oc-cn-docker-files-12.0.0.x.0.tgz package includes references toall Dockerfiles and scripts that are needed to build images of Pipeline ConfigurationCenter. You can refer to them when building a Pipeline Configuration Center image inyour own environment.

Chapter 8Building Pipeline Configuration Center Images

8-15

Pulling the Fusion Middleware Infrastructure ImageThe Fusion Middleware Infrastructure Image is available on the Oracle ContainerRegistry (http://container-registry.oracle.com). This image is regularly updated with thelatest security fixes. You can pull this image to your local system, where you will buildother images, with the name container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.3.

Building the Pipeline Configuration Center ImageTo build the Pipeline Configuration Center image, do this:

1. Go to the oc-cn-docker-files/ocpcc/pcc directory.

2. Download the Oracle Communications Pipeline Configuration Center installationJAR file.

3. Copy PipelineConfigurationCenter_12.0.0.x.0_generic.jar to the currentworking directory (oc-cn-docker-files/ocpcc/pcc).

4. Build the Pipeline Configuration Center image by entering this command:

docker build -t oracle/pcc:12.0.0.x.0 .

Building Billing Care ImagesThe Billing Care image extends the Fusion Middleware Infrastructure image bypackaging its own installer BillingCare_generic.jar file along with scripts andconfigurations. This image can install both Billing Care and the Billing Care REST API.

To build your own image of Billing Care, you must have these base images ready. Theoc-cn-docker-files-12.0.0.x.0.tgz package includes references to all Dockerfiles andscripts that are needed to build images of Billing Care. You can refer to them whenbuilding a Billing Care image in your own environment.

Pulling the Fusion Middleware Infrastructure ImageThe Fusion Middleware Infrastructure Image is available on the Oracle ContainerRegistry (http://container-registry.oracle.com). This image is regularly updated with thelatest security fixes. You can pull this image to your local system, where you will buildother images, with the name container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.3.

Building the Billing Care ImageTo build the Billing Care image, do this:

1. Go to the oc-cn-docker-files/ocbc/billing_care directory.

2. Download the Oracle Communications Billing Care installation JAR file.

3. Copy BillingCare_generic.jar to the current working directory (oc-cn-docker-files/ocbc/billing_care).

Chapter 8Building Billing Care Images

8-16



4. Build the Billing Care image by entering this command:

docker build -t oracle/billingcare:12.0.0.x.0 .

Building Business Operations Center ImagesBuilding your own BOC images involves these high-level steps:

1. Build the BOC image. See "Building the Business Operations Center Image".

2. Build the BRM Apps image. See "Building the Oracle BRM Apps Image".

3. Build the Kubectl image. See "Building the Kubectl Image".

Building the Business Operations Center ImageThe BOC image extends the Fusion Middleware Infrastructure image, packaging itsown installer BusinessOperationsCenter_generic.jar file along with scripts andconfiguration files. To build your own image of BOC, you must have the FusionMiddleware Infrastructure image ready.

The Fusion Middleware Infrastructure image is available on Oracle Container Registry(http://container-registry.oracle.com). This image is updated regularly with latestsecurity fixes. You can pull this image to your local system, where you will build otherimages, with the name container-registry.oracle.com/middleware/fmw-infrastructure:12.2.1.3.

The oc-cn-docker-files-12.0.0.x.0.tgz package includes references to all of theDockerfiles and scripts needed to build images of BOC. You can refer to them whenbuilding a BOC image in your own environment.

To build the BOC image, do this:

1. Go to the oc-cn-docker-files/ocboc/boc directory.

2. Download the Oracle Communications BOC installation JAR file.

3. Copy BusinessOperationsCenter_generic.jar to the current working directory(oc-cn-docker-files/ocboc/boc).

4. Build the BOC image by entering this command:

docker build -t oracle/boc:12.0.0.x.0 .

BOC requires openssh-clients, openssh-server, and other libraries that are not apart of the Fusion Middleware Infrastructure image. To download the libraries from theYum repository during the image build process, Docker must have internet access. Ifyou're behind a proxy server, your build command will look like this:

docker build --build-arg http_proxy=ProxyHost:Port --build-arg https_proxy=ProxyHost:Port -t oracle/boc:12.0.0.x.0 .

Building the Oracle BRM Apps ImageWhen you deploy BOC using oc-cn-helm-chart, it uses the brm-apps image andcopies its files to the BOC container to support scheduling BRM applications. Youmust have the brm-apps image ready before you deploy oc-cn-helm-chart for BOC.

Chapter 8Building Business Operations Center Images

8-17

http://container-registry.oracle.com/

You build the brm-apps image by using the Dockerfiles in oc-cn-dockerfiles/brm/brm_apps. To build the brm-apps image, see "Building Images of BRM ServerComponents".

You can check if the brm-apps image was built successfully by entering this command:

docker image ls

You can then retag the image by entering this command:

docker tag brm_apps:Tag brm_apps:12.0.0.x.0

Building the Kubectl ImageWhen you deploy BOC using oc-cn-helm-chart, it requires a Kubectl image toestablish passwordless SSH between two UNIX user accounts in the same BOCcontainer. You must have the Kubectl image ready before you can install or upgradeoc-cn-helm-chart for BOC.

The oc-cn-docker-files-12.0.0.x.0.tgz package includes a sample Dockerfile forbuilding a Kubectl image. You can refer to it when building a Kubectl image in yourown environment.

To build the Kubectl image, do this:

1. Go to the oc-cn-docker-files/ocboc/kubectl_image directory.

2. Download the Kubectl binary that is compatible with Oracle Linux.

3. Build the Kubectl image by entering this command:

docker build -t kubectl_img:v1 .

Chapter 8Building Business Operations Center Images

8-18

9Deploying into Oracle Cloud Infrastructure

This chapter describes how to deploy Oracle Communications Billing and RevenueManagement (BRM) cloud native services into Oracle Cloud Infrastructure.


• Deploying into Oracle Cloud Infrastructure

Deploying into Oracle Cloud InfrastructureOracle Cloud Infrastructure is a set of complementary cloud services that enable youto run a wide range of applications and services in a highly available hostedenvironment. It offers high-performance computing capabilities (as physical hardwareinstances) and storage capacity in a flexible overlay virtual network that is securelyaccessible from your on-premise network. Among many of its services, the BRM cloudnative deployment is tested in an Oracle Cloud Infrastructure environment using itsdatabase and container engine for Kubernetes services on a bare metal instance.

Deploying the BRM cloud native services into Oracle Cloud Infrastructure involvesthese high-level steps:

Note:

These are the bare minimum tasks for deploying BRM cloud native servicesin Oracle Cloud Infrastructure. Your steps may vary from the ones listedbelow.

1. Sign up for Oracle Cloud Infrastructure.

2. Create a database system on a bare metal or virtual machine instance.

Select a database version that is compatible with the BRM cloud native softwarerequirements. See "Software Compatibility".

3. Create a Kubernetes cluster and deselect the Tiller (Helm) Enabled option. Theversion of Helm used by Oracle Cloud Infrastructure isn't compatible with the BRMcloud native software requirements.

4. Install and configure the Oracle Cloud Infrastructure Command Line Interface(CLI).

CLI is a small footprint tool that you can use on its own or with the Console tocomplete OCI tasks. It's needed here to download the kubeconfig file.

5. Install and configure kubectl on your system to perform operations on your clusterin Oracle Cloud Infrastructure.

6. The kubeconfig file (by default named config and stored in the $HOME/.kubedirectory) provides the necessary details to access the cluster using kubectl andthe Kubernetes Dashboard.

9-1

Download kubeconfig to access your cluster on Oracle Cloud Infrastructure byentering this command:

oci ce cluster create-kubeconfig --cluster-id ClusterId --file $HOME/.kube/config --region RegionId --token-version 2.0.0

where ClusterId is the Oracle Cloud Identifier (OCID) of the cluster, and RegionIdis the region identifier such as us-phoenix-1 and us-ashburn-1.

7. Set the $KUBECONFIG environment variable to the downloaded kubeconfig fileby entering this command:

export KUBECONFIG=$HOME/.kube/config

8. Verify access to your cluster. You can enter this command and then match theoutput Internal IP Addresses and External IP Addresses against the nodes in yourcluster in the Oracle Cloud Infrastructure Console.

kubectl get node -o wide

9. Download and configure Helm in your local system.

10. Place the BRM cloud native Helm chart on your system where you havedownloaded and configured kubectl and Helm. Then, follow the instructions in"Installing the BRM Cloud Native Deployment Package".

Chapter 9Deploying into Oracle Cloud Infrastructure

9-2

10Integrating with Your BRM Cloud NativeDeployment

This chapter describes how to integrate the Oracle Communications Billing andRevenue Management (BRM) cloud native deployment with external systems.


• Integrating with Thick Clients

• Using a Custom TLS Certificate for Secure Connections

• Integrating with JCA Resource Adapter

• Integrating with BI Publisher

Integrating with Thick ClientsYou can integrate the BRM cloud native deployment with thick clients, such asCustomer Center and Pricing Center. To do so:

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

• ocbrm.cm.dnsName: Set this to the master node name.

• ocbrm.ENABLE_SSL: Set this to 1.

2. Copy the client wallet from the CM service to your thick client's wallet on Windows.

Note:

All thick clients installed in standard mode (that is, in non-WebStartmode) can be integrated with the BRM cloud native deployment. This isnot relevant for self care applications.

3. Update the Helm release. See "Updating a Helm Release".

Using a Custom TLS Certificate for Secure ConnectionsYou secure connections between the BRM cloud native deployment and externalservice providers, such as payment processors and tax calculators, by using SecureSockets Layer (SSL) certificates. By default, the BRM cloud native deployment usesthe TLS certificate provided with the BRM cloud native deployment package.

You can configure the BRM cloud native deployment to use your custom TLScertificate instead. You might do this, for example, to allow client applications outsideof the cloud environment to access the BRM cloud native connection manager (CM).In this case, the CM is exposed as a Kubernetes NodePort service.

To use a custom TLS certificate, do this:

10-1

1. When you generate your custom TLS certification, ensure that its SubjectAlternative Name (SAN) includes these:

dns:cmdns:HostName

where HostName is the hostname used to connect to the CM from outside theKubernetes cluster.

For example, if your CM is running on the ocbrm.example.com server and youuse Java Keytool to generate the custom SAN certificate, you'd enter thiscommand:

keytool -genkey -keyalg RSA -alias brm -keystore brm_custom.jks -validity 365 -keysize 2048 -ext san=dns:cm,dns:ocbrm.example.com

2. Create an Oracle wallet named brm_custom_wallet in the staging area and thencopy it to the top level of oc-cn-helm-chart:

mkdir brm_custom_walletorapki -nologo wallet create -wallet brm_custom_wallet -auto_login -pwd Password

3. Convert the Java Key store to Oracle wallet:

orapki wallet jks_to_pkcs12 -wallet brm_custom_wallet -pwd Password -keystore brm_custom.jks -jkspwd Password

4. Verify the contents of the wallet:

orapki wallet display -wallet brm_custom_wallet

5. Move your custom TLS certificate to oc-cn-helm-chart/brm_custom_wallet.

The wallet containing the custom certificate will be mounted at /oms/wallet/custom.

6. Update these keys in your override-values.yaml file for oc-cn-helm-chart andoc-cn-op-job-helm-chart:

• ocbrm.ENABLE_SSL: Set this to 1.

• ocbrm.cmSSLTermination: Set this to true.

• ocbrm.isSSLEnabled: Set this to true.

• ocbrm.customSSLWallet: Set this to true.

• ocbrm.wallet.client_location: Set this to /oms/wallet/custom.

• ocbrm.wallet.server_location: Set this to /oms/wallet/custom.

7. Install BRM cloud native services by entering this command from the helmchartsdirectory.


Integrating with JCA Resource AdapterYou can deploy the BRM JCA Resource Adapter in WebLogic Server and use it toexecute opcodes in the BRM cloud native deployment. When connecting to the BRMcloud native deployment, verify that the following properties are correctly updated inthe outbound connection properties.

Chapter 10Integrating with JCA Resource Adapter

10-2

For more information about JCA Resource Adapter, see BRM JCA Resource Adapter.

Table 10-1 lists the JCA Resource Adapter outbound connection properties forconnecting to the BRM cloud native deployment.

Note:

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

Table 10-1 JCA Resource Adapter Keys

Key Description

Password The BRM root password, which can be in plain text orencrypted in OZT.

JavaPcmSSL Set this to true.

SslWalletLocation Specify the location of the Oracle wallet that contains theBRM client TLS certificate. This can be copied from a BRMinstallation.

SslCipherSuites Set this to the desired TLS cipher. For a list of supportedTLS ciphers, see "BRM-Supported Cipher Suites" in BRMSystem Administrator's Guide.

Integrating with BI PublisherYou can optionally integrate the BRM cloud native deployment with BI Publisher soyou can generate your invoices.

To generate invoice PDFs in BI Publisher, run pin_inv_doc_gen outside of thecluster. Run docgen and pin_inv_doc_gen for the brm-apps container or throughBusiness Operations Center.

To integrate the BRM cloud native deployment with BI Publisher:

1. In the brm-apps container, set the export_dir and invoice_fmt entries in theconfigmap_pin_conf_brm_apps_1.yaml file.

Uncomment this entry:

- pin_inv_export export_dir ./invoice_dir

Set the invoice_fmt entry to text/xml:

- pin_inv_export invoice_fmt text/xml

2. Use the config-jobs job to change these configuration files to meet businessrequirements and then load them from loadme.sh.

Update these parameters in the bus_params_Invoicing.xml file:

<EnableInvoicingIntegration>enabled</EnableInvoicingIntegration><InvoiceStorageType>1</InvoiceStorageType>

Chapter 10Integrating with BI Publisher

10-3

3. Update these parameters in the bus_params_billing.xml file to meet yourbusiness requirements:

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

4. Specify which events to include in your invoices. In the events.file file,uncomment any events that you want to include in your invoices.

5. Modify the pin_business_profile.xml and pin_invoice_data_map files accordingto your business requirements. Run loadme.sh to load these changes.

For example, add these statements to loadme.sh and then run config_jobs.

pin_bus_params bus_params_Invoicing.xmlpin_bus_params bus_params_billing.xmlpin_load_invoice_events -reload -brand "0.0.0.1/account 1 0" -eventfile events.fileload_pin_business_profile pin_business_profile.xmlload_pin_invoice_data_map -dv pin_invoice_data_mapexit 0;

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

Chapter 10Integrating with BI Publisher

10-4

ASupported Utilities and Applications forbrm-apps Jobs

This appendix lists the utilities and applications that are supported by the brm-apps jobin the Oracle Communications Billing and Revenue Management (BRM) cloud nativedeployment.

The brm-apps job facilitates the execution of utilities and applications on demandwithout entering into the Pod.

Table A-1 lists the applications that can be run by the brm-apps job.

Table A-1 Supported Applications

Directory Application

apps/pin_inv_doc_gen pin_inv_doc_gen

apps/telco RunSimulator

apps/pin_aq pin_portal_sync_oracle.pl

apps/pin_billd pin_bill_daypin_bill_acctspin_depositpin_mass_refundpin_refundpin_deferred_actpin_ledger_report

apps/pin_collections pin_collectpin_collections_processpin_collections_send_dunning

apps/load_channel_config pin_channel_export

apps/pin_trial_bill pin_trial_bill_accts

apps/pin_job_executor pin_job_executor

apps/pin_ifw_sync pin_ifw_sync_oracle.pl

apps/pin_monitor pin_monitor_balance

apps/pin_bulk_adjust pin_apply_bulk_adjustment

apps/partition_utils partition_utils

apps/pin_sepa pin_sepa

apps/pin_ra_check_thresholds pin_ra_check_thresholds

apps/pin_event_extract pin_event_extract

apps/pin_rerate pin_rerate

apps/integrate_sync pin_history_on

apps/storable_class_to_xml storableclasstoxml

apps/load_config load_config

A-1

Table A-1 (Cont.) Supported Applications

Directory Application

apps/pin_inv pin_inv_sendpin_inv_exportpin_inv_accts

apps/pin_remit pin_remittancepin_remit_month

apps/pin_export_price pin_export_price

apps/load_price_list loadpricelist

Appendix A

A-2

BSupported Load Utilities for ConfiguratorJobs

The configurator job facilitates the execution of load utilities on demand withoutentering into the Pod. You can use the configurator job to run these load utilities:

• load_pin_suspense_editable_flds

• load_pin_payment_term

• load_pin_glchartaccts

• load_pin_event_record_map

• load_pin_config_ra_thresholds

• load_pin_telco_service_order_state

• load_pin_sim_config

• load_pin_order_state

• load_pin_excluded_logins

• load_pin_config_ra_flows

• load_pin_config_business_type

• load_pin_ach

• load_pin_spec_rates

• load_pin_service_framework_permitted_service_types

• load_pin_rerate_flds

• load_pin_notify

• load_pin_batch_suspense_reason_code

• load_usage_map

• load_suspended_batch_info

• load_pin_suspense_edr_fld_map

• load_pin_config_ood_criteria

• load_pin_config_export_gl

• load_pin_ar_taxes

• load_config_provisioning_tags

• load_config_item_types

• load_pin_telco_provisioning

• load_event_map

• load_config_item_tags

• load_pin_telco_tags

B-1

• load_pin_remittance_flds

• load_pin_calendar

• load_transition_type

• load_pin_suspense_params

• load_pin_recharge_card_type

• load_pin_num_config

• load_pin_network_elements

• load_pin_batch_suspense_override_reason

• load_localized_strings

• load_pin_suspense_reason_code

• load_pin_bill_suppression

• load_pin_beid

• load_pin_voucher_config

• load_pin_remittance_spec

• load_pin_rum

• load_pin_rtp_trim_flist

• load_pin_dealers

• load_pin_invoice_data_map

• load_pin_billing_segment

• load_pin_verify

• load_pin_sub_bal_contributor

• load_pin_config_ra_alerts

• load_pin_bus_params

• load_tax_supplier

• load_pin_device_state

• load_pin_config_batchstat_link

• load_pin_business_profile

• load_pin_suspense_override_reason

• load_pin_snowball_distribution

• load_pin_glid

• load_edr_field_mapping

• load_pin_impact_category

• load_pin_config_controlpoint_link

• load_pin_config_auth_reauth_info

• load_content_srvc_profiles

• load_pin_customer_segment

• load_pin_device_permit_map

Appendix B

B-2

• pin_deploy

• pin_uei_deploy

• load_ara_config_object

• load_channel_config

• testnap

Appendix B

B-3

Documents

Revenue Management Oracle® Communications Billing and · 2020-04-29 · Deploying Paymentech Data Manager in HA Mode 3-18 Configuring Elastic Charging Engine 3-19 Adding Elastic