1 Understanding the Synchronization Queue Data Manager

This document describes the Oracle Communications Billing and Revenue Management (BRM) Synchronization Queue Data Manager (DM) and how it works.

See also:

About Synchronizing Pricing Data

You can synchronize the following pricing data between BRM and external customer relationship management (CRM) applications:

  • Charge offers, including their associated provisioning tag details.

  • Simple discounts in discount offers. See "About Simple Discounts".

  • Real-time chargeshare offers.

When you start a CRM integration, you can export all of your existing charge offers, discount offers, and chargeshare offers from BRM to the external CRM application in a batch by using the pin_export_price utility. After BRM and the external CRM application are integrated, BRM can send charge offer, discount offer, and chargeshare offer changes to the external CRM application in real time.

Note:

For information about sending account data updates from BRM to Oracle Communications Elastic Charging Engine (ECE), see "About Synchronizing Account Data between the BRM Database and ECE" in BRM Installation Guide.

About Simple Discounts

BRM evaluates discounts in discount offers when they are created or modified to determine whether they are simple or complex. BRM considers a discount to be simple if it meets the following criteria:

  • The discount mode is original charge or remaining charge.

  • The event type is a purchase or cycle event.

  • The discount trigger condition is always true: (1 >= 0) and the condition expression is an integer value.

  • The quantity range expression is “Charge".

  • The discount contains only one discount rule, one discount quantity range, and one discount balance impact.

  • The discount balance impact is set to the impact currency balance element.

  • The base expression is “Charge".

If a discount is considered simple, BRM sends the following information to the external CRM application: the balance element ID, the discount amount, and a flag indicating whether the discount amount is a percentage (P) or an absolute (A) value.

If a discount is not considered simple, BRM sends to the external CRM application only the balance element ID and the discount amount, which is set to 0.

About the Data Synchronization Process

BRM synchronizes charge offers, discount offers, and chargeshare offers by using the Synchronization Queue DM and the Enterprise Applications Integration (EAI) framework, which consists of the event notification system and the Payload Generator External Module (EM). The Synchronization Queue DM and EAI framework work together to publish changes to a central Oracle Advanced Queuing (AQ) database queue called the Synchronization Queue DM database queue. External CRM applications can then retrieve data directly from the database queue.

Note:

To use the Synchronization Queue DM, you must purchase and install EAI Manager. For more information, see "About Integrating BRM with Enterprise Applications" in BRM Developer's Guide.

Figure 1-1 shows the data flow from BRM to the external CRM application:

Figure 1-1 Data Synchronization Process

Description of Figure 1-1 follows
Description of "Figure 1-1 Data Synchronization Process"

Charge offers, discount offers, and chargeshare offers are synchronized in the following way:

  1. A notification event is generated. The way a notification event is generated depends on whether you are synchronizing in real time or in a batch:

    • In real time: BRM generates notification events right after any of the following occurs: a charge offer changes, a discount offer changes, or a chargeshare offer changes.

    • In a batch: The pin_export_price utility generates the notification events. When you run the utility, it retrieves charge offers, discount offers, and chargeshare offers from the BRM database and then generates a notification event for each object that is retrieved. See "Exporting Pricing Data in a Batch".

  2. The BRM event notification system recognizes the notification event and calls the Payload Generator EM. See "About BRM Event Notification".

  3. The Payload Generator EM collects events in its payload until they compose a complete business event. See "About the Payload Generator EM".

  4. When the business event is complete, the Payload Generator EM sends it to the Synchronization Queue DM. See "About the Synchronization Queue DM".

  5. The Synchronization Queue DM sends the business event to the Synchronization Queue DM database queue. See "About the Synchronization Queue DM Database Queue".

  6. The external CRM application retrieves the business event from the database queue and updates the information in its system.

About BRM Event Notification

The following notification events are generated when you run the pin_export_price utility or when charge offers, discount offers, and chargeshare offers change in the BRM system:

  • /event/notification/price/discounts/modify

  • /event/notification/price/products/modify

  • /event/notification/price/sponsorships/modify

When BRM is configured to synchronize charge offers, discount offers, and chargeshare offers, the event notification system listens for one of these events to occur and then calls the Payload Generator EM.

