We decided to share with you lessons learned, which we gain by migrating from Oracle BRM 7.5 to Oracle BRM 12 for one of our telecom company. First off all, why we did upgrade of the Oracle BRM billing system? There are mainly two reasons why we decided to perform this. First reason is to modernize the overall architecture and the second reason is to stay compliant with oracle licences.

Oracle BRM HA Availability

Current high-availability (HA) architecture has the following components:

• Diameter and MBI gateway.
• Oracle Communications Billing and Revenue Management System – BRM 7.5.
• Client applications (Customer Center, Pricing Center, Developer Center, Permissioning Center, etc).

Oracle BRM 7.5 architecture

New modern Oracle BRM architecture

Components of the latest, modernized Oracle BRM 12 architecture are as follows:

• Oracle Elastic Charging Engine (ECE) 11.3.
• Oracle NoSQL 12.
• Oracle BRM 12.
• Oracle Database 12c.
• Oracle Weblogic 12c.
• Oracle Pricing Design Center (PDC) 12.
• Oracle BRM Billing Care 12.

Key benefits of the new Oracle BRM 12 architecture

With adding new components such as Oracle Weblogic, ECE and PDC we gain in several areas. Oracle ECE contributes to the overall scalability part. There is an ever growing increase of request from various IoT devices and for that reason we need a fast and low latency rating engine, which can scale.
Another key area is also delivering notifications, which occur inside the billing system to external systems. The existing Oracle BRM notification framework is relying on Oracle AQ. However, notification system provided by Oracle ECE is using JMS queuing. With help of Weblogic JMS we can now bridge the existing Oracle AQ queue and leverage only JMS messaging. Oracle BRM 12 PDC is now a web based application, which can be accessed from anywhere and it does not need to be installed locally.

Oracle BRM 12 key components

• Oracle Elastic Charging Engine – is the main rating engine for online and offline charging for the BRM system. ECE is highly scalable because it leverages Oracle Coherence an in-memory data grid solution. It can process up to a couple of thousands of transactions per second. It also has built in diameter gateway component which is able to process request from the network
• Oracle BRM 12 – is a complete solution to capture, generate, collect and analyze revenue. The system is highly customizable and can fit pretty much any industry.
• Oracle Weblogic – is an application servers for building and deploying Java EE applications such as Pricing Design Center and Billing Care.
• Oracle Pricing Design Center – is a web based application for managing your pricing catalog. With PDC we can setup pricing for all the services and products that an organization is offering. PDC has it is own database schema which is synchronized with ECE and Oracle BRM.
• Oracle BRM 12 Billing Care – is a web based application for managing your customer base. It gives us the ability to create new customers as well as assign new services. Billing Care has its own SDK with help of which we can customize to fit the requirements of a business.

Conclusion

In this article we gave a brief overview of how we performed the modernization of Oracle BRM 7.5 and what components are being used. Moreover, in future articles we will go into more details for each of the components and describe how to set it up and describe the main features of Oracle BRM 12.

The post Oracle BRM 12 real-time convergent charging Telecom billing  appeared first on Tridens Technology.

When you have been maintaining your Oracle BRM (Billing and Revenue Management) configuration for some time, you begin to realize that the amount of configured entities keeps growing. By this time, it is very likely that you also developed some customizations and integrated with additional solutions. The evolution of your environment leads to a complex cluster of intertwined objects. There comes the point where you, or your client, decide to change something. The new feature might seem easy to develop at first. The truth, however, is that it will very likely collide with an existing feature, or will require the update of existing configuration as well. What seemed a simple change, then affects the whole system. Such occurrences are sometimes challenging to avoid, but being prepared for them can save you a lot of trouble. Functional test scenarios and testing versatility can be a game-changer.

Continuous Development Flow

Here at Tridens, we have established a continuous development flow. All our BRM configurations, customizations, and other integrated components are properly versioned and tracked on a distributed version control system (Git). This practice allows our developers to check out required component versions at any time and begin their work. Everything is fine to this point, but how do we tackle the possibility of new features breaking the current build?

We have a deployment and testing flow set up, which tracks the remote repositories of our sources. Consequently, each time a developer commits and pushes some changes to version-control, this initiates the testing process. The deployment flow builds docker images for all relevant components with their latest versions on a local (or remote) environment, and automated tests are executed to ensure that the build is stable. Only when the tests are successful, can we release the new versions to production. This process helps us ensure that new features work seamlessly with existing ones. The executed tests are a part of the Oracle BRM TestToolkit, which we developed. The BRM TestToolkit has predefined steps and scenarios with background glue code. The steps are very descriptive and user-friendly, allowing our developers or any other user to write new test scenarios quickly. Find an example of test scenarios in the image below.

