45 Synchronizing Account Data between the BRM Database and ECE

You can set up your Oracle Communications Billing and Revenue Management (BRM) system to synchronize account data between the BRM database and Elastic Charging Engine (ECE).

Topics in this document:

• About Account Synchronization with ECE

• How Synchronization Works with ECE

• About the EAI Framework for Account Synchronization

• About the Oracle DM and Account Synchronization

• About the Oracle AQ Database Queue

• About Synchronizing Data in a Multischema System

About Account Synchronization with ECE

Account synchronization keeps account data in the BRM database and ECE synchronized. For example, when a customer service representative (CSR) adds, cancels, or modifies an account or when an adjustment such as a cycle fee is applied to an account balance, that information must be updated in ECE so that ECE can rate service usage events properly. Account synchronization sends the updated information to ECE through a database queuing system, enabling ECE to rate events using the updated information.

To configure your system to synchronize account data between the BRM database and ECE, install ECE, create your AQ database queues, and configure the Oracle DM to publish customer events to the queues. See "Configuring Your AQ Database Queues".

How Synchronization Works with ECE

BRM synchronizes account data using the Oracle Data Manager (DM) and the Enterprise Application Integration (EAI) framework, which consists of the event notification system and the Payload Generator External Module (EM). The Oracle DM publishes account data to an Advanced Queuing (AQ) database queue, where ECE can retrieve it.

Figure 45-1 shows the data flow between the BRM server and ECE.

Figure 45-1 Data Flow between the BRM Server and ECE

Description of "Figure 45-1 Data Flow between the BRM Server and ECE"

Account data is synchronized between BRM and ECE as follows:

1. A BRM event occurs, generating data BRM is configured to send to ECE.

2. The event notification system calls the opcode associated with the BRM event in the system's event notification list.

3. One of the following actions occurs:

   • If the event is associated with the PCM_OP_IFW_SYNC_PUBLISH_EVENT opcode, it is passed to the PCM_OP_IFW_SYNC_POL_PUBLISH_EVENT policy opcode for modification. The policy opcode passes the event, along with any modifications, to the Payload Generator External Module (EM).

   • If the event is not associated with the PCM_OP_IFW_SYNC_PUBLISH_EVENT opcode, it is sent directly to the Payload Generator EM.

4. The Payload Generator EM collects events in its payload until they compose a complete business event.

5. When the business event is complete, the Payload Generator EM sends it to the Oracle DM.

6. The Oracle DM publishes the business event to the Notification queue.

7. ECE Customer Updater retrieves the business event from the Notification queue and uses the event as needed.

   • If the update request fails, ECE moves the business event to a Suspense queue for later reprocessing.

   • If the update request succeeds, ECE publishes an acknowledgment event to the Acknowledgment queue. In turn, BRM retrieves the event from the Acknowledgment queue.

About the EAI Framework for Account Synchronization

You use the EAI Manager framework to define business events, capture the BRM events that make up the business events, and send the completed business events to the Oracle DM. See "About Enterprise Application Integration (EAI) Manager" in BRM Developer's Guide for more information.

The EAI framework consists of the following components:

• BRM event notification

  When specific BRM events occur, event notification automatically triggers calls to opcodes that send the event to the Payload Generator EM.

  You map BRM events to opcodes using an event notification file. The default event notification file (ECE_home/brm_config/pin_notify) provided with the ECE installation lists the BRM events required by ECE, such as /event/notification/account/create, /event/billing/product/fee/purchase, and /event/billing/cycle/tax. You can change the list of BRM events in the file to meet your business needs. You must load the event notification file into the database before account synchronization can start. See "Using Event Notification" in BRM Developer's Guide for more information.

• Payload Generator EM

  The Payload Generator EM collects BRM events until they form a complete business event, generates the data necessary to publish business events, and sends the business events to the Oracle DM.

  The data required to create a complete business event is specified in a payload configuration file. The default payload configuration file (ECE_home/brm_config/payloadconfig_ece_sync.xml) provided with the ECE installation defines the business events that ECE needs, such as AccountStatusUpdate, BillInfoUpdate, and BillNow. You can add or remove business events from the file. See "Configuring Business Events" in BRM Developer's Guide for more information.

About the Oracle DM and Account Synchronization

The Oracle DM publishes business events to a Notification queue. You specify how the Oracle DM connects to the queue and which business events to send to the queue by using the following configuration files:

• The BRM_home/sys/dm_oracle/pin.conf file specifies how the Oracle DM connects to the queue.

• The BRM_home/sys/dm_oracle/aq_event_map file specifies the business events sent to the Notification queue. See "Mapping Business Events to Database Queues".

When the Oracle DM receives a business event from the Payload Generator EM, it does the following:

1. Determines whether to send the business event to the Notification queue by reading the aq_event_map file.

2. Publishes the entire content of the business event to the Notification queue.

3. Sets the business event in the Notification queue to a READY state. See "About Event Status Flags".

About the Oracle AQ Database Queue

The Oracle AQ database queue is used to pass business events from the Oracle DM to ECE. The Oracle DM sends business events to the queue asynchronously, so the BRM and ECE applications are not required to be running at the same time.

• If ECE terminates, the Oracle DM continues publishing business events to the queue. After ECE restarts, it retrieves the business events from the queue.

• If the Oracle DM terminates, ECE continues to retrieve business events already in the queue.

About Creating Your AQ Database Queues

The ECE postinstallation script (post_Install.pl or kafka_post_install.sh) automatically creates Notification, Suspense, and Acknowledgment AQ database queues in your specified schema. You can create additional AQ database queues to meet your business needs using the pin_publish_aq_oracle.pl script, which is included with the BRM installation. See "pin_publish_aq_oracle.pl" for more information.

When creating AQ database queues, you specify the following:

• The database schema in which to create the queue.

• The name of the queue and queue table.

• The tablespace in which to create the queue.

  You can create the queue in an existing tablespace or its own separate tablespace. For optimal performance in production systems, create the queue in its own tablespace.

About Synchronizing Data in a Multischema System

To synchronize data in a multischema BRM system, you install and configure an Oracle DM on the primary BRM installation machine and on all secondary BRM installation machines.

You also do the following:

• Create the following AQ database queues for each secondary BRM schema.

  • Notification queue

  • Suspense queue

  • Acknowledgment queue

  You create these queues manually by running the pin_publish_aq_oracle.pl utility. See "Creating Additional Queues for Multischema BRM Systems".

• Configure an instance of ECE Customer Updater for each BRM schema.

  To configure an instance of ECE Customer Updater, see "Configuring Customer Updater".