Synchronizing Pricing Data between the BRM Database and External CRMs

About Synchronizing Pricing Data

You can synchronize the following pricing data between BRM and your external CRM applications:

Charge offers, including their associated provisioning tag details
Simple discounts in discount offers
Real-time chargeshare offers
Bundles
Packages
Package lists

When you start a CRM integration, you can export your pricing data from BRM to external CRM applications in a batch using the pin_export_price utility. After BRM and the external CRM application are integrated, BRM can send pricing data changes to the external CRM application in real-time.

About Synchronizing Simple Discounts

When you create or modify discounts in discount offers, BRM evaluates whether the discounts 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.
A flag indicating whether the discount is a percentage (P) or an absolute (A) value.

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

About the Synchronization Process for Pricing Data

BRM synchronizes pricing data with external CRM applications using the Oracle DM and the Enterprise Applications Integration (EAI) framework, consisting of the event notification system and the Payload Generator External Module (EM). The Oracle DM and EAI framework work together to publish changes to a central Oracle Advanced Queuing (AQ) database queue. External CRM applications can then retrieve the pricing data directly from the AQ queue.

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

Figure 44-1 Pricing Data Synchronization Process

Description of "Figure 44-1 Pricing Data Synchronization Process"

Pricing data is synchronized in the following way:

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 after changes to any of the following: charge offers, discount offers, chargeshare offers, bundles, packages, and package lists.
- In a batch: The pin_export_price utility generates the notification events. When you run the utility, it retrieves pricing data from the BRM database and generates a notification event for each object retrieved. See "Exporting Pricing Data in a Batch".
The BRM event notification system recognizes the notification event, which triggers a call to a synchronization opcode.
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.
The Payload Generator EM collects events in its payload until they compose a complete business event.
When the business event is complete, the Payload Generator EM sends it to the Oracle DM.
The Oracle DM sends the business event to an Oracle AQ database queue.
The external CRM application retrieves the business event from the 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 charge offers, discount offers, chargeshare offers, bundles, packages, and package lists 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 pricing data, the event notification system listens for one of these events and then calls the Payload Generator EM. You define the notification events that trigger calls to the Payload Generator EM using the BRM_home/sys/data/config/pin_notify_crm_sync file.

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 BRM events until they generate a complete business event, generates the data necessary to publish them, and sends them to the Oracle DM.

The data required to create a complete business event is defined in the payload configuration file (BRM_home/sys/eai_js/payloadconfig_ifw_sync.xml). The default file includes definitions for the following business events: ProductInfoChange, DiscountInfoChange, SponsorshipInfoChange, AccountStatusUpdate, AccountInfoChange, and InstallmentNotification.

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

About the Oracle DM and Pricing Synchronization

The Oracle DM is responsible for publishing data to the Oracle AQ database queue. You define which business events the Oracle DM sends to the AQ database queue using the BRM_home/sys/dm_oracle/aq_event_map file. To configure the aq_event_map file, see "Mapping Business Events to Database Queues".

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

Determines whether to send the event to the AQ database queue by checking the aq_event_map file.
Publishes the business event's contents to the AQ database queue as an XML message.
Sets the event in the AQ database queue to a READY state. For information, see "About Event Status Flags".

Note:

If the Oracle DM is offline for an extended period, you can use the pin_export_price utility to synchronize pricing data in batches. For more information, see "Exporting Pricing Data in a Batch".

About the AQ Database Queue

The AQ database queue is used to pass business events from the Oracle DM to the external CRM application. The Oracle DM sends business events to the AQ 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 Oracle DM continues to send business events to the AQ queue. After the external CRM application restarts, it retrieves the business events from the AQ queue.
If the Oracle DM terminates, the external CRM application continues to retrieve business events already in the AQ queue.

About the Structure of Queued Messages

The Oracle DM publishes the business event to the AQ database queue. 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 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 exceeds 4000 bytes.
PIN_FLD_MESG_ID: Contains the unique message ID generated by the AQ queue.
PIN_FLD_ENQ_TIME: Specifies the time the message was sent to the AQ queue.

About Event Status Flags

Events in the AQ database queue are set to the following statuses:

READY indicates that the event has not been dequeued.
PROCESSED indicates that the event has been retrieved. The Oracle Queue Monitor process (QMN) removes the event from the queue after a configurable amount of time.

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

About Retrieving Specific Events from the AQ Database Queue

You define business event names in the base tags of the payload configuration file (payloadconfig_ifw_sync.xml). When the Oracle DM sends an event to the AQ database queue, it stores the business event name 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. The external CRM application can retrieve the event if it needs to update its charge offer information. Otherwise, it can ignore the event.

Note:

The CORRID field is limited to 128 characters. If you customize the payloadconfig_ifw_sync.xml file, use business event names with fewer than 128 characters.