| Oracle® Communications Billing and Revenue Management Installation Guide Release 7.5 Part Number E16706-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Billing and Revenue Management Installation Guide Release 7.5 Part Number E16706-06 |
|
|
PDF · Mobi · ePub |
This chapter describes how to install and configure the Oracle Communications Billing and Revenue Management (BRM) Account Synchronization Data Manager (DM). Anyone who installs, configures, or administers Account Synchronization DM should read this document.
Before installing Account Synchronization DM, you should be familiar with how a BRM wireless system works and Account Synchronization DM. See:
The description of integrating wireless services in BRM Telco Integration.
The overview of installing wireless services in BRM Telco Integration.
Before setting up Account Synchronization, you should be familiar with BRM concepts and architecture. See BRM Concepts.
Important:
Account Synchronization DM is an optional feature that requires a separate license.Account Synchronization DM is available for the Solaris, Linux, and AIX operating systems.
Before installing Account Synchronization DM, you must install:
Oracle 10g, or Oracle 11g.
Third-Party software, which includes the PERL libraries and JRE required for installing BRM components.
BRM.
(Multidatabase systems only) Multidatabase Manager.
Account Synchronization DM software includes Connection Manager (CM), DM, and EAI Java server features. When you install Account Synchronization, you can install all features on the same machine (typical install) or install them individually on the same or different machines (custom install).
When you install Account Synchronization DM, the installation program updates your BRM_Home/setup/pin_setup.values files with information about the Account Synchronization component.
Account Synchronization DM installation features:
Account Synchronization CM
The Account Synchronization CM is a CM module that contains the EAI framework Facilities Module (FM) and the Account Synchronization FMs.
Important:
The Account Synchronization CM is dependent on the CM and must be installed on all hosts on which the CM will run.Account Synchronization DM
The Account Synchronization DM (dm_ifw_sync) contains files to start and stop the Account Synchronization DM and perform other Account Synchronization DM functions. This component has no dependencies.
Account Synchronization EAI Java server
This Java server contains the files that start and stop the EAI Java server and perform other EAI Java server functions such as merging payload configuration files. This component has no dependencies.
Important:
If a Payload Generator External Module (another EAI Java server) has already been installed (as part of installing the EAI Manager or another EAI-based publisher), the Account Synchronization EAI Java server must be installed on the same host where the existing EAI server is installed.You can run the Account Synchronization DM and the Payload Generator External Module (EM) on computers other than the computer on which the CM is running. To do this, you must run the Account Synchronization installation program on each computer that hosts one or more of these features.
Important:
Perform all installation and configuration steps before starting Account Synchronization.To install Account Synchronization:
Configure Account Synchronization for Oracle.
Install Account Synchronization DM.
Create additional Account Synchronization queues.
If your database queues are on multiple databases, link the databases.
Configure the EAI payload for Account Synchronization.
See "Configuring the EAI Payload for Account Synchronization".
Enable event notification.
See "Configuring Event Notification for Account Synchronization".
Configure Account Synchronization.
Configure the DAT_Listener module.
Set up service-level bill items.
Configure Account Synchronization for multiple databases.
See "Configuring Account Synchronization for Multiple Databases".
Before you install the Account Synchronization DM, you must configure all queuing database machines for advanced queuing.
Perform the following on each queuing database machine in your system:
Open the Oracle_Home/dbs/initSID.ora file.
Set the compatible parameter to the appropriate version to specify the Oracle database.
Important:
If you use an entry lower than 10.0, your BRM and Pipeline Manager systems fail.Set the aq_tm_process parameter to 1 to specify one queue monitor process (QMn).
Queue monitor process removes from the queue any processed events that are over an hour old.
Save and close the file.
Using SQL*Plus, log in to your database as the SYS user and grant AQ privileges to user pin:
% sqlplus sys/password@databaseAlias SQL> grant execute on dbms_aq to pin; Grant succeeded. SQL> grant execute on dbms_aqadm to pin; Grant succeeded. SQL> grant select on sys.gv_$aq to pin; Grant succeeded. SQL> grant execute on dbms_lock to pin; Grant succeeded.
To initialize the database instance with your changes, stop and restart Oracle.
Note:
If you have already installed the product, features that are already installed cannot be reinstalled without uninstalling them first. To reinstall a feature, uninstall it and then install it again.To install Account Synchronization DM:
Download the software to a temporary directory (temp_dir).
Important:
If you download to a Windows workstation, use FTP to copy the .bin file to a temporary directory on your UNIX server.
You must increase the heap size used by the Java Virtual Machine (JVM) before running the installation program to avoid “Out of Memory” error messages in the log file. For information, see "Increasing Heap Size to Avoid “Out of Memory” Error Messages".
Go to the directory where you installed the Third-Party package and source the source.me file.
Note:
You must source the source.me file to proceed with installation, otherwise “suitable JVM not found” and other error messages appear.Bash shell:
source source.me.sh
C shell:
source source.me.csh
Go to the temp_dir directory and enter this command:
7.5.0_AccountSynchTool_platform_opt.bin
where platform is the operating system name.
Note:
You can use the -console parameter to run the installation in command-line mode. To enable a graphical user interface (GUI) installation, install a GUI application such as X Windows and set the DISPLAY environment variable before you install the software.(Optional) To install Account Synchronization features separately, either on this computer or on another computer, select custom install when asked to specify the setup type.
Select the features you are installing by typing their respective numbers and click Next. The features are:
AcctSync_CM
AcctSync_DM
AcctSync_EAI_JS
Follow the instructions displayed during installation.
The default installation directory for Account Synchronization DM is opt/portal/7.5.
Note:
The installation program does not prompt you for the installation directory if BRM or Account Synchronization DM is already installed on the machine and automatically installs the package at the BRM_Home location.Go to the directory where you installed the Account Synchronization DM package and source the source.me file:
Bash shell:
source source.me.sh
C shell:
source source.me.csh
Go to the BRM_Home/setup directory and run the pin_setup script.
Note:
The pin_setup script starts all required BRM processes.The script creates a queue on the specified database, configures your pin.conf files, and starts all of your BRM processes.
Stop the Account Synchronization DM process.
For information, see "Starting and Stopping Account Synchronization DM".
The Account Synchronization DM installer automatically creates a default queue in a specified database. If your system requires multiple queues, create additional queues by manually running the pin_ifw_sync_oracle utility.
Important:
To avoid system errors, do not run Pipeline Manager while running the pin_ifw_sync_oracle utility.To create an additional database queue:
Verify default queue storage and retention time settings in the create_ifw_sync_queue.conf file.
For information, see:
Create your queue by logging in as user pin and running the pin_ifw_sync_oracle utility with the create command:
Note:
To create queues, user pin must have Oracle AQ privileges.su - pin pin_ifw_sync_oracle.pl create [-l username/password@databaseAlias] [-q queue_name -t queue_table]
The utility creates a database queue named IFW_SYNC_QUEUE and a queue table named IFW_SYNC. To use nondefault names, use the -q and -t parameters to specify names for the queue and queue table.
Important:
In multidatabase systems, all queues must have unique names.For more information about the pin_ifw_sync_oracle utility, see "pin_ifw_sync_oracle".
Verify that the queue and queue table were created and function properly by running the pin_ifw_sync_oracle utility with the test command:
pin_ifw_sync_oracle.pl test [-q queue_name -t queue_table]
The utility enqueues and dequeues 20 test events.
Run a summary report to verify that the queue processed the test events properly:
pin_ifw_sync_oracle.pl report -r summary
If successful, the report shows all 20 events with a processed state:
Tue Feb 04 page 1
Event Summary Report
Evt. Stat Event Name Event Count
--------- -------------------------------- -----------
PROCESSED LongTestEvent 10
ShortTestEvent 10
********* -----------
sum 20
If unsuccessful, you must drop and then recreate the queue and queue table. For information, see "Dropping the Queue and Queue Tables".
Note:
If your database queues reside on a single database, skip this section and go to "Configuring the EAI Payload for Account Synchronization".If your system contains queues on multiple databases, you must create a link from each queuing database to every other queuing database. This enables Oracle to forward events to queues residing on other databases.
Before linking your Oracle databases, verify that the database alias names are defined in each tnsnames.ora file (Oracle_home/network/admin/tnsnames.ora).
Note:
You can check this by logging in to one database as user pin and connecting to the other databases by using the database alias. For example:SQL> connect pin/password@databaseAlias
To link your databases, perform the following procedure from each database:
Using SQL*Plus, log in to your database as the SYSTEM user and grant database linking privileges to the BRM user pin:
% sqlplus system/manager@databaseAlias SQL> grant create database link to pin; Grant succeeded.
Log in to the database as user pin:
SQL> connect pin/password@databaseAlias
Create a link to other databases by entering the following command:
SQL> CREATE DATABASE LINK RemoteDatabaseAlias CONNECT TO pin IDENTIFIED BY pin_password USING 'RemoteDatabaseAlias';
For example, if you have two databases with the alias names BRM1 and BRM2, log in to BRM1 and give the following SQL command:
SQL> CREATE DATABASE LINK BRM2 CONNECT TO pin IDENTIFIED BY pin_password USING 'BRM2';
and log in to BRM2 and give the following SQL command:
SQL> CREATE DATABASE LINK BRM1 CONNECT TO pin IDENTIFIED BY pin_password USING 'BRM1';
You must modify your BRM system's payload configuration file in the following situations:
If you have another EAI-based publisher, you must do the following:
Check for conflicts in the EAI payload configuration files.
See "Checking for Conflicts in EAI Payload Configuration Files".
Specify the default configuration file.
If your Account Synchronization DM database number is not the default (0.0.9.9), see "Specifying the Account Synchronization DM Database Number".
If you uninstall Account Synchronization DM, see "Revising the Payload Configuration File When Uninstalling Account Synchronization DM".
For information about defining business events in the EAI payload configuration file, see BRM Developer's Guide.
If your BRM system already has an EAI publisher, the Account Synchronization DM installation program merges this file with the existing payload configuration file.
Note:
If you do not already have an existing EAI publisher application, skip this section and go to "Specifying the Account Synchronization DM Database Number".In rare cases, conflicts can occur when the Account Synchronization DM payload configuration file is merged with an existing payload configuration file. This can happen when entries in the two original configuration files have conflicting definitions.
Important:
You must determine whether merge conflicts exist before running the Account Synchronization DM.Compare the Account Synchronization DM payload configuration file (BRM_Home/sys/eai_js/payloadconfig_ifw_sync.xml) with the existing payload configuration file (referenced in BRM_Home/sys/eai_js/Infranet.properties). If any of the following conditions exist, it is not possible to run both EAI publishers in the same BRM system:
Two different business event definitions specify the same StartEvent.
The same business event definitions have different values for one or more of these attributes: StartEvent, EndEvent, or Source.
The same business event or element definitions have different search criteria.
The same element definitions have different values for one or more of these attributes: Source, PinFld, DataFrom, UseOnlyElement, or Tag.
The same element definitions have different OnEvent values.
If your BRM system already has an EAI publisher, you must make the payloadconfig_MergedWithIfw_sync.xml file your system's default payload configuration file.
Note:
If you do not already have an existing EAI publisher application, skip this section and go to "Specifying the Account Synchronization DM Database Number".To specify the default payload configuration file, do one of the following:
Change the EAI configFile entry so that it points to the merged payload configuration file:
In a text editor, open the eai_js properties file (BRM_Home/sys/eai_js/Infranet.properties).
Change the infranet.eai.configFile entry to refer to the BRM_Home/sys/eai_js/payloadconfig_MergedWithIfw_sync.xml file:
infranet.eai.configFile=./payloadconfig_MergedWithIfw_sync.xml
Save and close the file.
Rename the configuration file and the configFile entry to match each other:
Change the name of the file specified in the infranet.eai.configFile entry.
For example, change payloadconfig.xml to payloadconfig_eai.xml.
Change the name of the BRM_Home/sys/eai_js/payloadconfig_MergedWithIfw_sync.xml file to match the file name specified in the infranet.eai.configFile entry.
The default BRM database number for your Account Synchronization DM is 0.0.9.9. If you change your database number, you must change the value of the DB attribute in the Account Synchronization DM publisher definition.
Note:
If you did not change the default database number for your Account Synchronization DM, go to "Configuring Event Notification for Account Synchronization".In a text editor, open the payload configuration file in the BRM_Home/sys/eai_js directory (payloadconfig_ifw_sync.xml, or the merged file if you merged payload configuration files).
Find the <PublisherDefs> section.
In the Publisher DB entry, type the correct BRM database number.
For example, if your Account Synchronization DM database number is 0.0.9.5, change this entry:
<PublisherDefs>
<Publisher DB="0.0.9.9" Format="FLIST">
to this:
<PublisherDefs>
<Publisher DB="0.0.9.5" Format="FLIST">
Save and close the file.
To remove Account Synchronization elements from your system's EAI payload configuration file after uninstalling Account Synchronization DM:
In a text editor, open the payload configuration file in the BRM_Home/sys/eai_js directory (payloadconfig_ifw_sync.xml, or the merged file if you merged payload configuration files).
Find the <PublisherDefs> section.
Remove the following publisher definition:
<Publisher DB="0.0.9.9" Format="FLIST">
Note:
This is the default Account Synchronization DM publisher definition. Your definition might have a different DB attribute. For more information, see "Specifying the Account Synchronization DM Database Number".Save and close the file.
Stop and restart the Payload Generator External Module (the EAI Java server) by entering this command from the BRM_Home/bin directory:
pin_ctl bounce eai_js
When a BRM event that is included in a business event defined in the Account Synchronization DM payload configuration file occurs, the EAI framework uses event notification to call the opcode that caches the BRM event in the Payload Generator. See "About Event Notification" in BRM Developer's Guide.
Before you can use Account Synchronization, you must configure the event notification feature as follows:
If your system has multiple configuration files for event notification, merge them.
Ensure that the merged file includes the entire event notification list in the BRM_Home/sys/data/config/pin_notify_ifw_sync file.
(Optional) If you defined new business events for Account Synchronization, you must edit your final event notification list to include all the BRM events in the new business events.
Load your final event notification list into the BRM database.
You configure the Account Synchronization DM to connect to the BRM database and the database queue by performing these tasks:
Connect the Account Synchronization Manager's EAI framework to BRM by editing the CM configuration file (pin.conf).
Map BRM business events to the appropriate database queue by editing the ifw_sync_queuenames file.
Connect the Account Synchronization DM to the database queue by editing the Account Synchronization DM configuration file (pin.conf).
See "Configuring the Account Synchronization DM Configuration File".
You must modify the CM pin.conf file to enable the EAI framework to notify Account Synchronization when specific events occur. You should also verify that the pointer to the Account Synchronization DM specifies the correct database and port numbers.
Important:
If you use a multidatabase system and set up more than one CM, you must edit the configuration file for each CM.Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.
Set the enable_publish entry to 1:
- fm_publish enable_publish 1
Verify that the ifw_sync_dm_pointer entry specifies the correct database and port:
- cm dm_pointer 0.0.9.9 ip host_name/ip_address 11999
where:
0.0.9.9 is the default Account Synchronization DM database number.
host_name/ip_address is the host name or IP address of the computer on which the Account Synchronization DM runs.
11999 is the default Account Synchronization DM port number.
Note:
If you change the location of the Account Synchronization DM, you must modify this pointer. For more information, see the description of using configuration files to connect and configure components in BRM System Administrator's Guide.Important:
The Account Synchronization DM database number must match the number in these entries:The dm_db_no entry in the Account Synchronization DM configuration file (BRM_Home/sys/dm_ifw_sync/pin.conf).
The DB entry of the Account Synchronization Publisher definition in the payload configuration file (BRM_Home/sys/eai_js/payloadconfig_ifw_sync.xml).
The Account Synchronization DM port number must match the number in the dm_port entry in the Account Synchronization DM configuration file (BRM_Home/sys/dm_ifw_sync/pin.conf).
Save and close the file.
Stop and restart the CM:
From the BRM_Home/bin directory, enter this command:
pin_ctl bounce cm
You must configure which events the Account Synchronization DM sends to each database queue by editing the ifw_sync_queuenames file. This file specifies the names of all queues in your system and which events to send to each queue.
Note:
Only business events that are defined in the payloadconfig file can be sent to the database queue.
Account Synchronization does not send events to queues until you edit the ifw_sync_queuenames file.
To map business events to the database queue:
Open the BRM_Home/sys/dm_ifw_sync/ifw_sync_queuenames file in a text editor.
Add entries for each queue in your system by using the following syntax:
queue_Name@database_Link { Criteria }
where:
queue_Name specifies the queue name. The queue name must match the name you assigned the queue when you created it. Each queue name must also match the queue name in the corresponding DAT_Listener registry.
database_Link Use the database link names you created in "Linking Oracle Databases"
Criteria specifies which events to send to the queue. You can configure the Account Synchronization DM to send all business events, only events from a specific database, or only specific event types. Table 22-1 shows the syntax for each criteria:
Table 22-1 Syntax to Add Entries to Queues
| To Send This | Use This Syntax | Example |
|---|---|---|
|
All business events |
ALL |
ALL |
|
Only business events from a specific database |
0.0.0.x |
0.0.0.1 |
|
Only specific event types |
eventName |
CustCreate ProductCancel |
For example, to send all business events from BRM database 0.0.0.1 to the IFW_SYNC_QUEUE queue, and only CustCreate events to the IFW_SYNC_QUEUE2 queue, which resides in another database:
IFW_SYNC_QUEUE { 0.0.0.1 } IFW_SYNC_QUEUE2@database_Link { CustCreate }
Save and close the file.
During installation, the Account Synchronization DM installer generates a pin.conf configuration file that specifies how to connect to your BRM database and database queue and that contains other configuration settings. The installer populates the connection entries with values from your pin_setup.values file and provides default information for the other configuration entries. Before you start the Account Synchronization DM, verify that the file contains accurate information for connecting to your BRM database and database queue.
In multidatabase systems, each BRM database has its own Account Synchronization DM. Verify that each Account Synchronization DM pin.conf file contains accurate information for its associated database and queue.
Perform the following for each instance of Account Synchronization DM:
Open the Account Synchronization configuration file (BRM_Home/sys/dm_ifw_sync/pin.conf) in a text editor.
Verify that the plugin_name entry specifies the path and file name of the correct shared library file:
-dm plugin_name path/name
where:
name is libplugin_ifw_sync9i.so for Solaris and Linux, and libplugin_ifw_sync9i.a for AIX.
Verify that the queue_map_file entry specifies the path and file that maps the Oracle database queues to the events they are to receive.
For example:
- dm_ifw_sync queue_map_file ./ifw_sync_queuenames
For more information, see "Mapping Business Events to the Database Queue".
Verify that the queue_database entry specifies the alias name of the Oracle queuing database to which Account Synchronization DM connects.
The value of this entry should be the TNSNAMES.ORA alias, which can be found in the Oracle_home/network/admin/tnsnames.ora file:
- dm_ifw_sync sm_database alias_name
Verify that the queuing_database_id entry specifies the database user name that Account Synchronization DM uses to log in to the queuing database:
- dm_ifw_sync sm_id user_name
Verify that the queuing_database_pw entry specifies the password for the user specified in the queuing_database_id entry:
- dm_ifw_sync sm_pw password
(Optional) You can also edit the entries in Table 22-2:
Table 22-2 Entries That Are Editable
| Entry Name | Description |
|---|---|
|
connect_retries |
Specifies the number of times that Account Synchronization DM attempts to connect to the database queue. |
|
retry_interval |
Specifies the length of time, in seconds, that Account Synchronization waits before attempting to reconnect to the database queue. |
For more information, see "Configuring Account Synchronization DM Database Connection Attempts".
For other entries you can edit, see the comments in the pin.conf file.
Save and close the file.
Each instance of Pipeline Manager is connected to one database queue. You must configure each instance's DAT_Listener module to connect to its corresponding database queue by modifying the Pipeline Manager registry.
Perform the following tasks for each instance of Pipeline Manager:
Open the registry file.
Add the following lines to the Listener section of the registry file:
Important:
The Listener section must be listed after the pipeline and BRM database connection sections. Otherwise, Pipeline Manager fails to start.Listener
{
ModuleName = DAT_Listener
Module
{
InfranetConnection = #mandatory
QueueName = #mandatory
QueueLibrary = #mandatory
ConnectRetries = #optional
RetryInterval = #optional
LogEvents = #optional
}
}
where:
InfranetConnection points to the section of the registry file that specifies how Account Synchronization DM connects to the database queue.
For example, ifw.DataPool.LoginAccountSync. This entry is mandatory.
QueueName specifies the queue name.
For example, IFW_SYNC_QUEUE. This entry is mandatory.
QueueLibrary specifies if the Listener should use Oracle queue libraries. Enter OracleQueue.
ConnectRetries specifies the number of times the DAT_Listener module retries to connect to the database queue.
This entry is optional. The default is 0.
RetryInterval specifies the time, in seconds, between reconnection attempts.
This entry is optional. The default is 5.
LogEvents specifies whether the entire contents of each business event is copied to a log file.
This entry is optional. The default is FALSE.
Save and close the file.
You can control how many events are waiting to be processed simultaneously by configuring DAT_Listener to interleave CDR and business event processing. For more information, see "About Controlling the Business Event Backlog".
To interleave processing between CDR and business events:
Open the registry file.
Add the interleaving entries in the Listener section of the registry file:
Note:
These entries are optional. If not present, Pipeline Manager processes CDRs and business events concurrently.Listener
{
ModuleName = DAT_Listener
Module
{
#Add the following lines for interleaved processing:
InterleavingReqd = true #default is False
MaxNumEvents = #default is 900
MinNumEvents = #default is 300
CheckInterval = #default is 60
EnableInterLeavingStatistics = #default is False
ProcessAllEvents = #default is False
MaxEventProcessTime = #default is 60
MaxCDRProcessTime = #default is 300
}
}
where:
InterleavingReqd specifies whether interleaved processing is enabled.
The default is False. When set to False or not specified, interleaved processing is not performed; CDRs and events are processed simultaneously.
CheckInterval specifies (in seconds) how frequently DAT_Listener checks the number of events waiting in the queue (specified by MaxNumEvents and MinNumEvents) and the amount of processing time that has passed (specified by MaxCDRProcessTime and MaxEventProcessTime).
The default is 60. If this entry is not present, the default interval is used.
Note:
This entry takes precedence over MaxNumEvents, MinNumEvents, MaxEventProcessTime, and MaxCDRProcessTime. If CheckInterval is set too high, DAT_Listener will not switch between CDR and event processing even if the thresholds have been reached. For example, if MaxEventProcessTime is set as 3600 seconds and CheckInterval is set to 7200 seconds, events are processed for 7200 seconds before the processing time is checked.MaxNumEvents specifies the maximum number of business events allowed in the queue.
The default is 900. When the number of events in the queue reaches or exceeds this amount, DAT_Listener stops CDR processing and starts business event processing. When this entry is specified, MinNumEvents must also be specified.
For example, suppose CheckInterval is set to 60 seconds and MaxNumEvents is set to 900. When the business event queue is checked, there are 850 events in the queue. Because the number of events in the queue is less than 900, CDR processing does not stop. When the queue is checked again after the 60-second interval, there are 950 events in the queue. Because the number of events in the queue is greater than 900, CDR processing is stopped and queue processing is started.
MinNumEvents specifies the minimum number of business events allowed in the queue.
The default is 300. When the number of events in the queue reaches or drops below this amount, DAT_Listener stops business event processing and starts CDR processing. When this entry is specified, MaxNumEvents must also be specified.
For example, suppose CheckInterval is set to 60 seconds and MinNumEvents is set to 400. When the business event queue is checked, there are 401 events in the queue. Because the number of events in the queue is greater than 400, queue processing does not stop. When the queue is checked again after the 60-second interval, there are 10 events in the queue. Because the number of events in the queue is less than 400, queue processing is stopped and CDR processing is started.
EnableInterLeavingStatistics specifies whether to log only interleaving statistical data.
The default is False. By default, DAT_Listener logs all processing messages in the pipeline processing log (process.log). If this entry is set to True, only statistical data related to the rate of interleaved processing is logged. You can use this entry to monitor your event processing performance.
ProcessAllEvents specifies whether to process all events in the queue when Pipeline Manager is started.
A value of True processes all events in the queue before activating interleaved processing. A value of False activates interleaved processing at startup, and events are processed according to the interleaving settings.
If set to True at startup, after processing all events, this entry is reset to False. To use this feature, you must reset this entry to True each time you restart Pipeline Manager.
MaxEventProcessTime specifies the maximum number of seconds that business events are processed.
The default is 60. When Pipeline Manager has been processing business events for this amount of time, DAT_Listener stops business event processing and starts CDR processing regardless of how many business events are in the queue. When this entry is specified, MaxNumEvents, MinNumEvents, and MaxCDRProcessTime must also be specified.
MaxCDRProcessTime specifies the maximum number of seconds that CDRs are processed.
The default is 300. When Pipeline Manager has been processing CDRs for this amount of time, DAT_Listener stops CDR processing and starts business event processing regardless of how many CDRs are in the queue. When this entry is specified, MaxNumEvents, MinNumEvents, and MaxEventProcessTime must also be specified.
Important:
The default values for interleaved processing are also the minimum required values. If you specify a value less than the default for any entry, that value is ignored and the default value is used.Some entries can be used in a semaphore to update the processing thresholds. If these semaphores contain an error, the pipeline is deactivated and you must reactivate it. See the description of starting and stopping BRM in BRM System Administrator's Guide.
Save and close the file.
Switching to Business Event Processing When No CDRs Are Waiting
When there are no CDRs to process, DAT_Listener waits until either the CDR processing time threshold is reached or the maximum number of business events is reached before switching to business event processing. If this wait period is too long, you can shorten the CDR processing time by using a semaphore to update the DAT_Listener registry. The new semaphore value becomes effective the next time DAT_Listener checks for the number of events and elapsed processing time. This is determined by the CheckInterval registry entry. For example, if CheckInterval is set to 180 seconds, the semaphore update becomes effective after 180 seconds have elapsed.
Use one of the following semaphores to shorten the CDR processing time so that business events are processed sooner:
Shorten the CDR processing time by changing the MaxCDRProcessTime value:
ifw.DataPool.Listener.Module.MaxCDRProcessTime=new_value
Reduce the maximum number of business events by changing the MaxNumEvents value:
ifw.DataPool.Listener.Module.MaxNumEvents=new_value
If the number of business events waiting in the queue exceeds the new value, DAT_Listener immediately switches to business event processing when it checks the number of events.
To enable Pipeline Manager to choose the correct bill item for an event, you must configure BRM to pre-create service-level items. (For more information, see the description of how Pipeline Manager assigns delayed events to items in BRM Configuring Pipeline Rating and Discounting.)
To set up service-level bill items, run the load_config_item utilities to load the contents of the config_item_tags and config_item_types files into the BRM database. For more information, see the description of creating custom bill items in BRM Configuring and Running Billing.
After installing the Account Synchronization DM, you must enable BRM to audit GSM (Global System for Mobile Communication) objects by running the object_auditing.pl script. Auditing objects create a history of certain information, such as phone numbers and logins, so that BRM can track changes.
For a list of default objects, see "Required Objects to Be Audited".
The object_auditing.pl script invokes the "pin_history_on" utility to load the file containing the objects to audit and turn on object auditing. It then creates the audit table indexes in the BRM database.
Caution:
When installing wireless managers such as Account Synchronization DM or GSM Manager, you must install all managers before running this script. If you run this script before installing a wireless manager, your installation will fail.
If you use a multidatabase system, you must perform these steps in the following order:
1. Install all wireless managers.
2. Install your multidatabase system.
3. Run the object_auditing.pl script.
To enable additions of GSM objects, use the following command to run the object_auditing.pl script:
perl object_auditing
Note:
The object_auditing.pl script requires a pin.conf configuration file. You can create one (see the description of configuration files in BRM System Administrator's Guide), or you can run the utility from a directory that contains a pin.conf file, such as BRM_Home/sys/dm_ifw_sync.For more information, see "object_auditing".
You can customize audit table indexes or the list of audited objects by modifying the input files before running the object_auditing script:
To customize the list of audited objects, edit the pin_history_on input file (BRM_Home/apps/integrate_sync/pin_history_on_input).
To customize your audit table indexes, edit the index file (BRM_Home/sys/dd/data/create_indexes_audit_tables_oracle.source).
Pipeline Manager requires certain objects to be audited, which are included in the pin_history_on_input file in BRM_Home/apps/integrate_sync. Table 22-3 lists the default objects and their fields configured in the file:
Table 22-3 Objects Configured in pin_history_on_input
| Object | Fields Audited by Default |
|---|---|
|
/account |
|
|
/profile/acct_extrating |
|
|
/profile/serv_extrating |
|
|
/service |
|
|
/uniqueness |
|
For an overview of how Account Synchronization works in a multidatabase system, see "About Account Synchronization".
To synchronize accounts in BRM and Pipeline Manager in a multidatabase system:
Set up your multidatabase system and create multiple instances of Pipeline Manager for each database.
Configure each queuing database for Account Synchronization.
Link your queuing databases so that the databases can forward events to the appropriate database queue when necessary.
Install Account Synchronization DM on all systems that have the CM installed by following the instructions in "Installing Account Synchronization DM".
Note:
You do not need to perform all the configuration steps for secondary Account Synchronization installations. For example, you do not need to configure the EAI payload, enable event notification, set up service-level items, turn on object auditing, and validate rate plans. These updates are propagated to each database by Multidatabase Manager.(Optional) Create additional database queues.
Map each instance of the DAT_Listener module to its corresponding database queue.
Map the business events to each database queue in the ifw_sync_queuenames files.
Edit the configuration file (pin.conf) for each instance of Account Synchronization DM.
See "Configuring the Account Synchronization DM Configuration File".
In the registry section for the DAT_AccountBatch module, add the UseAsRouter entry and set it to True, as in this example:
CustomerData
{
ModuleName = DAT_AccountBatch
Module
{
IntegrateConnection = ifw.DataPool.Login
InfranetConnection = ifw.DataPool.LoginInfranet
LogEvents = True
LoadLogins = True
Listener = ifw.DataPool.Listener
Connections = 10
Threads = 10
UseAsRouter = True
}
}
For more information on this parameter, see the description of the DAT_AccountBatch module in BRM Configuring Pipeline Rating and Discounting.
In the registry section for the FCT_AccountRouter module, map each BRM database identifier to an output stream, as in this example:
Note:
You can use any names for the output streams.AccountRouter
{
ModuleName = FCT_AccountRouter
Module
{
Active = True
DataModule = ifw.DataPool.CustomerData
Streams
{
1 = PinOutputStream1
2 = PinOutputStream2
3 = PinOutputStream3
4 = PinOutputStream4
5 = PinOutputStream5
}
}
}
For more information on this parameter, see the description of the FCT_AccountRouter module in BRM Configuring Pipeline Rating and Discounting.
Configure the registry of each Pipeline Manager instance to read accounts from their associated databases.
For example, Pipeline Manager 1 connects to database 1, Pipeline Manager 2 connects to database 2, and so forth.
Each instance of Account Synchronization DM connects to only one database queue. In some cases, the Account Synchronization DM receives an event that belongs to another database (for example, when you move an account from one database to another). Oracle AQ uses the queue name entries in the ifw_sync_queuenames file to send the events to the appropriate queue.
The queuenames file in each database must include one or more queue entries for every database. Each queue entry includes the queue name and the events to send to that queue.
To map business events to multiple database queues:
Open the ifw_sync_queuenames file (BRM_Home/sys/dm_ifw_sync/ifw_sync_queuenames).
Add the queue names corresponding to each database and the business events to send to those queues.
Important:
The queue names must match the names you assigned the queues when you created them. Each queue name must also match the queue name in the corresponding DAT_Listener registry.If the queue is on the local database, enter only the queue name. If the queue is on a remote database, you must append the queue name with a link to the database to which it belongs. This means that for each ifw_sync_queuenames file, the queue names will be identical, but the queues that include a link will vary.
For example, if you use three databases, the entries in the queuenames file on database 0.0.0.1 will look like this:
IFW_SYNC_ROUTER_QUEUE { CustCreate ServiceLogin CustDelete } IFW_SYNC_QUEUE # local database queue { 0.0.0.1 } IFW_SYNC_QUEUE2@BRM2 # remote database { 0.0.0.2 } IFW_SYNC_QUEUE3@BRM3 # remote database { 0.0.0.3 }
And the entries in the queuenames file on database 0.0.0.2 will look like this:
IFW_SYNC_ROUTER_QUEUE@BRM1 { CustCreate ServiceLogin CustDelete } IFW_SYNC_QUEUE@BRM1 # remote database queue { 0.0.0.1 } IFW_SYNC_QUEUE2 # local database { 0.0.0.2 } IFW_SYNC_QUEUE3@BRM3 # remote database { 0.0.0.3 }
In the preceding example, the queue that connects to the Pipeline Manager instance where the multidatabase account router is configured (IFW_SYNC_ROUTER_QUEUE) is on the same database as the primary queue.
Note:
The multidatabase account router is only interested in CustCreate, CustDelete, and ServiceLogin events. However, you can alternatively specify ALL to have all events sent to the router.For more information, see "Mapping Business Events to the Database Queue".
Save and close the file.
To start Account Synchronization DM, enter this command at the prompt for Oracle AQ:
pin_ctl start dm_ifw_sync
To stop Account Synchronization DM, enter this command at the prompt for Oracle AQ:
pin_ctl stop dm_ifw_sync
This section provides information and guidelines to help you manage your Account Synchronization queues.
The main administrative tasks for database queues are:
Configuring How Often Processed Events Are Removed from the Queue
Configuring Account Synchronization DM Database Connection Attempts
Disconnecting and Reconnecting Account Synchronization DM to the Queue
You must create additional queues in the following situations:
You add a new instance of Pipeline Manager to your system.
You add a BRM database to your system.
To create additional queues in an existing system:
Stop Account Synchronization DM.
If necessary, configure the Oracle database for Account Synchronization.
If you are creating your queue in a new database, create internal database links between your database queues.
Create the new database queue by using pin_ifw_sync_oracle.
Specify which events the Account Synchronization DM sends to the new queue.
Connect the new queue to its corresponding DAT_Listener module.
Restart Account Synchronization DM.
You can monitor the events in your database queue by running pin_ifw_sync_oracle.
Important:
To avoid system errors, do not run Pipeline Manager while running the pin_ifw_sync_oracle utility.The pin_ifw_sync_oracle utility creates the following reports:
A summary report lists the number of events set to the READY and PROCESSED states.
A detailed report lists each event's ID, state, queuing time, and dequeuing time.
To run a summary report for Oracle AQ, enter this command:
% pin_ifw_sync_oracle.pl report -r summary [-q queue_name]
where queue_name specifies the queue name. For information, see "pin_ifw_sync_oracle".
To run a detailed report for Oracle AQ, enter this command:
% pin_ifw_sync_oracle.pl report -r detail [-q queue_name]
where queue_name specifies the queue name. For information, see "pin_ifw_sync_oracle".
To drop the queue and its queue table, run the pin_ifw_sync_oracle utility with the drop command:
Important:
To avoid system errors, do not run Pipeline Manager while running the pin_ifw_sync_oracle utility.% pin_ifw_sync_oracle.pl drop [-q queue_name]
The specified queue is dropped from the database. If the database contains no other queues for Account Synchronization, the utility also removes the Account Synchronization package, which contains stored procedures for queuing, dequeuing, and purging events.
For more information, see "pin_ifw_sync_oracle".
By default, the pin_ifw_sync_oracle utility creates Oracle database queues in the tablespace you specified when you installed Account Synchronization DM. If you'd like to use a different tablespace, perform one of the following:
Specifying Default Storage Settings by Using the Create_ifw_sync_queue.conf File
Specifying Storage Settings by Using the pin_ifw_sync_oracle Utility
You can specify the default storage settings by using the create_ifw_sync_queue.conf file. All database queues that you create use the default settings unless you override them with the pin_ifw_sync_oracle utility.
To specify your default storage settings:
Open the BRM_Home/apps/pin_ifw_sync/create_ifw_sync_queue.conf file in a text editor.
Specify the target tablespace and queue size by editing the storage_clause parameter:
Tip:
For production systems, create your queue in its own, separate tablespace to improve processing performance.$storage_clause = "tablespace PIN00 initrans 5 storage (initial 200k next 200k maxextents unlimited pctincrease 0 )";
Save and close the file.
You can specify a queue's storage settings by using the pin_ifw_sync_oracle utility with the -s parameter. This option overrides the storage settings in the create_ifw_sync_queue.conf file.
important:
To avoid system errors, do not run Pipeline Manager while running the pin_ifw_sync_oracle utility.To specify storage settings by using the pin_ifw_sync_oracle utility:
% su - pin % pin_ifw_sync_oracle.pl create [-q queue_name -t queue_table] -s storage_clause
where:
queue_name specifies the queue name.
queue_table specifies the queue table name.
storage_clause specifies the queue's storage parameters.
For more information, see "pin_ifw_sync_oracle".
Tip:
For production systems, create your queue in its own, separate tablespace to improve processing performance.The Oracle queue monitor process (QMn) removes from the queue any event set to the PROCESSED state for a specified amount of time. You specified a default retention time when you installed Account Synchronization DM. If you'd like to use a different retention time, perform one of the following:
Specifying Default Retention Times by Using the create_ifw_sync_queue.conf File
Specifying Retention Times by Using the pin_ifw_sync_oracle Utility
You can specify the default retention time setting by using the create_ifw_sync_queue.conf file. All database queues that you create use this default setting unless you override it with the pin_ifw_sync_oracle utility.
To specify how often processed events are removed:
Open the BRM_Home/apps/pin_ifw_sync/create_ifw_sync_queue.conf file in a text editor.
Set the retention_time parameter to the amount of time, in seconds, that you want to store processed events in the database queue:
Note:
For production systems, set the retention time to 0 to optimize your processing performance.$retention_time = retention_time;
Save and close the file.
You can specify a queue's retention time by using the pin_ifw_sync_oracle utility with the -r parameter. This option overrides the retention time settings in the create_ifw_sync_queue.conf file.
Important:
To avoid system errors, do not run Pipeline Manager while running the pin_ifw_sync_oracle utility.To set the retention time by using the pin_ifw_sync_oracle utility:
% su - pin % pin_ifw_sync_oracle.pl create [-q queue_name -t queue_table] -r retention_time
where:
queue_name specifies the queue name.
queue_table specifies the queue table name.
retention_time specifies the queue's retention time, in seconds.
For more information, see "pin_ifw_sync_oracle".
Tip:
For production systems, set the retention time to 0 to optimize your processing performance.You can configure how often Account Synchronization DM attempts to connect to the database that contains the Account Synchronization queue.
To configure connection attempts:
Open the Account Synchronization DM configuration file (BRM_Home/sys/dm_ifw_sync/pin.conf) in a text editor.
Specify the number of times Account Synchronization DM should retry to connect to the Oracle database server by editing the connect_retries entry.
The default is 1.
-dm_ifw_sync connect_retries number_of_retries
Specify the interval, in seconds, between each reconnection attempt by editing the retry_interval entry.
The default is 0.
-dm_ifw_sync retry_interval interval
Save and close the file.
Stop and restart Account Synchronization DM.
You can prevent the Account Synchronization DM from enqueuing business events when you tune or shut down the queuing database by using the pin_ctl utility. See BRM System Administrator's Guide.
To disconnect from the queue, use the following command:
pin_ctl stop dm_ifw_sync
To reconnect to the database queue and begin enqueuing business events, use the following command:
pin_ctl start dm_ifw_sync
For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
You can keep Pipeline Manager online when you tune or shut down the queuing database by disconnecting the DAT_Listener module from the queue. For more information, see "About Disconnecting the Account Synchronization DM from the Queue".
To disconnect the module from the database queue, use the Disconnect{} semaphore file entry, as shown below:
ifw.DataPool.Listener.Module.Disconnect{}
To reconnect the DAT_Listener module to the database queue, use the Connect{} semaphore file entry, as shown below:
ifw.DataPool.Listener.Module.Connect{}
For more information about the semaphore entries, see the description of the DAT_Listener module in BRM Configuring Pipeline Rating and Discounting.
If an error occurs during an Account Synchronization operation, check the Account Synchronization log file (BRM_Home/sys/dm_ifw_sync/dm_ifw_sync.pinlog) for error codes. For a list of standard errors and codes, see the description of BRM error codes in BRM System Administrator's Guide.
To install Account Synchronization DM and create database queues, the pin user must have Oracle AQ privileges. If pin does not have privileges, you receive the following error when you attempt to install Account Synchronization DM or create queues with the pin_ifw_sync_oracle utility:
PLS-00201 identifier 'SYS.DBMS_AQ' must be declared
To fix this error:
Using SQL*Plus, log in to your database as the SYS user and grant AQ privileges to user pin:
% sqlplus sys/password@databaseAlias SQL> grant execute on dbms_aq to pin; Grant succeeded. SQL> grant execute on dbms_aqadm to pin; Grant succeeded. SQL> grant execute on dbms_lock to pin; Grant succeeded.
Reinstall Account Synchronization DM or create your queue by running the pin_ifw_sync_oracle utility manually.
This section describes interleaved processing errors and their solutions.
If you enable interleaved event processing in DAT_Listener, and you specify the event and CDR processing time entries (MaxEventProcessTime and MaxCDRProcessTime), you must also specify the entries that set the number of event thresholds (MaxNumEvents and MinNumEvents). If you do not do this, DAT_Listener throws a critical error (ERR_REG_VALUE_INVALID) during startup. However, if you update the registry by using a semaphore and the required entries are not specified, DAT_Listener throws a warning and disregards the semaphore update.
When an interleaving semaphore entry contains an error, the pipelines are deactivated.
The following interleaving semaphore errors cause the pipelines to be deactivated:
The values for MinNumEvents and MaxNumEvents are not numbers.
MinNumEvents is less than MaxNumEvents.
The values for MaxEventProcessTime and MaxCDRProcessTime are not numbers.
CheckInterval is not a number.
To reactivate the pipelines, use the Active semaphore. For example:
ifw.Pipelines.PRE_PROCESS.Active=TRUE ifw.Pipelines.PRE_RECYCLE.Active=TRUE ifw.Pipelines.ALL_RATE.Active=TRUE
After the pipelines are reactivated, reissue the interleaving semaphore using the correct values.
You can modify the BRM events that make up a business event before the business event is sent to Account Synchronization DM for publishing to Pipeline Manager. You do this by customizing the Account Synchronization policy opcode, PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT. See BRM Developer's Reference.
Note:
Customizing the policy opcode requires programming knowledge and should be performed only by a developer.You might want to modify an event to filter out unneeded data, which can improve performance if you publish large quantities of events. You can also use a flag to specify how adjustments should be applied to the account balance; for example, to permit the account to have a negative balance. For more information, see the description of PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT in BRM Developer's Reference.
To modify a business event before sending it to Pipeline Manager:
Ensure that all the BRM events that make up the business event are associated with opcode number 3626 (PCM_OP_IFW_SYNC_PUBLISH_EVENT) in your system's event notification list.
See "Configuring Event Notification for Account Synchronization".
Use PCM_OP_IFW_SYNC_PUBLISH_EVENT to process the BRM events that make up the business event.
See "Processing BRM Events That Make Up Account Synchronization Business Events".
Use the PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT policy opcode to customize the BRM events that make up the business event.
See "Modifying BRM Events That Make Up Account Synchronization Business Events".
PCM_OP_IFW_SYNC_PUBLISH_EVENT passes BRM events that make up Account Synchronization business events to the PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT policy opcode for modification.
PCM_OP_IFW_SYNC_PUBLISH_EVENT is called by the event notification feature when an event associated with this opcode in your system's event notification list occurs. See "Configuring Event Notification for Account Synchronization".
By default, PCM_OP_IFW_SYNC_PUBLISH_EVENT does not modify events; it only passes them to the policy opcode.
If the BRM event is published in the business event, PCM_OP_IFW_SYNC_PUBLISH_EVENT returns one of two POIDs:
If the object passed in was an /event type object, the event POID is returned.
If the object passed in was not an /event type object, a POID of type /publish is returned.
If the BRM event is not published (for example, if you filter out the event based on your business logic), the input flist is returned.
You can customize the PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT policy opcode to remove or enhance BRM events and event fields before they are assembled into business events and sent to Pipeline Manager. For example, you can customize this opcode to:
Filter out BRM events that you do not want to include in published business events for various business or performance reasons.
Important:
Do not filter out balance impact fields based on the resource ID. If you do, you might remove fields needed by Pipeline Manager.
Do not modify the code that prepares the login fields (the fm_ifw_sync_pol_prep_logins function). This code is required when a login is changed.
Modify the value of the PIN_FLD_FLAGS field that is added to PIN_FLD_BAL_IMPACT arrays. This field specifies how to apply adjustments. For example, you can permit a negative balance by specifying a value of 4. By permitting a negative balance, the negative amount will be deducted from the account balance with the next billing cycle.
You might use this method, for example, when a customer purchases a service that includes 60 free minutes per month and cancels the service before the end of the month. If the customer has used all 60 minutes, but you prorate the free minutes, the amount of usage for the canceled period can be deducted with the next billing cycle (provided the customer has a positive balance at that time).
By default, PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT modifies the following BRM events listed in Table 22-4:
Table 22-4 BRM Events Modified by PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT
| Event | Action |
|---|---|
|
/event/billing/debit |
Adds a PIN_FLD_FLAGS field to each PIN_FLD_BAL_IMPACT array. This field indicates how adjustments should be applied:
Note: This flag value is not implemented.
|
|
/event/billing/product/fee/cycle/* |
Filters out these event types after the first occurrence. These events are generated when a product is purchased and when billing is run. For product purchase, Pipeline Manager must be notified so it can update the in-memory account data. However, for billing, Pipeline Manager performs the account balance update and does not need this event passed in. |
|
/event/billing/sub_bal_validity |
Creates a PIN_FLD_SUB_BAL_IMPACTS array in the event. PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT populates this array with information from element 1 of the existing PIN_FLD_SUB_BAL_AUDIT array for the event. Element 1 stores the updated validity period and the resource and balance group associated with the sub-balance. Adding PIN_FLD_SUB_BAL_IMPACTS with the new validity period enables the DAT_BalanceBatch module to dynamically update the rating basis. |
|
/event/customer/login |
Copies PIN_FLD_SERVICE_OBJ from the top level of the input flist into the new login field (element 1) in the PIN_FLD_LOGINS array. This ensures that Pipeline Manager knows which service is associated with the new login. |
If the BRM event is published in the business event, PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT returns one of two POIDs:
If the object passed in was an /event type, the event POID is returned.
If the object passed in was not an /event type object, a POID of type /publish is returned.
If the BRM event is not published (for example, if you filter out the event based on your business logic), the input flist is returned.
To enable BRM to audit GSM objects, run the object_auditing.pl script. For more information, see "Turning On Object Auditing".
The object_auditing.pl script performs a series of steps that can also be performed manually. This section describes these manual steps.
To manually enable BRM to audit GSM objects:
Modify the DM configuration file (pin.conf) and run the pin_history_on utility.
Modify the create_indexes_audit_tables_oracle.source file and create the audit table indexes.
Caution:
When installing wireless managers such as Account Synchronization DM or GSM Manager, you must install all managers before running this utility. If you run this utility before installing a wireless manager, your installation will fail.
If you are using a multidatabase system, you must perform these steps in the following order:
1. Install all wireless managers.
2. Install your multidatabase system.
3. Run the pin_history_on utility.
Important:
The pin_history_on utility requires a pin.conf configuration file. You can create one (see the description of creating configuration files in BRM System Administrator's Guide), or you can run the script from a directory that contains a pin.conf file, such as BRM_Home/sys/dm_ifw_sync.
Before running this utility, you must manually modify entries in the Oracle DM configuration file to give the DM write permission so that the objects in the input file can be written to the database. After running the utility, you restore the entries in the configuration file to their original values.
To run the pin_history_on utility:
In a text editor, open the Oracle DM configuration file (BRM_Home/sys/dm_oracle/pin.conf).
Note the value of the following entries:
- dm dd_write_enable_fields 1 - dm dd_write_enable_objects 1 - dm dd_write_enable_portal_objects 1 - dm dd_mark_as_portal 1
Set the values of the following entries to 1.
- dm dd_write_enable_fields 1 - dm dd_write_enable_objects 1 - dm dd_write_enable_portal_objects 1 - dm dd_mark_as_portal 1
Note:
If an entry is not in the file, add it.Save and close the file.
Stop and restart the Oracle DM.
Run the pin_history_on utility:
pin_history_on [-dv] pin_history_on_input
Note:
If you run the utility from another directory, include the path to the pin_history_on utility in the command line. For example:pin_history_on [-dv] BRM_Home/bin/pin_history_on_input
For more information, see "pin_history_on".
In a text editor, open the Oracle DM pin.conf file (BRM_Home/sys/dm_oracle/pin.conf).
Restore the following entries to their original values (the values they had before you modified them):
- dm dd_write_enable_fields - dm dd_write_enable_objects - dm dd_write_enable_portal_objects - dm dd_mark_as_portal
Save and close the file.
Stop and restart the Oracle DM.
After running the pin_history_on utility, you must create indexes for the new audit tables.
The Account Synchronization installation installs a file (create_indexes_audit_tables_oracle.source) that specifies the necessary indexes on the audit tables. You must modify two entries in this file to match the values as specified in your BRM_Home/setup/pin_setup.values file:
Open the audit tables indexes file (BRM_Home/sys/dd/data/create_indexes_audit_tables_oracle.source).
Edit the $PIN_CONF_TBLSPACEX1 entry to specify pinx00.
Note:
This entry must have the same value as the variable $MAIN_DB{'indexes_group'} configured in the BRM_Home/setup/pin_setup.values file. The default value of this entry is pinx00.Edit the $PIN_CONF_STORAGE_MED entry to specify the following:
storage (initial 200k next 200k maxextents unlimited pctincrease 0)
Save and close the file.
Create the audit table indexes in SQL*Plus:
sqlplus user/password@database_Alias @filepath/create_indexes_audit_tables_oracle.source
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|