BRM TestToolkit for Automated Testing

What started as simple test scenarios for account creations and product purchases, represents today, the mainframe of our testing BRM TestToolkit. To clarify, we now have several different test cases and fringe-case scenarios to ensure maximum coverage of implemented features. Automated tests allow our developers to focus on the task at hand and not spend vast amounts of time for manual testing. Of course, sometimes, we find ourselves developing a new feature not yet covered by test scenarios. In such cases, test step definitions and their background code are implemented as a part of that feature – to be used in the future as well.

The TestToolkit can communicate with different components, enabling the possibility of quick adjustments for other systems as well. We also use redesigned versions of our BRM TestToolkit for our other components. One of the latest features we added was modularity, where developers can tag different test scenarios as parts of a group. Each group then has its scripts and separated logic, allowing, if desired, only a specific number of tests to be executed at a time and in parallel. Furthermore, modularity enables us to separate prepaid rating tests from postpaid rating tests or addon purchase tests from miscellaneous purchases. You can see the test flow in the image below.

Test Scenario Coverage

The BRM TestToolkit communicates with our API, which we integrated with Oracle BRM for simplification of more complex operations. The TestToolkit can also interact with the BRM RestBridge, our BRM wrapper solution, which eases communication with BRM by allowing the use of JSON or XML format via a REST API. The test step definitions support, among many others, the following operations:

• Account creation and management
• Deal purchase and other deal operations
• Balance retrieval and check
• Traffic generating – Usage events
  • API calls
  • CDR drop-off
  • real-time traffic tools (diameter protocol)
• Rating checks
  • The BRM TestToolkit compares different usage events and purchases against expected values
  • each different plan or product can have its own set of rating files, ensuring versatility in complex product setups

By composing the user-friendly test steps, each developer can write the scenarios for the feature in development. In many cases, our developers choose to set up the test scenarios in advance – before developing the feature. Preparing scenarios in advance follows the Behaviour Driven Development (BDD) pattern. BDD essentially means that the scenarios dictate the development flow and should exist in advance. These scenarios describe how the system should behave, and developers must develop new features in a way to fit these scenarios. We can execute each test-scenario can be separately, resulting in a report in a specified format. Below is the example of an HTML report.

Reporting

When the system runs the test-scenarios as a part of a new development build, it usually executes them in their full potential – including all tests. From environment to environment, this can take some time, but it provides you with a broad picture of how the new feature might have affected any other existing implementations. We can assess build stability from the test report, which the BRM TestToolkit generates at the end of a test run. Test Reports contain details for each test scenario, but also provide some statistics and analytics about all tests in general. We can use this analysis to find differences between builds and to ensure that a build is working correctly. See an example of a report below.

Conclusion

Having the right testing solution can save vast amounts of time and prevent any unnecessary bugs from occurring. Therefore, if you are struggling with any difficulties mentioned in this article, or if you are interested in our Testing BRM Toolkit, feel free to contact us. We will gladly tell you more about our solution and devise an optimal plan on how to improve your deployment and testing flow.

The post BRM TestToolkit for Automated Testing appeared first on Tridens Technology.

Oracle BRM 12 is one of the best enterprise billing and revenue management systems on the market and is setting the standards that others strive to meet. BRM has years and even decades-long history (together with its predecessors Infranet and Portal). After Oracle acquired Portal Software in 2006, development continued with new service packs and new software versions introducing new features regularly.
Recently Oracle BRM 12 turned an entirely new chapter and reached a new exciting major milestone with releasing Oracle BRM Cloud-Native Deployment. This release allows BRM to deploy natively to Kubernetes cloud environment, which opens new ways of using BRM in SaaS (software as a service), PaaS (platform as a service) and IaaS (infrastructure as a service) solutions. Deploying to the cloud brings us some benefits over the traditional model of software deployment, such as scalability and reliability. When deployed to the new cloud system and hardware resources can be added to BRM on demand if needed without concerns over big capital investments in additional hardware. You can scale your deployment dynamically and add other nodes and replicas for specific BRM services or remove them if they are not needed anymore. Kubernetes takes care of your running pods and makes sure that all services are up and running, resulting in above-average uptime for cloud deployments as compared to on-premise software deployment.
Officially Oracle Cloud is supported currently for Oracle BRM Cloud Native deployment, although it is possible to deploy BRM to some other cloud environments also. In this article, we will take a look at how to deploy Oracle BRM to Oracle Cloud.

