The Oracle Communications Billing and Revenue Management (BRM) Elastic Charging Engine (ECE) notification framework publishes notification events which can be used by external systems. For example, for policy-driven charging, policy-related software programs (policy clients), can use the data in notification events for sending information to the Policy and Charging Rules Function (PCRF). This chapter describes the purpose of publishing notification events and how the notification framework publishes them.
See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for information about configuring the service events that trigger the publishing of notification events.
ECE supports in-session notifications and external asynchronous notifications. See the following topics for information about each notification type:
You can enable or disable ECE from publishing external notifications for various events that occur in the ECE system. You can enable or disable ECE from sending in-session notifications as part of the usage response. See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for more information.
In-session notifications are returned in the usage response to the network mediation system. The online mediation session controller uses the in-session notification information and the customer preferences to determine the messages that must be sent to the customer.
ECE supports in-session notifications for the Advice of Charge (AoC) charging scenario in addition to supporting asynchronous external notifications for AoC. AoC notifications include the operation types to indicate when the notification is triggered. For USAGE operations, the AoC notifications include the subtype. See "About Advice of Charge" for information about AoC. ECE also supports in-session notifications for threshold breach scenarios when a customer's balance breaches a credit threshold value.
For details about in-session notifications returned in the usage response for AoC, refer to the documentation for oracle.communication.brm.charging.messages.usage in BRM Elastic Charging Engine Java API Reference.
ECE supports in-session notifications for policy-driven charging by publishing asynchronous external notifications during a policy session. Policy clients consume the data in these notifications for sending in-session notifications to the PCRF.
For details about in-session notifications returned in the policy response for policy-driven charging, refer to the documentation for oracle.communication.brm.charging.messages.policy in BRM Elastic Charging Engine Java API Reference.
When certain events or state changes occur in ECE, ECE can publish asynchronous external notifications to a JMS queue. The external notifications contain the information about the event. For example, when a customer breaches one of his credit thresholds, ECE publishes the ThresholdBreachServiceEvent which contains the information about the breach such as the balance element (currency or non-currency) and the quantity of the breach (amount or percentage).
The external notification payload that is published into the JMS queue has a well defined XML format. External systems parse the XML strings of the payload to obtain the required information such as the balance element and current balance and so on. External notifications are published as XML strings in the XML structure shown by the ECE_Home/oceceserver/config/Notification.xsd file, where ECE_Home is the directory in which you installed ECE.
For samples of XML strings published for different notification types, see the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide.
Examples of client applications that would obtain information from external notifications for their own processing are:
The network mediation system can use data in the external notification with customer policy data for implementing network policy control.
Oracle Communications Billing and Revenue Management (BRM) can use data in the external notification for running billing for a specific customer. BRM Gateway sends the relevant data to BRM in the external notification for triggering billing.
BRM can use data in the external notification for updating the first usage validity period of a customer's balance item. BRM Gateway synchronizes the first-usage validity settings from ECE to BRM when first-usage notifications are configured.
Specific ECE service events trigger ECE to publish external notifications. You can enable or disable each of the service events from triggering external notifications. See "About Service Events that Trigger External Notifications" for information about the service events for which ECE supports publishing external notifications.
You must configure JMS credentials for publishing external notifications. See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for instructions on configuring the JMS credentials in ECE.
See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for information about enabling and disabling external notifications.
External notifications are published by the notification framework. See "About the Notification Framework" for information about configuring ECE to publish external notifications for various service events.
ECE sends notifications to BRM for synchronizing data and triggering required processes such as billing. For more information, see the discussion of implementing ECE with BRM in BRM Elastic Charging Engine Implementation Guide.
The following notifications are typically enabled as a best practice when integrating with the BRM system:
Billing notifications
Trigger billing in BRM for a specific customer (BillingServiceEvent).
When a subscriber starts a charging session near the time billing is set to run in BRM, ECE creates the BillingNotificationServiceEvent service event. If notifications are enabled for this service event, when this events occurs, the notification framework publishes the BillingNotificationServiceEvent notification to the JMS notification queue.
When a BillingNotificationServiceEvent notification is published to the JMS notification queue, BRM Gateway, which listens on the queue, uses the data from the event to create a BRM request. The BRM request calls an opcode in BRM to trigger billing in BRM for the customer.
Triggering billing for a customer when the customer starts a charging session near the time billing is set to run enables BRM to apply new cycle grants to the customer balance and to process any discounts or folds applied during billing. BRM then sends the information to ECE, which updates the customer balance in ECE. In this way, resources associated with these operations are replenished in ECE, which decreases the risk of terminating the charging session for lack of resources if resources were low in the account when the charging session began. It is a best practice to enable notifications for this service event (setting to ASYNCHRONOUS).
For offline charging, when a subscriber starts a charging session during the delayed billing period, ECE rejects the request for charging and sends a notification to BRM to trigger the partial billing. If new billing notifications are triggered for the same accounting cycle, ECE detects duplicate notifications and sends the notifications only if they are not sent earlier for the same accounting cycle.
External notifications are published as XML strings in the XML structure shown by the ECE_home/oceceserver/config/Notification.xsd file.
Replenish POID notifications
To track a customer's balance impacts for a given billable item type, ECE maps the product type and event type combinations in a usage request to the relevant item type. ECE sends information to BRM so that it can obtain the POIDs when it does not have enough that can be used (ReplenishPoidIDNotificationEvent).
Life Cycle Transition notifications
When the life cycle state changes in ECE, this notification is used to synchronize the state with BRM. If life cycle management is enabled in ECE, this notifies BRM of any changes in the subscriber life cycle state (LifeCycleTransitionServiceEvent).
First Usage Validity Initialization notifications
Synchronize validity of first usage resources from ECE to BRM (FirstUsageValidityInitServiceEvent).
External Top Up notifications
Update the balances in ECE and send notifications to BRM (ExternalTopUpNotificationEvent).
When changes occur to policy counters (balances) or policy-related subscriber preferences that are associated with products that have an active policy session, ECE publishes asynchronous notifications to the JMS notification queue. A policy client interacting with ECE subscribes for receiving the policy notifications when it initiates the policy sessions. The policy client uses the information in the notifications to send Sy and Sp messages to the PCRF.
ECE publishes policy notifications for products that have an active Sy session if the balance threshold is breached because of a usage session, or a balance top-up, or a subscription activity. ECE does not generate notifications for threshold breaches that occur outside of an Sy session (when the customer is not using the product) as these breaches could generate unnecessary notifications. For example, it would be a waste of system resources for ECE to publish notifications for breaches caused by monthly resets of resource allowances for products that are not being used by customers.
For Java API descriptions of the service event objects published as policy notifications, refer to the documentation for oracle.communication.brm.charging.messages.policy in BRM Elastic Charging Engine Java API Reference.
For information about the XML data structure of ECE policy notifications, see the discussion about integrating ECE with policy clients in BRM Elastic Charging Engine Implementation Guide.
ECE publishes SpendingLimit notifications when it detects a policy threshold breach. ECE generates a SpendingLimit notification when usage results in a threshold breach of pre-defined policy tiers. A threshold breach causes ECE to send a label tagging this condition to the PCRF. Based on this label, the PCRF will take a policy action (such as request the PCEF to throttle bandwidth, or block a service, and so on).
The customer balance change could occur because of any of the following:
Usage requests coming from the network mediation system
Update requests coming from BRM (as the customer management system)
Top ups coming from top-up systems
ECE checks for spending limit breaches and generates notifications for any breaches for products that have an active policy session (Sy session).
ECE administers threshold checks during the usage processing flow (in-session) and during the balance update flow (off-session) based on the current balance and consumed reservation of the customer balance.
ECE publishes SubscriberPreference notifications during an update from BRM for the customer preferences present in a particular product. For example, if a CSR adds a preference to a customer's profile, modifies an existing preference, or adds a new type of customer preference. ECE publishes SubscriberPreference notifications only for active subscriptions of Sp data (SubscribeNotificationRequest).
When certain state changes occur in the ECE system, service events are created. When configured, the service events can trigger the publishing of notification events (asynchronous external notifications). See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide.
When the following service events occur, they can trigger the notification framework to publish associated external notifications to a JMS notification queue.
AdviceOfChargeServiceEvent
See "About Advice of Charge" for information.
FirstUsageValidityServiceEvent
See "About First-Usage Validity" for information.
ThresholdBreachServiceEvent
See "About Breach-Type Notifications" for information.
TopUpNotificationServiceEvent
See "About Top-Up Notifications" for information.
BillingNotificationServiceEvent
See "About Billing Notifications" for information.
ReplenishPoidId
See "About Notifications Used by BRM" for information.
ECE creates top-up notifications in support of Server Initiated Re-auth Requests (RAR). See "Server Initiated Reauthorization Requests" for details on how ECE can support RAR.
See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for information about configuring this notification.
When a customer starts a charging session near the time billing is set to run in BRM, ECE publishes the BillingNotificationServiceEvent service event. If notifications are enabled for this event, when this events occurs, the notification framework publishes the BillingNotificationServiceEvent notification to the JMS notification queue.
See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for information about configuring this notification.
When performing usage-charging, ECE can generate notifications related to breaches in credit limits and thresholds. A client application can use this information for sending a notification back to the customer according to the customer's user preferences. For example, an email or an SMS could be sent to inform the customer that a credit threshold has been breached.
If notifications are configured for breaches in credit limits and thresholds, when the events occurs, the notification framework publishes a notification for each type of event to the JMS notification queue.
See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for information about configuring notifications.
For information about policy-driven threshold notifications, see "About Notifications Used by Policy Clients".
When a customer's balance breaches a credit threshold value, ECE publishes the ThresholdBreachServiceEvent notification with information about the breach such as the threshold amount or threshold percentage that was breached.
The notification framework publishes in-session notifications and asynchronous external notifications. When certain state changes occur in the ECE system, service events are created by the Elastic Charging Server. The notification framework, based on how you configure ECE, puts the data from these events either in the usage response (for an in-session notification), or into a notification event (for an external notification), or does both.
The notification framework publishes external notifications asynchronously. To publish external notifications, the notification framework transforms the Java payload of ECE service events into notification events that have a well defined XML payload. These notification events can be consumed by other systems for further processing.
The notification framework publishes external notifications to a JMS topic on a remote JMS server. You must set up a notification topic on a remote JMS server and configure the JMS credentials in ECE to access that server. See the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide for instructions on configuring the JMS credentials in ECE.
The notification framework is not used to receive messages from external systems.
The notification framework transforms the Java payload of the ECE service event into XML. The payloads that are published into the JMS notification queue (JMS topic) are XML strings in the XML structure shown by the ECE_Home/oceceserver/config/Notification.xsd file.
For samples of XML strings published into the JSM notification queue for different notification types, see the discussion of configuring notifications in BRM Elastic Charging Engine Implementation Guide.