4 Using Configuration Files to Connect and Configure Components

This chapter provides an overview of Oracle Communications Billing and Revenue Management (BRM) configuration and properties files, including where to find them and how to edit them.

For information about a specific entry in a configuration file, look directly in the file. Each entry includes a description and guidelines for changing the values.

For information about the optimal values for tuning your BRM system, see "Improving BRM Performance".

About Configuration and Properties Files

The primary purpose of configuration and properties files is to enable the different components of BRM to communicate with each other (see "About Connecting BRM Components"). The configuration and properties files can also include other entries that let you increase performance and implement business policies.

Most BRM components and utilities use configuration files (pin.conf).
BRM Java programs use properties files (usually Infranet.properties).
BRM programs based on Perl scripts read configuration and properties information from a file named pin.conf.pl.

You can use any text editor to edit configuration files.

Important:

Before you edit a configuration file, save a backup copy.

Some configuration files are write-protected. Before editing the file, remove that restriction. After you edit the file, restore the restriction.

Each configuration file includes specific, detailed information about how to edit each configuration entry in that file. To edit an entry, follow the guidelines provided for that entry.

To insert a comment, type a crosshatch (#) followed by the comment. BRM ignores all text on that line.

Configuration Entry Syntax

Any configuration entry that includes an application name, such as Infranet.pricing_tool.log.file, is specific to that application. Any other entry is a shared entry, applying to all applications. Any application-specific entry overrides a shared entry.

Syntax for Configuration Entries

Entries in a configuration file use the following syntax:

host_name     program     keyword     values

where:

host_name is the name or IP address of the computer. To refer to the current computer, use a single hyphen (-). If several computers share the same configuration file, use the name of the current computer. In this case, BRM components, such as the Connection Manager (CM) or the Data Manager (DM), use only the entries that contain the host name on which they are started.
program is the name of the program to which this entry applies. The program can be:
- The name of the application (or custom application) or Facilities Module (FM), such as cm, pin_billd, or fm_bill. Use a specific name when the entry applies only to a single program.
- nap (Network Application Program). Use nap when the entry applies to general BRM applications, which use the PCM_CONNECT and PCM_CONNECT_OPEN functions.
- Blank or a single hyphen (-). The entry applies to any BRM function, such as pin_virtual_time.
keyword is the name of the configuration entry.
values is one or more parameters specific to the configuration entry. Values are separated by spaces.

A single configuration entry resembles the following example:

- cm   userid   0.0.0.1   /service   1

This entry applies to the Connection Manager (cm) on the local computer (-). The entry is called userid, and the three values associated with that entry are 0.0.0.1, /service, and 1.

Note:

Some configuration files have entries with userid and a database number, as shown here. BRM ignores the database number in these entries:

- cm   userid   0.0.0.1   /service   1

Syntax for Facilities Module Entries

The CM configuration file includes entries for Facilities Module (FM) that are linked to the CM at startup. Some of these entries are for the base set of FMs that are part of the standard release; other entries are for optional BRM components. You can also add entries for custom FMs.

Configuration entries for FMs use the following syntax:

- cm fm_module file_name initialization_table initialization_function tag

where:

file_name is the path to the shared library file containing the functions that make up the FM. The file name has the following platform-dependent extensions:
- .so on HP-UX IA64, Oracle Linux, and Oracle Solaris
- .a on AIX
Do not change this parameter unless you change the location of the file.
initialization_table is the name of the configuration structure that maps each opcode to a function. Do not change this text for standard FMs.
initialization_function is either a hyphen (-), meaning that no function is run when the CM is started, or the name of the function to be run at startup. Some FMs call optional initialization functions that you can use to configure the FM.
tag identifies the FM to the CM. Each CM has an equivalent tag as part of the cm_ports configuration entry. Each FM with a matching tag is linked to that CM at startup. The default tag for the base set of FMs is pin. For example, you can use other tags to define separate sets of FMs for multiple CMs on the same computer.

Configuration entries for the base-rating FM resemble the following example:

- cm fm_module ../../lib/fm_rate_pol.so fm_rate_pol_config - pin

The entry shows a policy FM that must always be included with its corresponding base FM.

Caution:

Some FMs depend on others. Never change the order of the base set of FMs in the CM configuration file.

Preparing for Platform Migration by Using Variables in pin.conf Files

You can reference certain system environment variables in pin.conf configuration files. These references can facilitate future migration of the pin.conf files to BRM implementations on other platforms.

For information about environment variables, see "BRM Environment Variables" in BRM Installation Guide.

Table 4-1 shows the environment variables that can be referenced in BRM configuration files (pin.conf):

Table 4-1 BRM Configuration File Environment Variables

Environment Variable	Reference in pin.conf Files
PIN_HOME	${PIN_HOME}
PIN_LOG_DIR	${PIN_LOG_DIR}
LIBRARYEXTENSION	${LIBRARYEXTENSION}
LIBRARYPREFIX	${LIBRARYPREFIX}

Sample pin.conf file with environment variable references:

- - pin_virtual_time ${PIN_HOME}/lib/pin_virtual_time_file
- fm_rate tax_supplier_map ${PIN_HOME}/sys/cm/tax_supplier.map
- cm fm_module ${PIN_HOME}/lib/fm_utils/${LIBRARYEXTENSION} fm_utils_config fm_utils_init pin
- cm fm_module ${PIN_HOME}/lib/fm_delivery/${LIBRARYEXTENSION} fm_delivery_config - pin

Locations of Configuration and Properties Files

Each daemon can have its own configuration file, or two or more can share a configuration file.

File Locations

The default location for a configuration file is the directory where the system process or program runs. Typical locations are:

Directories inside the BRM_home/sys directory (for example, BRM_home/sys/cm/pin.conf).
Directories inside the BRM_home/apps directory (for example, BRM_home/apps/pin_billd/pin.conf).
In the application folder (for example, BRM_home/Application_home/Infranet.properties).

Configuring a Shared pin.conf File

If you run several BRM applications and processes on one computer, they can share a single configuration file. To set up a shared configuration file:

Combine configuration entries for each BRM component into a single pin.conf file.
Save that file to the BRM_home directory.
For each BRM component that uses the shared configuration file, move its specific configuration file to a backup location or rename the file.

When BRM starts any BRM application, component, or process, it searches for the appropriate pin.conf file in the following directories in the order shown:

The current directory.
The system /etc directory.

Note:
The /etc directory is included in the search path for backward compatibility.
If the PIN_HOME environment variable is defined, the BRM_home/config directory.

Note:
If the PIN_HOME environment variable is not defined, BRM skips this part of the search.

Guidelines for Editing Java Properties Files

Java applications get configuration information from Java properties files instead of the pin.conf files that are used for C applications.

The BRM installation program uses information supplied by the installer to write configuration information to the properties files.

Each properties file includes specific, detailed information about how to edit each configuration entry in that file. To edit an entry, follow the guidelines provided with that entry.

You can add comments to properties files to help others understand the purpose of your entries. To insert a comment, type a crosshatch (#) followed by the comment. BRM ignores all text on the same line after the crosshatch.

Common Properties File Entry Syntax

Connection entries, failover entries, and other entries each have their own syntax considerations.

Connection Entry

The connection entry consists of a full URL to the BRM services. It takes one of two forms, depending on the type of login setting:

For the Type 1 login setting, which requires a password, use the following format:

pcp://user_name:password@host_name:port/service_object

where:
- user_name is the login name to use for connecting to BRM.
- password is the password for the specified user name.
- host_name is the name or IP address of the computer running the CM or Connection Manager Master Process (CMMP).
- port is the TCP port number of the CM or CMMP on the host computer. The port number must match the corresponding cm_ports entry in the CM or CMMP configuration file.
- service_object is the service type. The trailing number, ”1,” is the Portal object ID (POID) of the service.
For example:
```
infranet.connection=pcp://root.0.0.0.1:password@hostname:11960/service/admin_client
```
For the Type 0 login setting, which does not require a password, use the following format:

pcp://host_name:port/database_number/service_object

where:
- host_name is the name or IP address of the computer running the CM or Connection Manager Master Process (CMMP).
- port is the TCP port number of the CM or CMMP on the host computer. The port number must match the corresponding cm_ports entry in the CM or CMMP configuration file.
- database_number is the database number assigned to your BRM database when the DM was installed. For example, 0.0.0.1.
- service_object is the service type. The trailing number, ”1,” is the Portal object ID (POID) of the service.
For example:
```
infranet.connection=pcp://hostname:11960/0.0.0.1/service/admin_client
```

Failover Entry

A failover entry refers to an alternate CM host that an application can use to connect to BRM if the main host, specified in the connection entry, is unavailable.

Use the following format:

infranet.failover.1=pcp://host_name:port

where:

host_name is the name or IP address of the computer running the CM or CMMP.
port is the TCP port number of the CM or CMMP on the host computer. The port number must match the corresponding cm_ports entry in the CM or CMMP configuration file.

Note:
user_name, password, and service_object for the alternative hosts are the same as for the main host and are not specified in failover entries.

Other Properties Entries

The flags used in the connection entry of the main Infranet.properties file are used by all the other properties entries, unless they are overridden.

Other entries that override these values for all your Java applications use the following format:

infranet.entry.specific_entries

The Infranet.properties file also contains entries specific to particular Java applications, in the following format:

infranet.application.specific_entries

About Validating XML Configuration Files

After you edit the contents of an XML configuration file, a load utility typically validates the contents against the file's schema definition. If the contents do not conform to the schema definition, either the utility returns an error or the load operation fails.

XML files are not directly linked to their schema definition files. Instead, they are linked to one of the following XSD reference files:

BRM_home/apps/pin_billd/business_configuration.xsd
BRM_home/sys/data/config/business_configuration.xsd

The XSD reference file associates multiple XML files with their schema definition file. Each XML file contains a schema location pointer to the reference file, and the reference file contains a pointer to the XML file's schema definition. Figure 4-1 shows an example.

Figure 4-1 XML File Validation by business_configuration.xsd

Description of ''Figure 4-1 XML File Validation by business_configuration.xsd''

To validate the contents of XML_1, XML_2, or XML_3 in Figure 4-1, business_configuration.xsd is called rather than XSD_1, XSD_2, or XSD_3.

About Connecting BRM Components

To allow BRM components to communicate with each other, you use entries in configuration or properties files. The basic connection entries in the files identify the host names and port numbers of each component.

These connection entries are set when you install BRM and when you install each client application. You can change them if you change your configuration. Depending on how you install BRM, you might have to change some entries to connect BRM components. See "Reconfiguring a BRM Component".

Figure 4-2 shows how entries in configuration files link components.

Figure 4-2 BRM Component Connections

Description of ''Figure 4-2 BRM Component Connections''

In Figure 4-2, the client application is a utility that uses a configuration file entry to point to the CM. (A Java client has a similar entry in its properties file.) The following sample entry includes the CM host name, CM_System, and port number, 11960:

cm_ports    ip    CM_System    11960

The CM configuration file has corresponding entries:

The cm_name entry identifies the host name as CM_System
```
- cm    cm_name    CM_System
```
The cm_ports entry identifies the port number as 11960:
```
- cm    cm_ports    11960    pin
```

The CM configuration file includes an entry that points to the DM. This entry includes the DM host name and port number:

- cm    dm_pointer    0.0.0.1    ip    DM_System    11950

The DM configuration file includes corresponding information:

The dm_name entry identifies the host name as DM_System. This entry is optional: if you remove or disable it, BRM uses gethostname to find the IP address of the DM computer:
```
- dm dm_name DM_System
```
The dm_port entry identifies the port number as 11950:
```
- dm dm_port 11950
```

The DM configuration file specifies the database number, which is in 0.0.n.n / 0 format:

- dm dm_db_no 0.0.0.1 / 0

Queue Manager (QM) components (for example, LDAP Manager) use the same types of configuration entries, but they have different names. For example, instead of dm_max_fe, the entry is named qm_max_fe.

The QM configuration files include the following entry:

The qm_port entry identifies the host address and the port number:
```
- qm_process qm_port host_name port [tag_number]
```
where:
- qm_process is the system process such as dm_ldap, dm_email, dm_fusa, dm_vertex, cm_proxy, and dm_invoice.
- host_name is the host name or the IP address where the system process is deployed.
- port is the port number.
- tag_number is a sequential number that identifies the host_name and port pair. You use this parameter when configuring multiple qm_port entries.

There are additional entries in configuration files, but these entries are the most basic. For more information on connection entries in configuration files, see the comments in the configuration files.

Guidelines for Database and Port-Number Entries

The configuration and properties files specify identifying numbers for databases and DMs. The default numbers, listed in Table 4-2, are systematic to make numbers relatively easy to maintain and extend.

The DM numbers are in the form A.B.C.D. Make the number assignments meaningful as follows:

Use A to separate divisions of your company (use 0 if you have none).
Use B to distinguish different BRM installations (use 0 if you have only one).
Use C to indicate the type of DM. For example:
- 0 for data
- 1 for transaction processing of credit or debit card
- 2 for email
- 3 for taxation
  
  Important:
  Start numbering your custom DMs at 100, such as 0.0.100.1.

Use D to indicate the instance of a particular DM division, installation, or type.

Table 4-2 Database and Port Number Entries

Program	Database Number	Port Number
The database DM (dm_oracle)	0.0.0.1	12950
The second database DM for a multischema system (dm_oracle)	0.0.0.2	12951
Each additional dm_oracle for multischema systems	0.0.0.n	12950 + (n – 1)
Paymentech data manager for credit card, dm_fusa	0.0.1.1	12810
Paymentech data manager for direct debit, dm_fusa	0.0.1.2	12810
Each additional dm_fusa	0.0.1.n (n > 2)	12813+
Email notification manager: dm_email	0.0.2.1	12821
Each additional dm_email	0.0.2.n	12820 + n
Activity Log Data Manager of a BRM satellite: dm_opstore	0.0.4.1	12841
Each additional dm_opstore	0.0.4.n	12840 + n
LDAP: dm_ldap	0.0.5.1	12851
Each additional dm_ldap	0.0.5.n	12850 + n
Wireless Provisioning DM, dm_prov_telco	0.0.10.2	10970
The Connection Manager (CM) or Connection Manager Master Process (CMMP)	NA	11960
Each additional CM or CMMP	NA	11960 + n
System Manager (infmgr)	NA	11981
Node Manager (nmgr)	NA	11991
The Account Synchronization DM, dm_acctsync	0.0.9.9	11999
Credit-card or online-processing batch simulators (answer_b)	NA	5678
Credit-card or online-processing online simulators (answer_s)	NA	5679

Setting Data Manager Attributes

In the CM configuration file, you can set DM attributes (dm_attributes) for each DM to which you connect. For example, set the scoped and assign_account_obj options when you enable branding. You use the dm_attributes entry with these options:

scoped: Enables scoping enforcement. This option is used only when you use branding. It restricts database access for separate brands. You can disable this option if branding is not used. See "Data Scoping" in BRM Developer's Guide.
assign_account_obj: Assigns an owning account reference when the object is created. When you use branding, all objects are associated with an account. You can disable this option if branding is not used. See "Changing the Owner of a Discount Sharing Group" in BRM Managing Accounts Receivable.
searchable: Restricts access to certain database schemas in multischema environments, and indicates that the DM is a database DM. See "Running the pin_multidb.pl Script on the Primary Installation Machine" in BRM Installation Guide.

This example specifies a DM pointer in the CM pin.conf file:

- cm    dm_pointer       0.0.0.1 ip 156.151.2.168        33950  # dm_oracle
- cm    dm_attributes    0.0.0.1 scoped,assign_account_obj,searchable
- cm    dm_pointer       0.0.0.2 ip 156.151.2.168        34950  # dm_oracle
- cm    dm_attributes    0.0.0.2 scoped,assign_account_obj,searchable

Connecting a Data Manager to the BRM Database

Use the following DM pin.conf file entries in Table 4-3 to connect a DM to the BRM database. These entries are used by multiple DMs, such as DM Oracle and the Account Synchronization DM.

Table 4-3 DM pin.conf File Entries

Entry	Description
sm_database	Specifies the database alias name. For example, for Oracle Database this is the SQL*NET alias defined in the tnsnames.ora file. This entry was configured when you installed BRM, so you do not have to change it. Note: If you have multiple database hosts, such as an Oracle Parallel Server configuration, include a separate sm_database configuration entry for each host.
sm_id	Specifies the database user name that the DM uses to log in to the BRM database. This entry was configured when you installed BRM, but you can change it.

Entry

Description

sm_database

Specifies the database alias name. For example, for Oracle Database this is the SQL*NET alias defined in the tnsnames.ora file. This entry was configured when you installed BRM, so you do not have to change it.

Note: If you have multiple database hosts, such as an Oracle Parallel Server configuration, include a separate sm_database configuration entry for each host.

sm_id

Specifies the database user name that the DM uses to log in to the BRM database. This entry was configured when you installed BRM, but you can change it.

Creating Configuration Files for BRM Utilities

Some BRM utilities, such as load_tax_supplier, require you to create a configuration file to tell the utility how to connect to the BRM system. The configuration file must be in the same directory as the utility executable file.

To create a configuration file for a utility:

Copy the sample configuration file in BRM_home/source/apps/sample.

Use this file, which contains all of the configuration entries needed for connecting to BRM, as a template for any utility configuration file.
Edit the configuration entries to reflect your BRM environment. Follow the guidelines in the configuration file.
Save the file as pin.conf in the directory with the utility executable file.

Table 4-4 shows the common utility pin.conf entries:

Table 4-4 Common Utility pin.conf Entries

Entry	Description
cm_ports	Specifies a pointer to the CM or CMMP. Use a separate entry for each CM or CMMP. Each entry includes three values: protocol: ip host_name: the name or IP address of the computer running the CM or CMMP port: the port number of the CM or CMMP on this computer The port number should match a corresponding cm_ports entry with the same port number in the CM or CMMP configuration file. The default, 11960, is a commonly specified port for the CM or CMMP. See "About Connecting BRM Components".
login_name	Specifies the login name to use when connecting to the CM.
login_pw	Specifies the password to use when connecting to the CM.
login_type	Specifies if the application requires a login name and password to connect to BRM.
userid	Specifies the database number and service type for the BRM database. The CM uses the database number to identify the BRM database and to connect to the correct DM. For connections that do not require a login name and password, the CM also passes the service type to the database. The database number, in the form 0.0.0.n, is the number assigned to your BRM database when you installed the system. The default is 0.0.0.1.

In addition, the pin.conf entries in Table 4-5 are used by multithreaded application (MTA) utilities:

Table 4-5 MTA Utilities pin.conf Entries

Entry	Description
children	Specifies the number of worker threads spawned to perform the specified work. The default is 5. Important: This entry is mandatory. For more information, see the following sections: Tuning the Number of Children for Billing Utilities Setting the Number of Children for Invoice Utilities Controlling Thread Load on Your Multithreaded Application
fetch_size	Specifies the number of objects received from the database in a block and cached in system memory for processing. The default is 5000. Important: This entry is mandatory. See the following sections: Tuning the Account Cache Size for Billing Utilities (fetch_size) Tuning the Account Cache Size for Invoice Utilities (fetch_size)
hotlist	Specifies the name for the hotlist file. This parameter is available for backward compatibility.
logfile	Specifies the file name used to log errors. Important: This entry is mandatory. See "Changing the Name or Location of a Log File".
loglevel	Error reporting level. 0: no logging 1: (Default) log error messages only 2: log error messages and warnings 3: log error, warning, and debugging messages See "Setting the Reporting Level for Logging Messages".
loop_forever	Specifies whether the iterative step search for account information in the BRM database continues in a loop when the number of objects returned by a search step is 0: 0: stop the iterative step search. 1: continue the iterative step search. Use the loop_forever entry if the application times out before a search is complete. The default is 0.
max_errs	Specifies the maximum number of errors allowed in the application. The application stops when the number of errors exceeds this number. The default is 1.
max_time	Specifies the maximum time, measured from application start time, for job processing before the application exits. The default is 0, for infinite time.
monitor	Specifies the file used by the pin_mta_monitor utility. The default is monitor. Important: The file specified is for system use only and should not be deleted or modified.
multi_db	A flag that determines whether the application works with a BRM multischema system. The default is 0. For information, see "Using Multithreaded Applications with Multiple Database Schemas" in BRM Developer's Guide.
per_batch	Specifies the number of objects processed by each worker thread in batch mode. The default is 500. Important: This entry is mandatory. See "Tuning the Batch Size for Billing Utilities (per_batch)".
per_step	Specifies the number of objects returned by each search step. The default is 1000. Important: This entry is mandatory. See "Setting the Batch Size for Invoice Utilities (per_step)".
pin_virtual_time	Enables pin_virtual_time to advance BRM time. See "pin_virtual_time" in BRM Developer's Guide.
respawn_threads	Re-spawns worker threads if they exit due to an error. Threads are re-spawned if necessary after every search cycle. The default is 0, for no re-spawning.
retry_mta_srch	The number of retry attempts for main search execution in case of search error. The default is 0, for no retry.
return_worker_error	Specifies whether to return an error code when any thread encounters an error: 0 specifies to not return an error code. 1 specifies to return an error code. The default is 0.
sleep_interval	Specifies the time in seconds before the iterative step search for account information in the BRM database is resumed within a loop. The default is 60.

Reconfiguring a BRM Component

Each BRM component—CMs, DMs, and applications—gets configuration information from its configuration file, which the component reads when it starts. Changes you make to a configuration file take effect the next time you start the program.

Important:

Most configuration file entries require that you restart the CM, but some do not. For information about restart requirements, see "Business Logic pin.conf Reference" and "System Administration pin.conf Reference".

To reconfigure a BRM component:

Edit and save the configuration file (pin.conf) for the component. See "Locations of Configuration and Properties Files" and "About Configuration and Properties Files".
If required, stop and restart the component. See "Starting and Stopping the BRM System".

Running Non-MTA Utilities in Multischema Systems

Utilities built on the MTA framework can perform global searches across all database schemas in a multischema system when configured to do so. See "Using Multithreaded Applications with Multiple Database Schemas" in BRM Developer's Guide.

The following non-MTA utilities, however, can connect to only one CM and its associated schema at a time:

pin_clean (see "pin_clean" in BRM Configuring and Collecting Payments)
pin_deposit (see "pin_deposit" in BRM Configuring and Collecting Payments)
pin_ledger_report (see "pin_ledger_report" in BRM Collecting General Ledger Data)
pin_mass_refund (see "pin_mass_refund" in BRM Managing Accounts Receivable)
pin_recover (see "pin_recover" in BRM Configuring and Collecting Payments)
pin_refund (see "pin_refund" in BRM Managing Accounts Receivable)
pin_config_distribution

To run non-MTA utilities in your multischema system, you must have a CM for each schema in the system. You then connect and run the utility against each CM and schema pair. For example, to run a non-MTA utility on a multischema system:

Connect the utility to the primary CM and run the utility against the primary schema.
Connect the utility to a secondary CM and run the utility against its associated secondary schema.
Connect the utility to another secondary CM and run the utility against its associated secondary schema.

To run a non-MTA utility in a multischema system:

Connect the utility to the primary CM:

On the primary CM machine, open the BRM_home/apps/pin_billd/pin.conf file in a text editor.

Edit the following entries:

- nap   cm_ports   ip    PrimaryHost   PrimaryPort
- nap   login_name       PrimaryLoginName
- nap   login_pw         PrimaryLoginPassword
- nap   login_type       LoginType
- -     user_id          0.0.0.x /service/pcm_client 1

Save and close the file.

On the primary CM machine, go to the BRM_home/apps/pin_billd directory and run the utility.

Connect the utility to a secondary CM:

On the secondary CM machine, go to the BRM_home/apps/pin_billd directory and open the pin.conf file in a text editor.

Edit the following entries:

- nap   cm_ports   ip    SecondaryHost   SecondaryPort
- nap   login_name       SecondaryLoginName
- nap   login_pw         SecondaryLoginPassword
- nap   login_type       LoginType
- -     user_id          0.0.0.x /service/pcm_client 1

Save and close the file.

On the secondary CM machine, go to the BRM_home/apps/pin_billd directory and run the utility.
Repeat steps 3 and 4 for each remaining secondary schema in your system.

Configuring BRM by Using the pin_bus_params Utility

As part of the BRM installation, a standard group of /config/business_params objects is added to the BRM database. These objects contain all the business parameters normally used by BRM. In their default state, these parameters typically disable optional features and direct BRM to use behaviors optimal for most users. However, your business might require optional features or alternative BRM behaviors. Or you might want to add business parameters or parameter classes that are not part of BRM.

If so, use the pin_bus_params utility to perform those tasks. This utility has the following capabilities:

Retrieving: Use the utility to retrieve the contents of an existing /config/business_params object in your BRM installation and translate it into an XML file that you can edit.
Loading: Use the utility to load the contents of an XML file that contains business parameters into an existing /config/business_params object or to create entirely new objects.

You can use the XML file created during retrieval to add new parameters for existing classes or to create an entirely new class of parameters. When you use the utility to load the XML file into the /config/business_params object, BRM adds the new parameters to your parameter configuration, and these parameters can be called from custom code. For information on adding new parameters and classes, see "Using /config/business_params Objects" in BRM Developer's Guide.

Retrieving /config/business_params Objects

When you retrieve a /config/business_params object with pin_bus_params, you use the -r parameter. To retrieve the object, use the following command:

pin_bus_params [-h] -r ParameterClassTag bus_params_ParameterClassName.xml

This command retrieves the /config/business_params object for the specified class into the specified XML file. Consider the following when retrieving business parameters:

To retrieve a specific parameter, you must know which parameter class it belongs to. The resulting XML file for each class is short so you can quickly locate specific parameters within the class.
Because you retrieve one parameter class at a time, you can edit parameters for a single parameter class without affecting any other parameter classes. BRM overwrites only the /config/business_params object whose parameter class appears in the resulting XML file, so the overall BRM business parameter configuration remains stable.
To update more than one parameter class, you must perform multiple retrievals and loads, one for each class.
You can create a library of class-based business parameter files and individually reload modified versions of these files only when needed.

Loading /config/business_params Objects

To load parameters into /config/business_params objects, use the following command:

pin_bus_params [-h] bus_params_ParameterClassName.xml

This command finds the /config/business_params object for the parameter class in the XML file and overwrites the object with the new parameters.