About Oracle Cloud

Oracle Corporation is offering its cloud computing service (Oracle Cloud) that provides services, storage, servers, etc. through a global network of managed data centers. You can choose which managed data center you want to use when setting up your cloud environment. Usually, you want to select one which is geographically close to you. Some basic features of Oracle Cloud (like some essential instances of Autonomous Database and Virtual Machine – with limitations) are in a free tier of Oracle Cloud (named “Always Free Eligible”) and can be used for free for an unlimited time. You can also take advantage of a 30-day free trial, and in that timeframe, you can test out more advanced features and possibilities that Oracle Cloud is offering to you. Your account can always be upgraded to a paid version. Oracle Cloud provides a handy cost estimation calculator where you can set up your infrastructure and services that you want to use, and the calculator returns you cost estimations for your chosen set up.
Now let’s take a look at how you can perform Oracle BRM Native Cloud Deployment in Oracle Cloud free of charge for testing purposes.

Deploying Oracle BRM 12 to Oracle Cloud for testing purposes

First, you have to get a correct version of BRM software from Oracle Software Delivery Cloud (edelivery.oracle.com). Search for “Oracle Communications Billing and Revenue Management Cloud-Native Deployment Option” and get the latest available version. Then you have to sign up for using Oracle Cloud (https://www.oracle.com/cloud/sign-in.html). After signing up and setting up your account, you will be presented with Oracle Cloud Dashboard screen similar to that shown on Picture 1.

Picture 1: Oracle Cloud Dashboard

As you can see, there are some “Always Free Eligible” options presented to you here. Unfortunately, to test out theOracle BRM Cloud-Native Deployment free tier of Oracle Cloud will not suffice. You will have to use some more advanced features, but you can try them out free of charge for 30 days.

Preparing Database System for Oracle BRM services

First, you need to prepare a database for your BRM deployment. Open the main menu by clicking on a hamburger button to open the main menu, then choose the “Bare Metal, VM, and Exadata” option under the “Database” section. Now click on the “Create DB System” button. Here you can configure your new database instance as shown in picture 2.

Picture 2: Setting up DB System

You must choose a name for your DB system and select on which availability domain in your chosen managed data center do you want to run it. Choose the “Virtual Machine” shape type and some basic shape for your database (it will suffice for our testing purposes). Choose “Enterprise Edition High Performance” as your Database software edition. Note that if you choose “Enterprise Edition,” then your database instance will not support partitioning, and your BRM deployment will fail as a consequence. You can then also tune some other instance parameters and upload your SSH public key for access. On the next page, you can configure some more options and define administrator credentials for your database instance (they are essential, remember them). Now you can confirm your settings and DB System will be created.

One important note here: if you get a message that you reached your service limit for creating DB System in this availability domain, then you have to open a service request (SR) for Oracle Support to enable that option to you. Go to Main menu -> Governance -> Limits, Quotas, and Usage. Find a link to request a service limit increase on that page. After opening a service request, it may take a few days to have that request granted, however usually such requests are resolved quickly.

Now that you have a DB system for our cloud-native BRM provisioned and running, you have to prepare DB tablespaces and schemas. First, you have to configure your Oracle SQL Developer (or another client) to connect to your newly created database.

Picture 3: DB System nodes

One way to do this is to use the public IP address of your DB system. You can find your public IP address under the Nodes section of your DB system page. Use this address and other data found on your DB system page to configure the Oracle SQL Developer connection. Login as SYSDBA and perform preparatory steps for the database found in Oracle BRM documentation.

Preparing Kubernetes cluster for Oracle BRM services

Now you have to prepare your Kubernetes cluster in Oracle Cloud. Open main menu -> Developer Services -> Container Clusters (OKE). Click on Create cluster and fill out the form to create a new cluster.

Picture 4: Creating a new container cluster in Oracle Cloud

After your cluster is created, you also have to install docker, kubectl, and helm to your local machine. You can find instructions on how to install all these components on their corresponding official websites. Then you must configure your local environment to manage remote container clusters in Oracle Cloud. You can find instructions on how to do that by clicking on a button “Access Kubeconfig” as shown on

Picture 5: Access Kubeconfig button

Deploying Oracle BRM Cloud Native Deployment to Kubernetes cluster

When your database is configured as per documentation, and your Kubernetes cluster created and running, you can proceed with deploying BRM. First, you have to load all provided docker BRM images to your docker environment, then tag them and push them to a remote repository in Oracle Cloud so that images will be found when you deploy helm charts.
Basically, you must follow instructions found here: https://www.oracle.com/webfolder/technetwork/tutorials/obe/oci/registry/index.html
But instead of pulling a hello-world image in step 3, you have to load Oracle BRM images from tar files.
When images are loaded and pushed to the repository in Oracle Cloud Infrastructure, you are ready to deploy helm charts.
Oracle BRM Cloud-Native Deployment package provides you with two charts:

• oc-cn-init-db-helm-chart that deploys init_db image which creates all necessary tables, indexes, views, etc. and loads initial default data into database for BRM services to be able to run,
• oc-cn-helm-chart that deploys BRM cloud-native services

You have to deploy oc-cn-init-db-helm-chart first to prepare your database for BRM services.
Go to folder where oc-cn-init-db-helm-chart is unpacked and copy values.yaml to override-values.yaml. Then open file override-values.yaml and configure all necessary values according to instructions found in Oracle BRM Cloud-Native Deployment documentation. Pay special attention to the fact that all passwords must be entered in base64 encoding.
You have to configure “imageRepository” field to point to your Oracle Cloud Infrastructure registry so that images can be found, for example:

imageRepository: “eu-frankfurt-1.ocir.io/frm097gtmuzm/”

Note also “/” which is required for chart to deploy correctly. In “db” section of your override-values.yaml file, you have to provide access data for your database. There is no need to use public IP as DB host here; actually, it is much better to use private IP address or DNS name for performance reasons.
After configuring override values for helm chart you can deploy it with the following command:

helm install oc-cn-init-db-helm-chart –name initdb –values oc-cn-init-db-helm-chart/override-values.yaml

Now helm will deploy BRM DB initialization image to Kubernetes cluster and start to prepare your database for BRM.
You can check the status of your deployment with:

helm status initdb

If you see any issues with pods there are multiple techniques to debug such issues. One basic approach is to check the logs of failing pod:
kubectl logs
Also, another command can provide you useful debug data:

kubectl describe pods

After your database is initialized, you can prepare another chart – oc-cn-helm-chart – for deployment. This chart will actually deploy BRM to your cluster. You can copy “db” section of override-values.yaml file from your oc-cn-init-db-helm-chart to oc-cn-helm-chart. Then you have to configure all other needed values in override-values.yaml in a similar way as for oc-cn-init-db-helm-chart. You can find a description of all the keys in the Oracle BRM Cloud Native Deployment documentation. Note that all passwords have to be base64 encoded. If you don’t want to deploy all BRM components, you can remove files of specific components from the templates subdirectory inside chart folder and remove relevant sections from override-values.yaml file.

You can then deploy BRM with the following command:

helm install oc-cn-helm-chart –name occn-ps2 –namespace ocgbu –values oc-cn-helm-chart/override-values.yaml

Note that you have to deploy oc-cn-helm-chart in a different namespace (in our example “ocgbu”) than oc-cn-init-db-helm-chart.
It is useful to monitor your Kubernetes deployment with Kubernetes Dashboard. Because Kubernetes Dashboard is not deployed by default, you can deploy it to your cluster using the following command:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta6/aio/deploy/recommended.yaml

Then you have to run proxy service to access the Dashboard:

kubectl proxy

Now you can open Kubernetes Dashboard in your browser using the following address:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

You can see Kubernetes Dashboard display of deployed services on picture 6.

Picture 6: Kubernetes Dashboard showing deployed Oracle BRM services

It is also possible to open shell inside one of the running pods. This can sometimes be useful for a number of reasons, for example, if you want to access some internal logs. You can open shell inside a pod with a following command:

kubectl exec -n -it — /bin/bash

Logs can usually be found on a path /oms_logs in pod.
Congratulations, you successfully deployed Oracle BRM Cloud-Native Deployment to Oracle Cloud!

Conclusion

This article explains all the main steps needed to deploy Oracle BRM Cloud-Native Deployment to Oracle Cloud Infrastructure. If you need any additional help with deploying Oracle BRM to Oracle Cloud, need suggestions, or if you are searching for a reliable solution provider for all your billing needs, feel free to contact us. But deploying Oracle BRM Cloud-Native Deployment to Oracle Cloud is not the only option to test it out. You can deploy it also to your local server environment. We will look at how to do that in one of our upcoming articles.

The post Oracle BRM 12 Cloud-Native Deployment to Oracle Cloud appeared first on Tridens Technology.

In one of our previous articles we already presented deployment of Oracle BRM 12 Cloud Native Deployment version to Oracle Cloud (https://tridenstechnology.com/oracle-brm-12-cloud-native-deployment-to-oracle-cloud/). Oracle Cloud is very well-designed cloud environment, which is also affordable and constantly evolving. However, if you want to deploy Oracle BRM 12 to Oracle Cloud you have to use some non-free features and components of Oracle Cloud that you can test for free for 30 days only. After that you have to upgrade to paid account if you want to continue using it.

You also have another option if you want to test out Oracle BRM 12 Cloud Native Deployment. You can go for an on-premise deployment and deploy BRM to your local servers. The main purpose of this article is to show you how you can achieve that. This article will show you how you can create and run a local Kubernetes cluster using Minikube and how you can deploy Oracle BRM 12 into your newly created and configured cluster. Please note that Minikube is suitable only for testing and development purposes, and you should not use it on a production environment. Let’s take a look at specific components of our system that we will use and how to install them.

About Oracle Linux 8

We will base our solution on a Linux operating system, namely Oracle Linux version 8. This Linux distribution is provided by Oracle and available for free. It is based on Red Hat Enterprise Linux. For this operating system you can also get a commercial technical support if you need it. It is also worth mentioning that Oracle Cloud is powered mainly by Oracle Linux servers.

We will use Oracle Linux version 8 for the purpose of this article. Of course you can use also other Linux distributions but instructions for preparing your environment can vary according to that. If you want to use Oracle Linux, you can download it freely from Oracle Software Delivery Cloud or from many mirror sites available worldwide.

You can install Oracle Linux directly on your servers or inside a virtual machine. In the latter case your virtualization software has to support nested virtualization if you want to closely follow instructions in this article.

After installing Oracle Linux make sure to update your software packages to latest versions before continuing:

sudo yum update

Then install some other required packages:

sudo yum install -y yum-utils device-mapper-persistent-data lvm2

Now you are ready to start preparing your Kubernetes cluster. First we will install Docker.

Installing Docker

Docker is a set of products that allows you to deploy and run containerized software. Containers are software bundles that bundle their own software, configuration and all needed libraries into one package, called container.

Here are instructions for installing Docker on Oracle Linux 8:

sudo curl https://download.docker.com/linux/centos/docker-ce.repo -o /etc/yum.repos.d/docker-ce.repo

sudo yum makecache

sudo yum remove podman-manpages

sudo dnf -y install docker-ce –nobest

systemctl start docker

systemctl enable docker

systemctl status docker

To enable Docker for current user:

sudo usermod -aG docker

newgrp docker

Installing kubectl

We will continue now with installing kubectl, which is command-line tool that allows you to control a Kubernetes cluster.

Download the latest stable version of kubectl and move it to a system folder:

curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl

chmod +x ./kubectl

sudo mv ./kubectl /usr/local/bin/kubectl

You can check if kubectl is working by issuing the following command:

kubectl version

You will receive output similar to this:

Client Version: version.Info{Major:”1″, Minor:”17″, GitVersion:”v1.17.3″, GitCommit:”06ad960bfd03b39c8310aaf92d1e7c12ce618213″, GitTreeState:”clean”, BuildDate:”2020-02-11T18:14:22Z”, GoVersion:”go1.13.6″, Compiler:”gc”, Platform:”linux/amd64″}

The connection to the server localhost:8080 was refused – did you specify the right host or port?

For now you can ignore error in the last line of command input.

Installing Oracle VirtualBox

VirtualBox is a virtualization product provided by Oracle and we will use it as a hypervisor for our minikube Kubernetes cluster. To install VirtualBox to our system we must add an additional repository first:

cd /etc/yum.repos.d/

sudo wget http://download.virtualbox.org/virtualbox/rpm/rhel/virtualbox.repo

Install some other needed packages:

sudo yum install binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel elfutils-libelf-devel

Now you are ready to install VirtualBox:

sudo yum install VirtualBox-6.1

At this point we are ready to install Minikube.

Installing Minikube

Minikube is Docker-based Kubernetes cluster that is suitable for testing and development purposes. We will deploy Oracle BRM 12 Cloud Native Deployment which is containerized version of Oracle BRM to Minikube Kubernetes cluster.

Now install minikube:

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube

sudo mkdir -p /usr/local/bin/

sudo install minikube /usr/local/bin/

We can now start minikube that will prepare its environment and create a new virtual machine. Default minikube values for virtual disk size and amount of memory for virtual machine are too low for Oracle BRM, therefore we will explicitly raise them (obviously you must have enough physical memory available for that else you may experience various issues):

minikube start –disk-size=’800g’ –memory=’8192m’

You can check if minikube was successfully configured:

kubectl -n kube-system get pod

You will get some output like this:

$ kubectl -n kube-system get pod

NAME READY STATUS RESTARTS AGE

coredns-6955765f44-d8wj4 1/1 Running 0 7m54s

coredns-6955765f44-fd2lt 1/1 Running 0 7m54s

etcd-minikube 1/1 Running 0 7m46s

kube-apiserver-minikube 1/1 Running 0 7m46s

kube-controller-manager-minikube 1/1 Running 0 7m46s

kube-proxy-j575p 1/1 Running 0 7m54s

kube-scheduler-minikube 1/1 Running 0 7m46s

storage-provisioner 1/1 Running 0 7m52s

Load environment variables needed to work with minikube and docker on your environment:

eval $(minikube docker-env)

We need additional component before we deploy BRM to our newly created cluster – Helm.

Installing Helm

Helm is a package manager for Kubernetes. Helm charts are used to manage, install and upgrade your Kubernetes cluster. Oracle bundles Helm charts needed for deploying and configuring Oracle BRM 12 deployment in their Cloud Native Deployment version of BRM.

Now let’s install Helm:

curl -LO https://git.io/get_helm.sh

chmod +x ./helm.sh

./get_helm.sh

Perform initial configuration of helm:

helm init –history-max 200

Now your environment is ready to start deploying Oracle BRM 12. Obviously you have to perform some preparation steps on your Oracle Database instance so that Oracle BRM can use it. Detailed explanation of these steps exceeds the scope of this article, but you can find all the necessary information about this in Oracle BRM documentation or contact us and we will be glad to help you.

Deploying Oracle BRM 12 to Kubernetes cluster

First, you have to load all provided docker BRM images to your docker environment. Oracle provides you with two Helm charts – the first one (oc-cn-init-db-helm-chart) initializes your DB schema to prepare it for BRM, and the other one (oc-cn-helm-chart) deploys various BRM components that you choose.

You have to start by deploying oc-cn-init-db-helm-chart. First you have to load init_db Docker image into Docker repository:

docker load –input oc-cn-brm-init-db-12.0.0.2.0.tar

After image is successfully loaded, extract oc-cn-init-db-helm-chart and copy values.yaml to override-values.yaml. Then edit override-values.yaml according to Oracle BRM 12 Cloud Native Deployment documentation. Leave “imageRepository” value blank. In a “wallet” section set credentials for Oracle wallet. You have to set your database connection settings under a “db” section. After you configure all necessary values in override-values.yaml file, you can deploy init_db image to your Kubernetes cluster using Helm chart:

helm install oc-cn-init-db-helm-chart –name initdb –values oc-cn-init-db-helm- chart/override-values.yaml

Now helm will deploy BRM DB initialization image to Kubernetes cluster and start to prepare your database for BRM.
You can check the status of your deployment with:

helm status initdb

After a while initdb pod will finish preparing your database and you can delete the current deployment of initdb image:

helm delete initdb

Now unpack oc-cn-helm-chart.tgz and copy values.yaml to override-values.yaml. Now edit various fields in override-values.yaml according to instructions found in Oracle BRM 12 Cloud Native Deployment. You can copy some fields (like “wallet” and “db” sections) from init-db chart that you used before.

Use “docker load –input” command to load all docker images that you want to deploy to Docker repository.

Then you can deploy Helm chart:

helm install oc-cn-helm-chart –name occn-ps2 –namespace ocgbu –values oc-cn-helm-chart/override-values.yaml

Now BRM will deploy to your local Kubernetes cluster. You can find some more tips about monitoring cluster and diagnosing issues in our previous article.

You can also monitor your Kubernetes cluster with Kubernetes Dashboard:

minikube dashboard

Dashboard will open in a new browser window.

Conclusion

This article guides you through the main steps of deploying Oracle BRM Cloud Native Deployment to a local minikube Kubernetes cluster. You can use this deployment for testing and development purposes. If you need any additional help with deploying Oracle BRM to minikube, need suggestions, or if you are searching for a reliable solution provider for all your billing needs, feel free to contact us.

The post Oracle BRM 12 Cloud-Native Deployment with Minikube appeared first on Tridens Technology.