1. Developer's Guide
  2. Introduction to Customizing BRM
  3. Using BRM SDK

8 Using BRM SDK

Learn how to use the Oracle Communications Billing and Revenue Management (BRM) SDK to customize BRM or client applications.

In addition to the BRM SDK, you can use the Developer Center application to create storable classes and test applications.

Topics in this document:

About BRM SDK

BRM Software Development Kit (SDK) provides the APIs, libraries, and other resources you need to perform the following tasks:

  • Write client applications in C, C++, Java, and Perl.

  • Write and customize policy Facilities Modules (FMs) in C.

  • Write custom standard FMs in C.

  • Write custom Data Managers (DMs) in C.

  • Use sample applications and code as examples for your own work.

  • Use debug versions of libraries, FMs, the DM, and the Connection Manager (CM).

  • Develop multithreaded applications for BRM.

BRM SDK includes a common core library (libportal.so) that combines the previously separate PCM, PCP, and PIN libraries. (The separate libraries are also included for backward compatibility.) Other libraries, including standard and policy FMs and support for C, C++, Java, and Perl, are located in the same directory.

About PCM SDK

PCM SDK contains 64-bit PCM libraries that you require to create 64-bit client applications. PCM SDK is a part of BRM SDK and is installed along with the BRM server.

BRM SDK Directory Contents

When you install BRM SDK, the following subdirectories are included. The default installation directory for BRM SDK is BRM_home/PortalDevKit, where BRM_home is the directory in which the BRM server software is installed. To make it easier to find files, the BRM SDK directory structure is similar to the directory structure on BRM servers as shown in Table 8-1.

Table 8-1 SDK Directory Structure

Directory Contents

lib

Core and FM libraries, including libportal.so on Linux.

bin

CM and DM executables, testnap, perl.exe.

include

Base BRM header files, including pin_os_dynload.h.

sys

Server system files.

sys/lib

CM source library files.

source

Top-level directory for source code.

source/sys

Policy FM source code.

source/sys/cm

CM source file and Makefile for use in building Purify versions of the CM.

source/templates

FM and DM templates.

source/samples

Top-level directory for sample code and applications.

source/samples/context

Context management code samples in C, C++, Java, and Perl.

source/samples/callopcode

Opcode-related code samples in C, C++, Java, and Perl.

source/samples/flists

Flist-related code samples in C, C++, Java, and Perl.

source/samples/apps

Sample applications in C, C++, and Java.

source/samples/apps/c/mta_samples

Sample files for creating multithreaded applications.

jars

pcm.jar, pcmext.jar, and other Java PCM files.

Deploying New and Customized Components

After you successfully test an application, FM, or DM, you can deploy it to your production BRM installation.

Because BRM SDK includes the same libraries as BRM itself, dynamic links work without modification when you deploy new or customized server components to default locations.

Deploying Applications

To deploy a new application, you move the executable itself plus any necessary support libraries to the desired location. The libraries you must include depend on the language you used to write the application. For example, applications written in C need the libportal.so file, while applications written in Java need pcm.jar and pcmext.jar files. Depending on how your application is written, you might also need to include a configuration file (pin.conf for C/C++ applications or Infranet.properties for Java applications) for storing login information.

For more information about the files required, see the sections about writing client applications in the supported languages.

In most cases, you should package your application and its support files so that the files can be installed conveniently.

Deploying FMs

To deploy a new or customized FM:

  1. Compile the FM into a shared library (.so for Linux).

  2. For each CM server in the BRM installation:

    1. Stop the CM.

    2. Move the new shared library to BRM_home/lib.

    3. If this is a new FM, modify the CM pin.conf file to include the FM.

    4. Restart the CM.

Deploying DMs

The files you must deploy with a DM depend on whether the destination server is already in use as a DM server.

  • If you are deploying a new or customized DM to an existing DM server, you must move only the compiled .so file and the associated pin.conf file.

  • If you are deploying to a server that has not previously been used for DMs, you need the compiled .so, .a, or .so file, the DM pin.conf file, all the libraries linked to the DM, and a dm.exe file.

In either case, you must modify the pin.conf file of all CMs that will use this DM. See "Configuring Your CM to Use the Custom DM".

You should also modify the BRM start and stop scripts to include the new DM. See "Starting and Stopping Your Custom DM".

Compiling CMs for Purify

To enable customers to build versions of the CM for use with Rational Purify, BRM SDK includes a C++ source file along with related library and include files. To build a Purify version, you modify the source file to include your custom FMs and then compile.

Table 8-2 lists the CM build files for use with Purify:

Table 8-2 CM Build Files for Purify

File Location

cm.cpp

makefile

BRM_SDK_home/source/sys/cm

libcm_main.so (Linux)

BRM_SDK_home/sys/lib

Also in:

BRM_home/sys/lib

pin_os_dynload.h

BRM_SDK_home/include

When you compile a CM, you must specify options that point to the /include and /lib directories that contain the pin_os_dynload and libcm_main files. You must also specify the use of multithreaded components and dynamically loaded libraries. (The makefile in BRM_SDK_home/source/sys/cm includes these options.)

To reduce thread contention on malloc calls, CMs include a memory pool mechanism for processing flists and POIDs. When flists and POIDs are allocated memory from a pool, problems with memory leaks are hidden. To detect memory leaks in your CM, before you run Purify or any other diagnostic utilities to test memory usage, disable the memory pool by adding the following entry in the CM pin.conf file so that memory is allocated from the system heap: 

- - disable_pcm_mempool 1

You can use the following commands as examples for compiling a Purify version of the CM. Depending on your operating system and the compiler you use, your syntax may be somewhat different.

Linux:

purify gcc -o cm cm.cpp -g -Bdymanic -Wl,--export-dynamic -ldl -lpthread -I ${INFRANET_SDK_home} -L ${INFRANET_SDK_home}-lpinsys -lcm_main