7 Using BRM Developer Tools

This chapter includes instructions for using two Oracle Communications Billing and Revenue Management (BRM) customization tools, BRM SDK and Developer Center:

  • BRM Software Development Kit (SDK) contains the application programming interfaces (APIs), libraries, and samples you need to write and customize BRM components and applications.

    See "About BRM SDK".

  • Developer Center provides a suite of developer applications that you use to customize BRM.

    See "About Developer Center".

BRM also includes a set of utilities for managing and manipulating data, handling errors, and using configuration files. See "Developer Utilities".


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

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 as well as support for C, C++, Java, and Perl, are located in the same directory.

To customize Customer Center, install the Customer Center SDK. See "Using Customer Center SDK".

You can install BRM SDK on HP-UX IA64, Solaris, AIX, and Linux operating systems.

Before installing BRM SDK, you must install Third-Party software, which includes the PERL libraries and JRE required for installing BRM components. See "Installing the Third-Party Software" in BRM Installation Guide.

For BRM SDK disk space requirements, see "BRM Software Compatibility" in BRM Installation Guide.


To install BRM SDK, see "Installing BRM SDK" in BRM Installation Guide.

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 you installed BRM components. 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 7-1.

Table 7-1 SDK Directory Structure

Directory Contents


Core and FM libraries, including libportal.so on HP-UX IA64, Solaris, and Linux; and libportal.a on AIX.


CM and DM executables, testnap, perl.exe.


Base BRM header files, including pin_os_dynload.h.


Server system files.


CM source library files.


Top-level directory for source code.


Policy FM source code.


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


FM and DM templates.


Top-level directory for sample code and applications.


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


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


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


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


Sample files for creating multithreaded applications.


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


PCM SDK contains 64-bit PCM libraries that you require to create 64-bit client applications. You must install BRM SDK, which contains the source files, samples, and debug libraries, before you install PCM SDK.

To install PCM SDK, see "Installing PCM SDK" in BRM Installation Guide.

Setting Up Your Development Environment

Your programming tools must be set up to use the BRM SDK libraries. The way you do this depends on which programming languages and tools you use. This document includes environment information for specific languages and customizations.

To view a list of compilers that are supported by BRM SDK, see "BRM Software Compatibility" in BRM Installation Guide.

Testing New or Customized Components

The BRM architecture makes it possible to test new or customized components without having to physically move files. For example, if you want to test a new policy FM, you can include it in a CM that you run locally on your development machine.

For testing, you need access to a test installation of BRM. For best results, the test installation should resemble very closely your production BRM environment. For example, if you use branding or multiple database schemas in your production environment, your test environment should also include these features.

The following sections provide basic instructions for common testing scenarios. Depending on the nature of your customizations and the architecture of your BRM system, these instructions might not fully describe your situation.

Testing Custom Applications

To test an application, connect it to a BRM system via its CM, in the same way you would under production conditions. To establish a connection, the application must specify a valid user name, password, port number, and database number. Depending on how the application is designed, this information can be included in a configuration file (pin.conf for C/C++ applications or Infranet.properties for Java applications) or specified by the user.

Testing New or Customized Policy FMs

To test a new or customized policy FM, you must add it to a CM that you then use with a BRM test installation.

  1. Add the FM to the CM in BRM SDK. See "Adding a New FM Module to the CM Configuration File".

  2. Use that CM in place of the default CM in a test installation of BRM. See "Configuring Your CM to Use the Custom DM".

  3. Use Opcode Workbench or testnap to run the opcodes in the new or customized FM. See "Testing Your Applications and Custom Modules".

    Keep in mind that if the opcodes in the FM require the use of new storable classes or fields, you need to add those classes or fields to the database of the test BRM installation. See "Creating Custom Fields and Storable Classes".

See "Debugging FMs" for information about debugging new or customized policy FMs.

Testing New or Customized DMs

To test a new or customized DM, run a CM locally on your development machine. The CM should connect to the DM that you are testing as well as any other DMs included in the BRM installation. For information about including the new or customized DM in the CM, see "Configuring Your CM to Use the Custom DM".

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.


If you are replacing an existing BRM component, do not overwrite it with your new version. Save the old version under a new name or in a different location so that you can revert to it if necessary.

See the following sections for deployment information about applications, FMs, and DMs.

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 HP-UX IA64, Solaris, and Linux; and .a for AIX).

    See "Compiling and Linking a Policy FM".

  2. For each CM server in the BRM installation:

    1. Stop the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

    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. Stop and restart the CM.

Deploying DMs

The files you need to 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, all you need to move is the compiled .so file as well as 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 need to 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 now 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 7-2 lists the CM build files for use with Purify:

Table 7-2 CM Build Files for Purify

File Location




libcm_main.so (HP-UX IA64, Linux, and Solaris)


Also in:




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.


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


purify cc -o cm cm.cpp -g -lthread -ldl -I ${INFRANET_SDK_HOME}/include 
-L ${INFRANET_SDK_HOME}/sys/lib -lpinsys


purify cc -o cm cm.cpp -g -Wl,+s -ldld -lpthread -I ${INFRANET_SDK_HOME}/include -L ${INFRANET_SDK_HOME}/sys/lib -l:libpinsys.a


purify xlCcore_r -o cm cm.cpp -g -Drs6000 -D__aix -Dunix -D__unix -DFLIST_HEAP -I ${INFRANET_SDK_HOME} -L ${INFRANET_SDK_HOME} -bdynamic -bexpall -brtl -q32 -lpinsys -lcm_main -lnsl_r -lpthread -lptools_ptr -ldl

About Developer Center

Developer Center is a suite of Java-based applications for BRM developers. It includes these applications:

This section provides basic information about Developer Center. Additional information is provided in Developer Center Help.


Developer Center is an optional feature that requires a separate license.

Installing Developer Center

You can choose to install any combination of Developer Center applications, and you can install on both Windows and UNIX systems. For details on the operating systems BRM supports, see "BRM Software Compatibility" in BRM Installation Guide.

To install Developer Center, see the following:


Getting Started with Developer Center

You start Developer Center as you would any other application on your platform. You need to specify a BRM database and port number as well as a login and password for that database.

  1. To start Developer Center, run DevCenter.sh.

  2. In the Connect to section of the Database Connection dialog box, enter a database host name and port number.

  3. In the Identification section, enter your login and password for the specified database.

  4. Click OK.

Using Developer Center Applications

The toolbar at the top of the Developer Center window shows icons for the applications you have installed.

To start a Developer Center application, click its toolbar button or choose the appropriate command from the Tools menu.