You define the notification events that trigger calls to the Payload Generator EM by using the BRM_home/sys/data/config/pin_notify_crm_sync file. See "Configuring Event Notification for the Synchronization Queue DM".

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

About the Payload Generator EM

The Payload Generator EM collects notification events, generates the data necessary to publish business events, and sends the data to the Synchronization Queue DM.

The data required to create a complete business event is defined in the Synchronization Queue DM payload configuration file (BRM_home/sys/eai_js/payloadconfig_crm_sync.xml). The default file includes definitions for the following business events:

  • ProductInfoChange - Defines the events related to charge offer information changes, such as charge offer pricing changes.

  • DiscountInfoChange - Defines the events related to discount offer information changes, such as discount offer criteria changes.

  • SponsorshipInfoChange - Defines the events related to chargeshare offer (/sponsorship object) changes.

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

For information on how to configure the payloadconfig_crm_sync file, see "Configuring the EAI Payload for the Synchronization Queue DM".

About the Synchronization Queue DM

The Synchronization Queue DM is responsible for publishing data to the Synchronization Queue DM database queue. You define which business events are sent to the database queue by using the queue-names file (BRM_home/sys/dm_aq/aq_queuenames). To configure the queue-names file, see "Specifying Which Business Events to Send to the Database Queue".

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

  1. Determines whether the event should be sent to the Synchronization Queue DM database queue by checking the aq_queuenames file.

  2. Publishes the entire contents of a business event to the database queue as an XML message.

  3. Sets the event in the database queue to a READY state. For information, see "About Event Status Flags".

    Note:

    If the Synchronization Queue DM is offline for an extended period of time, you can use the pin_export_price utility to synchronize charge offer and discount offer CRM data in batches. For more information, see "Exporting Pricing Data in a Batch".

About the Synchronization Queue DM Database Queue

The Synchronization Queue DM database queue is used to pass business events from the Synchronization Queue DM to the external CRM application. The Synchronization Queue DM sends business events to the database queue asynchronously, so BRM and the external CRM application are not required to be running at the same time.

  • If the external CRM application terminates, the Synchronization Queue DM continues to send business events to the database queue. After the external CRM application restarts, it retrieves the business events from the database queue.

  • If the Synchronization Queue DM terminates, the external CRM application continues to retrieve business events already in the database queue.

About the Structure of Queued Messages

The Synchronization Queue DM publishes the entire contents of a business event. The business event is stored as a message in a /deq_event_ty object. This object includes the following fields:

  • PIN_FLD_EVENT_NAME — Specifies the name of the business event. The external CRM application can use this event name to identify the type of data in the queued message. For more information, see "About Retrieving Specific Events from the Synchronization Queue DM Database Queue".

  • PIN_FLD_FLIST_BUF — Contains the message (business event) in XML format if the message size is 4000 bytes or less.

  • PIN_FLD_LARGE_FLIST_BUF — Contains the message (business event) in XML format if the message size is greater than 4000 bytes.

  • PIN_FLD_MESG_ID — Contains the unique message ID generated by the Synchronization Queue DM database queue.

  • PIN_FLD_ENQ_TIME — Specifies the time the message was sent to the Synchronization Queue DM database queue.

About Event Status Flags

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

  • READY indicates that the event has not been retrieved by the external CRM application.

  • PROCESSED indicates that the event was retrieved by the external CRM application. The Oracle Queue Monitor process (QMn) removes the event from the database queue after a configurable amount of time.

You can check the status of events in the Synchronization Queue DM database queue by running a report. For information, see "Generating Queue Reports".

About Retrieving Specific Events from the Synchronization Queue DM Database Queue

Business event names are defined in the base tags of the payload configuration file (payloadconfig_crm_sync.xml). When an event is sent to the Synchronization Queue DM database queue, the business event name is stored in the database queue table in the CORRID field. The external CRM application can check for the name in the CORRID field to identify the type of data in the queued messages and determine whether to retrieve the message.

For example, if the name of a business event is ProductInfoChange, the message contains information about changes to a charge offer. If the external CRM application needs to update its charge offer information, it can retrieve the event. Otherwise, it can ignore the event.

Note:

The CORRID field is limited to 128 characters. If you customize the payloadconfig_crm_sync.xml file, be sure to use business event names that have fewer than 128 characters.