1 Understanding the Synchronization Queue Data Manager

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

Important:

The Synchronization Queue DM is an optional feature that requires a separate license.

About Synchronizing Pricing Data

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

• Products, including their associated provisioning tag details.

• Real-time discounts with simple pipeline discount models. See "About Simple Discount Models".

• Real-time chargeshares.

When you start a CRM integration, you can export all of your existing products, discounts, and chargeshares 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 product, discount, and chargeshare changes to the external CRM application in real time.

About Simple Discount Models

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

• The discount mode is parallel or sequential.

• The event type is a purchase or cycle event.

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

• The DRUM expression is ”TotalC”.

• The discount model contains only one discount configuration, one discount step, and one discount balance impact.

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

• The base expression is ”TotalC”.

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

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

About the Data Synchronization Process

BRM synchronizes products, discounts, and chargeshares 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. External CRM applications can then retrieve data directly from the Oracle AQ database queue.

Note:

To use the Synchronization Queue DM, you must purchase and install EAI Manager. For more information, see "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 Data Synchronization Process''

Products, discounts, and chargeshares 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 product changes, a discount changes, or a chargeshare changes.

   • In a batch: The pin_export_price utility generates the notification events. When you run the utility, it retrieves products, discounts, and chargeshares 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 Oracle AQ database queue. See "About the Oracle AQ Database Queue".

6. The external CRM application retrieves the business event from the Oracle AQ 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 products, discounts, and chargeshares 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 products, discounts, and chargeshares, 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 product information changes, such as product pricing changes.

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

• SponsorshipInfoChange: Defines the events related to chargeshare (/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 Oracle AQ database queue. You define which business events are sent to the Oracle AQ 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 Oracle AQ database queue by checking the aq_queuenames file.

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

3. Sets the event in the Oracle AQ 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 product and discount CRM data in batches. For more information, see "Exporting Pricing Data in a Batch".

About the Oracle AQ Database Queue

The Oracle AQ 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 Oracle AQ 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 Oracle AQ database queue. After the external CRM application restarts, it retrieves the business events from the Oracle AQ database queue.

• If the Synchronization Queue DM terminates, the external CRM application continues to retrieve business events already in the Oracle AQ 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 Oracle AQ 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 Oracle AQ database queue.

• PIN_FLD_ENQ_TIME: Specifies the time the message was sent to the Oracle AQ database queue.

About Event Status Flags

Events in the Oracle AQ 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 Oracle AQ database queue after a configurable amount of time.

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

About Retrieving Specific Events from the Oracle AQ 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 Oracle AQ database queue, the business event name is stored in the Oracle AQ 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 product. If the external CRM application needs to update its product information, it can retrieve the event. Otherwise, it can ignore the event.

Important:

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.