This chapter provides instructions for Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) post-installation tasks. You must install ECE before following these procedures. See "Installing Elastic Charging Engine".
If you are upgrading ECE 11.3 or an ECE 11.3 patch set, see the following for information on post-installation tasks:
After installing ECE, you must perform certain tasks. Some tasks you only need to perform for an ECE integrated installation. See the following topics for the post-installation tasks:
This section describes the post-installation tasks you must perform that are common to all ECE installations.
The driver machine is the machine on which you installed ECE, and it is the machine used to administer the ECE system. You specify the driver machine properties in the ece.properties file.
If you installed an ECE standalone installation, you must add an entry to the properties file that specifies that Oracle Communications Billing and Revenue Management (BRM) is not installed; if you do not, ECE tries to load BRM update events and cannot transition into a usage processing state.
To specify the ECE driver machine properties:
Open the ECE_home/oceceserver/config/ece.properties file.
Note:
(Linux) If you used the ece_provision script to provision your environment for an ECE installation, verify that the rootDir, user, and driverIP parameters match the corresponding parameters that you defined in the ece_provision_config.sh script.Specify the driver machine:
For a standalone installation, set the driverIP parameter either to localhost or to the explicit IP address or hostname of the machine. For example:
driverIP = localhost
For an ECE system that has more than one machine, set driverIP to the explicit IP address value of the driver machine.
(ECE standalone installation) Specify that BRM is not installed by adding the following entry:
java.property.skipBackLogProcessing=true
For an ECE system that has more than one machine, specify that configuration settings of a secondary machine should not be loaded into the driver machine by adding the following entry:
loadConfigSettings = false
Save and close the file.
You specify server machine properties to configure your ECE topology and tune the nodes in the cluster for garbage collection and heap size.
When you configure your ECE topology, you specify the ECE nodes in the cluster. This includes the physical host machines, or server machines, on which to deploy ECE nodes and the nodes themselves. Each server machine is a part of the Coherence cluster.
For an ECE standalone installation, you can accept all default values in the topology file if desired. You can add any number of charging server nodes (nodes that have the role server specified) and modify or delete existing charging server nodes. You must have at least one charging server node.
Note:
The topology file is pre-configured with several nodes that are required by ECE. Do not delete existing rows in this file.To specify server machine properties:
Open the ECE_home/oceceserver/config/eceTopology.conf file.
Add a row for each Coherence node for each physical host computer (server machine) in the cluster.
For example, if you have three physical server machines and each physical server machine has three nodes, you require nine rows.
For each row, enter the following information:
Name of the JVM process for that node.
You can assign an arbitrary name. This name is used to distinguish processes that have the same role.
Role of the JVM process for that node.
Each node in the ECE cluster plays a certain role.
Host name of the physical server machine on which the node resides.
For a standalone system, enter localhost.
A standalone system means that all ECE-related processes are running on a single physical server machine.
(For multihomed hosts) IP address of the server machine on which the node resides.
For those hosts that have multiple IP addresses, enter the IP address so that Coherence can be pointed to a port.
Whether you want the node to be JMX-management enabled.
The JVM tuning file that contains the tuning profile for that node.
(For Diameter Gateway nodes) For one Diameter Gateway node, specify a JMX port.
Choose a port number that is not in use by another application.
By specifying a JMX port number for one Diameter Gateway node, you expose MBeans for setting performance-related properties and collecting statistics for all Diameter Gateway node processes.
(For SDK sample programs) To run the SDK sample programs by using the sdkCustomerLoader, uncomment the line where the sdkCustomerLoader node is defined.
Save the file.
You must specify the JVM tuning parameters (the number of threads, memory, and heap size) for each Coherence node that you specified in the eceTopology.conf file by editing or creating the JVM tuning file(s).
Open the ECE_home/oceceserver/config/defaultTuningProfile.properties file.
You can create your own JVM tuning file and save it in this directory. You can name the file what you want.
Set the parameters as needed.
Save the file.
In the topology file (ECE_home/oceceserver/config/eceTopology.conf), ensure your JVM tuning file is associated with the node to which you want the tuning profile (as set by these parameters) to apply.
The JVM tuning file is referenced by name in the topology file as mentioned earlier in this procedure.
After installing ECE, you may reset system configurations, such as connection parameters for connecting to other applications, and set business configurations, such as charging-related rules you want to apply at run time. To set most configuration parameters, you use a JMX editor such as JConsole. Before you can use a JMX editor to set configuration parameters, you must expose ECE MBeans. You expose ECE MBeans by enabling one ECE node for JMX management for each unique IP address in your topology. When a JMX-management-enabled node starts, it provides a JMX management service on the specified host and port which is used to expose the ECE configuration MBeans.
Though any ECE node can be enabled for JMX management, you enable charging-server nodes for JMX management to support central configuration of the ECE system. Charging-server nodes are always running, and enabling them for JMX management exposes MBeans for all ECE node processes (such as Diameter Gateway node instances, simulators, and data loaders).
To enable a charging server node for JMX management:
Open the ECE_home/oceceserver/config/eceTopology.conf file.
For each physical server machine or unique IP address in the cluster, provide the following information for one charging server node (node with role server):
JMX port of the JVM process for that node.
Enter any free port, such as 9999, for the charging server node to be the JMX-management enabled node.
Choose a port number that is not in use by another application.
The default port number is 9999.
Specify that you want the node to be JMX-management enabled by entering true in the start CohMgt column.
For charging server nodes (nodes with the role server), always enable JMX-management for the node for which a JMX port is supplied.
Enable only one charging server node per physical server for JMX management.
Because multiple charging server nodes are running on a single physical machine, you set CohMgt=true for only one charging server node on each physical machine. Each machine must have one charging server node with CohMgt=true for centralized configuration of ECE to work.
Save the file.
This section describes how to configure ECE for multicast or unicast. Oracle Coherence uses the TCMP protocol, which can use the UDP/IP multicast or UDP/IP unicast methods of data transmission over the network. See the discussion about network protocols in Oracle Coherence Getting Started Guide for detailed information about how Oracle Coherence uses the TCMP protocol.
When ECE is deployed in a distributed environment (multiple machines), it uses multicast or unicast for discovering other nodes when forming a cluster; for example, for allowing an newly started node to discover a pre-existing cluster. Multicast is preferred because it allows packets to be sent only one time rather than sending one packet for each node. Multicast can be used only if it is enabled in the operating system and the network.
To configure ECE for multicast or unicast, see the following topics:
To test that multicast is enabled in the operating system, see "Determining Whether Multicast Is Enabled".
To configure ECE when using multicast, see "Configuring ECE for Multicast".
To configure ECE when not using multicast, see "Configuring ECE for Unicast".
To determine whether multicast is enabled in the operating system, use the Oracle Coherence multicast test utility. See the discussion about performing a multicast connectivity test in Oracle Coherence Administrator's Guide for detailed information about using the multicast test utility and how to understand the output of the test:
http://docs.oracle.com/cd/E18686_01/coh.37/e18679/tune_multigramtest.htm
To determine whether multicast is enabled in the operating system, go to the directory where the multicast-test.sh script is located and use the following test.
Note:
If you used the ece_provision script, run the test from your UNIX home directory in /opt/coherence/bin.$ ./multicast-test.sh -ttl 0
You can use the following tests to determine if multicast is enabled in the network. Start the test on Machine A and Machine B by entering the following command into the respective command window of each and pressing ENTER:
Machine A $ ./multicast-test.sh -ttl 1 Machine B $ ./multicast-test.sh -ttl 1
If multicast across Machine A and Machine B is not working with a TTL (time to live) setting of 1, repeat this test with the default TTL setting of 4. A TTL setting of 4 is required when the machines are not on the same subnet. If all participating machines are connected to the same switch, and therefore in the same subnet, use the TTL setting of 1.
If Machine A and Machine B both have multicast enabled in the environment, the test output for each machine will show the machine issuing multicast packets and seeing both its own packets as well as the packets of the other machine. This indicates that multicast is functioning properly between the machines.
To configure ECE when using multicast:
Verify the TTL value you must use in your environment.
Open the ECE Coherence override file your ECE system uses (for example, ECE_home/oceceserver/config/charging-coherence-override-prod.xml).
To confirm which ECE Coherence override file is used, refer to the tangosol.coherence.override parameter of the ECE_home/oceceserver/config/ece.properties file.
Tip:
When using multicast, using charging-coherence-override-prod.xml enables multicast across multiple computers within a single sub-network.In the multicast-listener section, update the tangosol.coherence.ttl parameter to match the TTL value you must use in your environment.
For example, to set a TTL value of 4:
<multicast-listener> <address system-property="tangosol.coherence.clusteraddress">ip_address</address> <port system-property="tangosol.coherence.clusterport">port</port> <time-to-live system-property="tangosol.coherence.ttl">4</time-to-live> </multicast-listener>
Note:
You can segregate multiple ECE clusters within the same subnet by assigning distinct tangosol.coherence.clusteraddress values for each cluster.Save the file.
If multicast is not used, you must set up the Well Known Addresses (WKA) mechanism for your ECE cluster. Configuring a list of well known addresses prevents Coherence from using multicast.
To configure ECE when not using multicast:
Open the ECE Coherence override file your ECE system uses (for example, ECE_home/oceceserver/config/charging-coherence-override-prod.xml).
To confirm which ECE Coherence override file is used, refer to the tangosol.coherence.override parameter of the ECE_home/oceceserver/config/ece.properties file.
Comment out the multicast-listener section.
Add the following unicast-listener section to the file:
<unicast-listener>
<well-known-addresses>
<socket-address id="id">
<address system-propety="tangosol.coherence.wka">ip_address</address>
<port system-property="tangosol.coherence.wka.port">port</port>
</socket-address>
...
</well-known-addresses>
<port system-property="tangosol.coherence.localport">port</port>
</unicast-listener>
where:
id is the ID for a particular cluster member
"tangosol.coherence.wka" must refer to the machine that runs the first Elastic Charging Server node (the ecs1 charging server node).
ip_address is the IP address of the cluster member
port is the value specified in the member's unicast listener port
Save the file.
During ECE installation, if you specified that Diameter Gateway must be started when ECE is started, the ECE Installer creates a single instance (node) of Diameter Gateway (diameterGateway1) that is added to your topology. By default, this instance listens to all network interfaces for Diameter messages.
For a standalone installation, a single node is sufficient for basic testing directly after installation; for example, to test if the Diameter client can send a Diameter request to the Diameter Gateway node. Add additional Diameter Gateway nodes to your topology, configure them to listen on the different network interfaces in your environment, and perform performance testing. For information on adding and configuring Diameter Gateway nodes, see BRM Elastic Charging Engine System Administrator's Guide.
Important:
When configuring additional Diameter Gateway nodes, ensure that you configure the Diameter peers and alternative peers for routing notifications. See the discussion about configuring alternative Diameter peers for notifications in BRM Elastic Charging Engine Implementation Guide for more information.During ECE installation, if you specified that RADIUS Gateway must be started when ECE is started, the ECE Installer creates a single instance (node) of RADIUS Gateway (radiusGateway1) that is added to your topology. By default, this instance listens to RADIUS messages.
For a standalone installation, a single node is sufficient for basic testing directly after installation; for example, to test if the RADIUS client can send a RADIUS request to the RADIUS Gateway node. Add additional RADIUS Gateway nodes to your topology and configure them to listen on the different network interfaces in your environment. For information on adding and configuring RADIUS Gateway nodes, see BRM Elastic Charging Engine System Administrator's Guide.
During rating, ECE uses the subscriber's primary currency or the secondary currency for charging subscribers. If the currency used in the rate plans does not match the subscriber's primary or secondary currency, ECE uses the default system currency, US dollars.
For more information, see the discussion about configuring default system currency in BRM Elastic Charging Engine System Administrator's Guide.
To identify and process external notifications, you must configure a header for each external notification. See the discussion about configuring headers for external notifications in BRM Elastic Charging Engine Implementation Guide for more information.
If you installed an ECE standalone installation on a single machine only, you can skip this task.
If your ECE cluster includes multiple physical server machines, you run the ECE sync command to deploy ECE from the driver machine onto the server machines in the cluster.
Deploying ECE onto the server machines (in your distributed environment) means that you distribute the Elastic Charging Server node instances (charging server nodes) and other nodes defined in your topology file across the server machines.
Tip:
For the sync command to work as expected, all the hosts included in the eceTopology.conf file must have the same login ID (user ID) and from the driver machine password-less SSH must be configured to all hosts.To deploy ECE onto server machines:
Log on to the driver machine.
Change directory to the ECE_home/oceceserver/bin directory:
Start Elastic Charging Controller (ECC):
./ecc
Deploy the ECE installation onto server machines:
sync
The sync command copies the relevant files of the ECE installation onto the server machines you have defined to be part of the ECE cluster.
For an ECE integrated installation, you perform the post-installation tasks common to all ECE installations and also the tasks described in this section. See "Post-Installation Tasks Common to All ECE Installations" for information on common post-installation tasks.
For an integrated installation, after you install ECE, you must do the following:
Create the following required queues for BRM and Pricing Design Center (PDC):
Suspense queue
See the BRM Elastic Charging Engine System Administrator's Guide for the discussion on configuring the suspense queue and troubleshooting update request failures.
Acknowledgement queue
See the discussion about implementing ECE with BRM in BRM Elastic Charging Engine Implementation Guide for information about the acknowledgement queue.
ECE notification queue (JMS topic)
Set up an ECE notification queue on a server running Oracle WebLogic Server where ECE can publish notification events for consumption by external systems, such as Oracle Communications Offline Mediation Controller. The ECE notification queue is a JMS topic; it can be on the same WebLogic server as the JMS queue where PDC publishes pricing updates.
See the discussion in the Oracle WebLogic Server documentation for information about setting up JMS queues.
If you set up multiple JMS WebLogic servers for failover, you must enter their connection information in the ECE_home/oceceserver/config/JMSConfiguration.xml file. See "Configuring Credentials for Multiple JMS WebLogic Servers."
See the discussion about configuring notifications for charging in BRM Elastic Charging Engine Implementation Guide for more information about configuring the ECE notification queue.
For instructions on creating these queues, see "Creating Required Queues for BRM".
Install and configure your network mediation software. For example:
If you use Diameter Gateway as your network integration for online charging, ensure that you have added and configured Diameter Gateway nodes to listen on the different network interfaces in your environment. See "Adding and Configuring Diameter Gateway Nodes for Online Charging" for more information.
If you use Offline Mediation Controller as network mediation software for offline charging, see Oracle Communications Offline Mediation Controller Elastic Charging Engine Cartridge Pack User Guide for instructions on installing and configuring Offline Mediation Controller to access ECE SDK libraries and send usage requests for offline CDRs.
Enable secure communication between components in the ECE integrated installation. See the following topics for more information:
Use the post_Install.pl script to create the required BRM queues: suspense queue, acknowledgement queue, and JMS notification queue.
ECE_home/oceceserver/post_installation/
perl post_Install.pl
You are prompted to install the BRM suspense and acknowledgement queues and the JMS notification queue. You can choose to install one, two, or all the queues.
The queue names are specified during the ECE installation process and are used by the post installation script.
If queues are already created, you see a message in the log files. Alternatively, you can check if the BRM queues exist by querying the user_queues table on your BRM machine. If the suspense and acknowledgement queues are already created, a note will be logged in brm_queue.log. If the JMS notification queue is already created, a note will be logged in output.log.
For the BRM suspense and acknowledgement queues, you also need to enter the BRM machine password in addition to entering the following parameters:
BRM_HOSTNAME: The IP address or the host name of the computer on which the BRM database is configured.
BRM_USER: The BRM database schema user name.
BRM_DB_PASSWORD: The password for the BRM database user.
For the JMS ECE notification queue, you enter the following WebLogic server parameters:
JMS_PASSWORD: The password for logging on to the WebLogic server on which the JMS queue resides.
JMS _MODULE NAME: The JMS system module name of the module that has already been created on the WebLogic server.
JMS_SUBDEPLOYMENT: The name of the subdeployment target in the JMS system module that has already been created on the WebLogic server.
After the JMS ECE notification queue is created, do the following in the WebLogic server:
Log on to the WebLogic Server on which the JMS topic for the ECE notification queue resides.
In the WebLogic Server Administration Console, from the JMS modules list, select the connection factory that applies to the JMS topic.
In the Client tab, do the following:
Set Reconnect Policy to None.
Set Client ID Policy to Unrestricted.
Set Subscription Sharing Policy to shareable.
In the Transactions tab, set Transaction Timeout to 2147483647.
The ECE installer gathers connection information for only one JMS WebLogic server on which the ECE notification queue (JMS topic) is to reside (see "ECE Notification Queue Details."). If your ECE system includes multiple ECE notification queue hosts for failover, you must specify connection information for all the hosts.
To configure credentials for multiple JMS WebLogic servers:
Open the ECE_home/oceceserver/config/JMSConfiguration.xml file.
Locate the <MessagesConfigurations> section.
Specify values for the parameters in the following JMSDestination name sections:
NotificationQueue: Read by the ECE charging nodes.
BRMGatewayNotificationQueue: Read by BRM Gateway.
DiameterGatewayNotificationQueue: Read by Diameter Gateway.
Note:
Do not change the value of the JMSDestination name parameter.Each JMSDestination name section contains the following parameters:
HostName: If you provided a value for the Host Name field on the ECE Notification Queue Details installer screen, that value appears here. Add this host to the ConnectionURL parameter, which takes precedence over HostName.
Port: If you provided a value for the Port Number field on the ECE Notification Queue Details installer screen, that value appears here. Add this port number to the ConnectionURL parameter, which takes precedence over Port.
Protocol: Specify the wire protocol used by your WebLogic servers in the ConnectionURL parameter, which takes precedence over Protocol.
ConnectionURL: List all the URLs that applications can use to connect to the JMS WebLogic servers on which your ECE notification queue (JMS topic) or queues reside.
Note:
When this parameter contains values, it takes precedence over the deprecated HostName, Port, and Protocol parameters.Use the following URL syntax:
[t3|t3s|http|https|iiop|iiops]://address[,address]. . .
where:
– t3, t3s, http, https, iiop, or iiops is the wire protocol used.
For a WebLogic server, use t3.
– address is hostlist:portlist.
– hostlist is hostname[,hostname.]
– hostname is the name of a WebLogic server on which a JMS topic resides.
– portlist is portrange[+portrange.]
– portrange is port[-port.]
– port is the port number on which the WebLogic server resides.
Examples:
t3://hostA:7001 t3://hostA,hostB:7001-7002
The preceding URL is equivalent to all the following URLs:
t3://hostA,hostB:7001+7002 t3://hostA:7001-7002,hostB:7001-7002 t3://hostA:7001+7002,hostB:7001+7002 t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002
Note:
If multiple URLs are specified for a high-availability configuration, an application randomly selects one URL and then tries the others until one succeeds.ConnectionRetryCount: Specify the number of times a connection is retried after it fails.
This applies only to clients that receive notifications from BRM.
ConnectionRetrySleepInterval: Specify the number of milliseconds between connection retry attempts.
(Optional) Modify the values of the following parameters in the JMSDestination name section:
UserName: Specify the user for logging on to the WebLogic server.
This user must have write privileges for the JMS topic.
Password: Specify the password for logging on to the WebLogic server.
When you install ECE, the password you enter is encrypted and stored in the keystore. If you change the password, you must run a utility to encrypt the new password before entering it here. See the discussion about encrypting new passwords in BRM Elastic Charging Engine System Administrator's Guide.
ConnectionFactory: Specify the connection factory used to create connections to the JMS topic on the WebLogic server to which ECE publishes notification events.
You must also configure settings in Oracle WebLogic Server for the connection factory. See the discussion about configuring a WebLogic Server connection factory for a JMS topic in BRM Elastic Charging Engine Implementation Guide for more information.
QueueName: Specify the JMS topic that holds the published external notification messages.
InitialContextFactory: Specify the name of the initial connection factory used to create connections to the JMS topic queue on each WebLogic server to which ECE will publish notification events.
RequestTimeOut: Specify the number of milliseconds in which requests to the WebLogic server must be completed before the operation times out.
KeyStorePassword: If SSL is used to secure the ECE JMS queue connection, specify the password used to access the SSL keystore file.
KeyStoreLocation: If SSL is used to secure the ECE JMS queue connection, specify the full path to the SSL keystore file.
Save and close the file.
To generate Java keystore certificates for connecting to the Weblogic server, PDC, and BRM:
Log on to the driver machine.
Go to the Java_home/bin directory, where Java_home is the directory in which you installed the latest supported Java version.
Run the following commands:
keytool -genkey -alias weblogic -dname CN=commonName OU=organizationalunit o=organization c=countryname -keyalg RSA -keypass mykeypass -keystore mykeystore -storepass mystorepass -validity valdays keytool -genkey -alias pdc -dname CN=commonname OU=organizationalunit o=organization c=countryname -keyalg RSA -keypass mykeypass -keystore mykeystore -storepass mystorepass -validity valdays keytool -genkey -alias brm -dname CN=commonname OU=organizationalunit o=organization c=countryname-keyalg RSA -keypass mykeypass -keystore mykeystore -storepass mystorepass -validity valdays
where:
commonName is the first and last name.
Organizationalunit is the container within a domain which can hold users, groups, and computers.
Organization is the name of the organization.
countryname is the name of the country.
mykeypass is the key password for the certificate.
mykeystore is the keystore.
mystorepass is the keystore password.
valdays is the number of days that the keystore is valid.
The Java keystore certificates for the Weblogic server, PDC, and BRM are generated.
To export the Java keystore certificates to a file:
Log on to the driver machine.
Go to the Java_home/bin directory, where Java_home is the directory in which you installed the latest supported Java version.
Run the following commands:
keytool -export -alias weblogic -keystore mykeystore -storepass mystorepass -rfc -file certificatename keytool -export -alias pdc -keystore mykeystore -storepass mystorepass -rfc -file certificatename keytool -export -alias brm -keystore mykeystore -storepass mystorepass -rfc -file certificatename
where:
certificatename is the name of the file to store the Java keystore certificates for connecting to the Weblogic server, PDC, and BRM.
mykeystore is the keystore.
mystorepass is the keystore password.
The Java keystore certificates for the Weblogic server, PDC, and BRM are exported to the certificate file; for example, public-admin.cer.
To import the Java keystore certificates into the default Java keystore:
Log on to the driver machine.
Go to the Java_home/bin directory, where Java_home is the directory in which you installed the latest supported Java version.
Run the following commands:
keytool -import -alias weblogic -keystore Java_home/jre/lib/security/cacerts -storepass mystorepass -file certificatename -noprompt rm mykeystore certificatename keytool -import -alias pdc -keystore Java_home/jre/lib/security/cacerts -storepass mystorepass -file certificatename -noprompt rm mykeystore certificatename keytool -import -alias brm -keystore Java_home/jre/lib/security/cacerts -storepass mystorepass -file certificatename -noprompt rm mykeystore certificatename
where:
certificatename is the name of the certificate file in which the Java keystore certificates for connecting to the Weblogic server, PDC, and BRM are stored.
mykeystore is the keystore.
mystorepass is the keystore password.
The Java keystore certificates are imported into the default Java ketstore.
For a standalone installation, verify the installation. See "Verifying the ECE Installation" for instructions.
For an integrated installation, you are ready to implement ECE with the required software products in the charging system. See BRM Elastic Charging Engine Implementation Guide for complete instructions.