14 About Synchronizing Account Data between the BRM Database and ECE

Learn how to use the Oracle Communications Billing and Revenue Management (BRM) account synchronization feature to send account data updates from the BRM database to Elastic Charging Engine (ECE).

Note:

For information about sending pricing data updates to external customer relationship management (CRM) applications, see "Understanding the Synchronization Queue Data Manager" in BRM Synchronization Queue Manager.

Topics in this document:

About Account Synchronization

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.

How Account Synchronization Works

Account synchronization uses 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)—to publish updated account data to the ECE Notification queue. ECE then retrieves the data from the Notification queue.

Figure 14-1 shows the account synchronization data flow from the BRM server to ECE.

Figure 14-1 Account Synchronization Data Flow from the BRM Server to ECE

Description of Figure 14-1 follows
Description of "Figure 14-1 Account Synchronization Data Flow from the BRM Server to ECE"

Account synchronization works as follows:

  1. A BRM event occurs, generating data that the account synchronization feature 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 (which includes event-to-opcode mapping from the account synchronization pin_notify_ifw_sync file).

  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 for BRM. In turn, BRM retrieves the event from the Acknowledgment queue.

    Note:

    The Suspense and Acknowledgment queues are created and configured when you install ECE.

About the EAI Framework for Account Synchronization

You use the EAI framework to define business events for account synchronization, to capture the BRM events that make up the business events, and to send completed business events to the Oracle DM.

The account synchronization EAI framework consists of the following components:

  • BRM event notification

    The account synchronization event notification list contains all of the BRM events that make up the business events defined in the Oracle DM payload configuration file. In the list, each event is associated with an opcode. When one of the events occurs, the event notification system calls the associated opcode to pass the event to the Payload Generator EM.

    You specify the BRM events that trigger calls to the Payload Generator EM by using the BRM_home/sys/data/config/pin_notify_ifw_sync file. See "Configuring Event Notification for Account Synchronization".

    For more information about event notification, see "Using Event Notification" in BRM Developer's Guide.

  • Payload Generator EM

    The Payload Generator EM collects the BRM events listed in the account synchronization event notification list, generates the data necessary to publish account synchronization business events, and sends the business events to the Oracle DM.

    The data required to create a complete account synchronization business event is specified in the Oracle DM payload configuration file (BRM_home/sys/eai_js/payloadconfig_ifw_sync.xml), which defines the business events that the Oracle DM uses to publish updated account data to ECE.

    The default Oracle DM payload configuration file includes definitions for business events such as AccountStatusUpdate, BillInfoUpdate, BillNow, CustCreate, ModifyBalanceGroup, and UpdateServices.

    You can add custom business events to the file. For information about creating business events, see "Defining Business Events" in BRM Developer's Guide.

    For information about configuring the EAI payload in systems that contain multiple EAI publishers, see "Configuring the EAI Payload for Account Synchronization".

Although account synchronization relies on the EAI framework, you do not need to install EAI Manager separately. All necessary EAI files are included with the account synchronization components installed with BRM.

About the Oracle DM and Account Synchronization

The Oracle DM publishes business events to a designated 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.

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

  1. Determines whether the event should be sent to the Notification queue by checking the ifw_sync_queuenames file.

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

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

About Disconnecting the Oracle DM from the Queue

You can prevent the Oracle DM from publishing events to the database queue by using the pin_ctl utility, which controls the connection between the Oracle DM and the queue. This enables you to make changes to the queuing database schema without affecting the account synchronization process.

See "Disconnecting and Reconnecting the Account Synchronization DM to the Queue".

About the Database Queue

Account synchronization uses a persistent Notification queue to pass business events from the Oracle DM to ECE. The queue enables account synchronization to pass events asynchronously, so the Oracle DM and ECE are not required to be running at the same time.

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

  • If the Oracle DM terminates, ECE continues retrieving business events already in the Notification queue.

About Creating the Notification Queue

The BRM installer automatically creates a Notification queue (named IFW_SYNC_QUEUE by default) on the specified database schema. When you create the Notification queue, you specify the following:

  • The database schema in which to create the queue.

  • The tablespace in which to create the queue.

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

Note:

When you install ECE, it creates the Suspense (ECE_SUSPENSE_QUEUE) and Acknowledgment (ECE_ACK_QUEUE) queues for the account synchronization process.

About Event Status Flags

Events in the Oracle DM database queue are set to the following states:

  • READY indicates that the event has not been retrieved by ECE.

  • PROCESSED indicates that the event was retrieved by ECE. The Oracle Queue Monitor process (QMn) removes processed events from the queue after a configurable amount of time.

You can check the status of events in your queue by running a report. See "Generating Queue Reports".

About Account Synchronization in a Multischema System

To set up account synchronization for 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 these queues for each secondary BRM schema.

    • Notification queue (IFW_SYNC_QUEUE)

    • Suspense queue (ECE_SUSPENSE_QUEUE)

    • Acknowledgment queue (ECE_ACK_QUEUE)

    You create these queues manually by running the pin_ifw_sync_oracle 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" in BRM System Administrator's Guide.

Figure 14-2 shows the data flow from multiple instances of the Oracle DM to ECE.

Figure 14-2 Data Flow from Multiple Instances of the Oracle DM to ECE

Description of Figure 14-2 follows
Description of "Figure 14-2 Data Flow from Multiple Instances of the Oracle DM to ECE"