This chapter provides instructions for configuring notifications published by Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).
You can configure ECE to publish notifications.
All notifications are disabled by default. You must enable the publishing of notifications. See "Enabling External Notifications in ECE" for information.
You use the JMX interface, such as JConsole, to enable specific types of notifications. See "Configuring Notifications for Online Charging" for information.
The allowed values for configuring notification types are follows:
NONE: No notification is sent.
ASYNCHRONOUS: An asynchronous notification is sent.
PIGGYBACK: Events are included as an in-session notification on the usage response message (send as a block on the usage response).
ASYNC_PIGGYBACK: Both asynchronous and in-session notifications are sent.
Only Advice of Charge (AoC) service events and threshold breach service events can be configured for in-session notifications (PIGGYBACK). All other service events must be configured for ASYNCHRONOUS notifications when notifications are enabled for them.
For ECE to publish external notifications, configure the JMS credentials for the JMS server on which the notification queue (JMS topic) resides. See "Configuring JMS Credentials for Publishing External Notifications".
To publish external notifications of any type, ECE must be enabled for publishing external notifications.
To verify that ECE is enabled for publishing external notifications, do the following:
Open the ECE_home/oceceserver/config/charging-cache-config.xml file, where ECE_home is the directory in which you installed ECE.
For the ServiceContext module, verify that the following entry is used for the cache-store configuration:
<init-param>
<param-name>cache-store</param-name>
<param-value>oracle.communication.brm.charging.notification.internal.coherence.AsynchronousNotificationPublisher
</param-value>
ECE is enabled for publishing external notification.
Save the file.
For ECE to publish external notifications, it needs the JMS credentials for each JMS WebLogic server on which an ECE notification queue (JMS topic) resides in your system.
To configure the JMS credentials for publishing external notifications:
Open the ECE_home/oceceserver/config/JMSConfiguration.xml file.
Locate the <MessagesConfigurations> section.
Specify values for the parameters in the following JMSDestination name sections:
NotificationQueue: Read by the ECE charging nodes.
BRMGatewayNotificationQueue: Read by BRM Gateway.
DiameterGatewayNotificationQueue: Read by Diameter Gateway.
Note:
Do not change the value of the JMSDestination name parameter.Each JMSDestination name section contains the following parameters:
HostName: Deprecated but remains in ECE for backward compatibility. To specify the host names of the WebLogic servers on which the JMS topics reside, use the ConnectionURL parameter, which takes precedence over HostName.
Port: Deprecated but remains in ECE for backward compatibility. To specify the port numbers on which the WebLogic servers reside, use the ConnectionURL parameter, which takes precedence over Port.
UserName: Specify the user for logging on to the WebLogic server.
This user must have write privileges for the JMS topic.
Password: Specify the password for logging on to the WebLogic server.
When you install ECE, the password you enter is encrypted and stored in the keystore. If you change the password, you must run a utility to encrypt the new password before entering it here. See the discussion about encrypting new passwords in BRM Elastic Charging Engine System Administrator's Guide.
ConnectionFactory: Specify the connection factory used to create connections to the JMS topic on the WebLogic server to which ECE publishes notification events.
You must also configure settings in Oracle WebLogic Server for the connection factory. See "Configuring a WebLogic Server Connection Factory for a JMS Topic".
QueueName: Specify the JMS topic that holds the published external notification messages.
Protocol: Deprecated but remains in ECE for backward compatibility. To specify the wire protocol used by the WebLogic servers, use the ConnectionURL parameter, which takes precedence over Protocol.
ConnectionURL: Specify one or more URLs that applications can use to connect to the JMS WebLogic servers on which your ECE notification queues (JMS topics) reside.
Note:
When this parameter contains values, it takes precedence over the deprecated HostName, Port, and Protocol parameters.Use the following URL syntax:
[t3|t3s|http|https|iiop|iiops]://address[,address]. . .
where:
– t3, t3s, http, https, iiop, or iiops is the wire protocol used.
For a WebLogic server, use t3.
– address is hostlist:portlist.
– hostlist is hostname[,hostname.]
– hostname is the name of a WebLogic server on which a JMS topic resides.
– portlist is portrange[+portrange.]
– portrange is port[-port.]
– port is the port number on which the WebLogic server resides.
Examples:
t3://hostA:7001 t3://hostA,hostB:7001-7002
The preceding URL is equivalent to all the following URLs:
t3://hostA,hostB:7001+7002 t3://hostA:7001-7002,hostB:7001-7002 t3://hostA:7001+7002,hostB:7001+7002 t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002
Note:
If multiple URLs are specified for a high-availability configuration, an application randomly selects one URL and then tries the others until one succeeds.ConnectionRetryCount: Specify the number of times a connection is retried after it fails.
This applies only to clients that receive notifications from BRM.
ConnectionRetrySleepInterval: Specify the number of milliseconds between connection retry attempts.
InitialContextFactory: Specify the name of the initial connection factory used to create connections to the JMS topic queue on each WebLogic server to which ECE will publish notification events.
RequestTimeOut: Specify the number of milliseconds in which requests to the WebLogic server must be completed before the operation times out.
KeyStorePassword: If SSL is used to secure the ECE JMS queue connection, specify the password used to access the SSL keystore file.
KeyStoreLocation: If SSL is used to secure the ECE JMS queue connection, specify the full path to the SSL keystore file.
Save and close the file.
Configuring a WebLogic Server Connection Factory for a JMS Topic
To configure a WebLogic server connection factory for a JMS topic:
Log on to a WebLogic server on which one of your JMS topics resides.
Log in to WebLogic Server Administration Console.
From the JMS modules list, select the connection factory that applies to the JMS topic used for ECE notifications.
In the Transactions tab, set the Transaction Timeout to 2147483647.
For information about setting up a JMS topic on a WebLogic server, see the Oracle WebLogic Server documentation.
Considerations for Using a JMS Provider Other Than Oracle WebLogic Server
If you use a JMS provider other than Oracle WebLogic Server for publishing ECE notifications, do the following on the driver machine:
Copy the other JMS provider's client JARs to the ECE_home/oceceserver/lib directory.
Rename the other JMS provider's JAR file to wlthint3client.jar.
Update the ECE_home/oceceserver/config/JMSConfiguration.xml file to specify the InitialContextFactory and protocol information of the other JMS provider.
After configuring JMS configuration settings on the driver machine, you can deploy the updates onto a running ECE system.
To deploy JMS configuration settings onto a running ECE system:
Log on to the driver machine.
Change directory to the ECE_home/oceceserver/bin directory.
Start ECC.
./ecc
Run the sync command to deploy the ECE installation onto server machines:
groovy:000> sync
The sync command copies the relevant files of the ECE installation (which includes your JMS configuration setting updates), onto the server machines you have defined to be part of the ECE cluster.
Open the topology file (ECE_home/oceceserver/config/eceTopology.conf) and define the following nodes at the top of the file (before the charging server nodes):
Updater nodes
Gateway nodes
Formatter nodes
These processes must be restarted before restarting the charging server nodes.
Run the rollingUpgrade command to perform a rolling restart of ECE nodes that are currently running on your topology.
groovy:000> rollingUpgrade
One by one (in the order they are listed in the topology file), each currently running node is brought down, updated, and joined back to the cluster.
When you run the rollingUpgrade command with no parameters specified, all running nodes are updated (charging server nodes, data-loading utility nodes, data updater nodes, and so on) except for simulator nodes (nodes that have the role simulator).
See the following topics to configure the notification that supports the charging business rule you want to configure:
For more information about configuring each notification, see the NotificationConfigMBean of the BizParamConfigMBean package in BRM Elastic Charging Engine Java API Reference.
This section describes how to configure top-up notifications.
See the discussion about notifications in BRM Elastic Charging Engine Concepts for a description of top-up notifications.
To configure top-up notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Specify one of the following values for the topUpNotificationMode attribute:
To disable the generation of top-up notifications, enter NONE.
An external notification is not generated when the TOP_UP_NOTIFICATION_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the TOP_UP_NOTIFICATION_EVENT service event is created, enter ASYNCHRONOUS.
This section describes how to configure threshold breach notifications.
See the discussion about notifications in BRM Elastic Charging Engine Concepts for a description of threshold breach notifications.
To configure threshold breach notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Specify one of the following values for the thresholdBreachNotificationMode attribute:
To disable the generation of threshold breach notifications, enter NONE.
An external notification is not generated when the THRESHOLD_BREACH_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the THRESHOLD_BREACH_EVENT service event is created, enter ASYNCHRONOUS.
To generate an in-session notification and return it in the usage response message when the THRESHOLD_BREACH_EVENT service event is created, enter PIGGYBACK.
To generate both an external and in-session notification when the THRESHOLD_BREACH_EVENT service event is created, enter ASYNC_PIGGYBACK.
Expand charging.server.
Expand Attributes.
Specify one of the following values for the thresholdBreachNotificationMode attribute:
To generate the threshold breach notification only when the session is terminated, enter ON_TERMINATE.
To generate the threshold breach notification when the customer's balance breaches the credit threshold value during the session, enter ONGOING.
This section describes how to configure credit limit ceiling breach notifications.
See the discussion about notifications in BRM Elastic Charging Engine Concepts for a description of credit limit ceiling breach notifications.
To configure credit limit ceiling breach notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Specify one of the following values for the creditCeilingBreachNotificationMode attribute:
To disable the generation of credit limit ceiling breach notifications, enter NONE.
An external notification is not generated when the CREDIT_CEILING_BREACH_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the CREDIT_CEILING_BREACH_EVENT service event is created, enter ASYNCHRONOUS.
This section describes how to configure credit limit floor breach notifications.
See the discussion about notifications in BRM Elastic Charging Engine Concepts for a description of credit limit floor breach notifications.
To configure credit limit floor breach notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Specify one of the following values for the creditFloorBreachNotificationMode attribute:
To disable the generation of credit limit floor breach notifications, enter NONE.
An external notification is not generated when the CREDIT_FLOOR_BREACH_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the CREDIT_FLOOR_BREACH_EVENT service event is created, enter ASYNCHRONOUS.
This section describes how to configure advice-of-charge notifications.
See the chapter about notifications in BRM Elastic Charging Engine Concepts for a description of advice-of-charge notifications.
To configure advice-of-charge notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Specify one of the following values for the adviceOfChargeNotificationMode attribute:
To disable the generation of advice-of-charge notifications, enter NONE.
An external notification is not generated when the ADVICE_OF_CHARGE_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the ADVICE_OF_CHARGE_EVENT service event is created, enter ASYNCHRONOUS.
To generate an in-session notification and return it in the usage response message when the ADVICE_OF_CHARGE_EVENT service event is created, enter PIGGYBACK.
To generate both an external and in-session notification when the ADVICE_OF_CHARGE_EVENT service event is created, enter ASYNC_PIGGYBACK.
This section describes how to configure notifications that are used for policy-driven charging. A client that interacts with the Policy and Charging Rules Function (PCRF), such as Diameter Gateway, consumes these notifications to retrieve data that it then sends to the PCRF.
See the chapter about notifications in BRM Elastic Charging Engine Concepts for a description of spending limit notifications.
To configure spending limit notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Specify values for the following attributes:
aggregatedSpendingLimitNotificationMode: Enter one of the following values:
To disable the generation of aggregate spending limit notifications, enter NONE.
An external notification is not generated when the AGGREGATED_SPENDING_LIMIT_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the AGGREGATED_SPENDING_LIMIT_EVENT service event is created, enter ASYNCHRONOUS.
spendingLimitNotificationMode: Enter one of the following values:
To disable the generation of spending limit notifications, enter NONE.
An external notification is not generated when the SPENDING_LIMIT_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the SPENDING_LIMIT_EVENT service event is created, enter ASYNCHRONOUS.
subscriberPreferenceUpdateNotificationMode: Enter one of the following values:
To disable the generation of subscriber preference update notifications, enter NONE.
An external notification is not generated when the SUBSCRIBER_PREFERENCE_UPDATE_EVENT service event is created.
To generate an external notification and send it to a notification queue (JMS topic) when the SUBSCRIBER_PREFERENCE_UPDATE_EVENT service event is created, enter ASYNCHRONOUS.
Each external notification can include some general information in a header. You can configure the header to include the information (such as public user identity) that is needed by external systems for identifying and processing the notifications.
To configure the header for an external notification:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notificationHeaderConfigurations.
Expand Operations.
Select setAttributes.
Specify values for the following parameters:
eventType. Enter the service event type for the external notification. The following are the supported service event types:
THRESHOLD_BREACH_EVENT
AGGREGATED_THRESHOLD_BREACH_EVENT
ADVICE_OF_CHARGE_EVENT
CREDIT_FLOOR_BREACH_NOTIFICATION_EVENT
CREDIT_CEILING_BREACH_NOTIFICATION_EVENT
SPENDING_LIMIT_NOTIFICATION_EVENT
AGGREGATED_SPENDING_LIMIT_NOTIFICATION_EVENT
TOP_UP_NOTIFICATION_EVENT
RAR_NOTIFICATION_EVENT
SUBSCRIBER_PREFERENCE_UPDATE_EVENT
CUSTOM_EVENT
COMMON_HEADER_ATTRIBUTES
To configure a header which is common to all the external notifications, enter COMMON_HEADER_ATTRIBUTES.
attributes. Enter the name and xpath of the attribute that you want to add to the header in the following format:
AttributeName://xpath
where xpath is the path to access the attribute in the XSD file. For example, if you want to add PublicUserIdentity to the header and if it is the child element of the PublicUserIdentities element in the XSD file, then you enter the xpath as PublicUserIdentities/PublicUserIdentity. For xpath of the attributes used in external notifications, see the ECE_home/oceceserver/config/Notification.xsd file.
Note:
If you are configuring a header which is common to all the external notifications, enter only the attribute (for example, NotificationType, OperationType, or version) that is common to all the external notifications.To add multiple attributes to the header, use the following format:
AttributeName1://xpath1,AttributeName2://xpath2,...
For example:
PublicUserIdentity://PublicUserIdentities/PublicUserIdentity,Operationtype://OperationType
Click the setAttributes button.
The attributes are added to the notification header.
For information about configuring notifications that ECE publishes for BRM, see Configuring Notifications for BRM.
You can configure ECE to enrich external notifications with subscriber preference information.
BRM enables you to manage how each subscriber prefers to receive notifications from the network. For example, you can specify that a subscriber wants to receive notifications in French (Language preference) via SMS text messages (Channel preference). All subscriber preferences that are set for customers in BRM are also stored in ECE.
You can configure ECE to enrich the following types of ECE external notifications with subscriber preference information:
Threshold breach notifications
Aggregated threshold breach notifications
Advice of Charge notifications
Credit limit ceiling breach notifications
Credit limit floor breach notifications
Subscriber life cycle state transition notifications
First usage validity initialization notifications
You can configure ECE to enrich each of the preceding external notifications with all subscriber preferences or with a subset of subscriber preferences.
If the same subscriber preference is defined as a customer-level preference and as a product-level (service-level) preference, ECE uses the product-level preference. If a subscriber preference is not specified at the product-level but is specified at the customer level, ECE uses the customer-level subscriber preference.
To configure ECE to enrich external notifications with subscriber preference information:
Get the list of subscriber preference names set in your BRM system.
When configuring ECE to enrich the external notifications with a subset of subscriber preferences, you must enter the name of the subscriber preferences as you previously set it in your BRM system.
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Set the subscriberPreferenceUpdateNotificationMode attribute to ASYNCHRONOUS.
Select a notification type whose messages you want to enrich with subscriber preference information.
Set it to ASYNCHRONOUS.
Expand Operations.
Select setNotificationEnrichmentConfig.
Specify values for the following parameters:
notificationEnrichType: Enter subscriberPreferences.
listOfEnrichNameValues: Enter one of the following values:
No value: (Default) External notifications are not enriched with subscriber preferences.
Individual subscriber preferences: External notifications are enriched with a subset of subscriber preferences. Enter the name of each preference, separated by commas. The names must match the preference names set in your BRM system.
ALL: External notifications are enriched with all the customer's subscriber preferences.
Click the setNotificationEnrichmentConfig button.
For each notification type that you have enabled to be enriched with subscriber preference information, ECE publishes subscriber preference information listed in the SubscriberPreferences block of the external notification messages.
The following is an example of the SubscriberPreferences block for a threshold breach notification that is enriched with the language subscriber preference of the customer.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <Notification> <NotificationType>THRESHOLD_BREACH_EVENT</NotificationType> <PublicUserIdentities> <PublicUserIdentity>6500000001</PublicUserIdentity> </PublicUserIdentities> <BalanceElementId>840</BalanceElementId> <BalanceElementCode>USD</BalanceElementCode> <CurrentBalance>-3.00</CurrentBalance> <ThresholdAmount>-4</ThresholdAmount> <ThresholdPercent>98.0</ThresholdPercent> <BreachDirection>THRESHOLD_BREACH_UP</BreachDirection> <DuplicateEvent>False</DuplicateEvent> <SubscriberPreferences> <SubscriberPreference PublicUserIdentity="6500000001:VOICE"> <SubscriberPreferencesInfo> <PreferenceName>Language</PreferenceName> <PreferenceValue>French</PreferenceValue> </SubscriberPreferencesInfo> </SubscriberPreference> </SubscriberPreferences> </Notification>
This section shows samples of XML strings that ECE publishes into the JSM notification queue for different notification types.
THRESHOLD_BREACH_EVENT (Breach Direction Up)
The payload published for a threshold breach (breach direction up) uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<CreditThresholdBreachNotification>
<NotificationType>THRESHOLD_BREACH_EVENT</NotificationType>
<PublicUserIdentities>
<PublicUserIdentity>123</PublicUserIdentity></PublicUserIdentities>
<BalanceElementId>840</BalanceElementId>
<BalanceElementCode>USD</BalanceElementCode>
<CurrentBalance>-4.00</CurrentBalance>
<ThresholdAmount>-4.5</ThresholdAmount>
<ThresholdPercent>55.0</ThresholdPercent>
<BreachDirection>THRESHOLD_BREACH_UP</BreachDirection>
<AlertType>2</AlertType>
<Reason>0x01</Reason>
<OperationType>USAGE</OperationType>
<SubOperationType>INITIATE</SubOperationType>
</CreditThresholdBreachNotification>
</Notification>
THRESHOLD_BREACH_EVENT (Breach Direction Down)
The payload published for a threshold breach (breach direction down) uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<CreditThresholdBreachNotification>
<NotificationType>THRESHOLD_BREACH_EVENT</NotificationType>
<PublicUserIdentities>
<PublicUserIdentity>123</PublicUserIdentity></PublicUserIdentities>
<BalanceElementId>840</BalanceElementId>
<BalanceElementCode>USD</BalanceElementCode>
<CurrentBalance>-9.00</CurrentBalance>
<ThresholdAmount>-8.0</ThresholdAmount>
<ThresholdPercent>20.0</ThresholdPercent>
<BreachDirection>THRESHOLD_BREACH_DOWN</BreachDirection>
<AlertType>2</AlertType>
<Reason>0x01</Reason>
<OperationType>USAGE</OperationType>
<SubOperationType>INITIATE</SubOperationType>
</CreditThresholdBreachNotification>
</Notification>
AGGREGATED_THRESHOLD_BREACH_EVENT (Aggregated Based on Balance Element ID)
The payload published for an aggregated threshold breach (aggregated based on Balance Element ID) uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<AggregatedCreditThresholdBreachNotification>
<NotificationType>AGGREGATED_THRESHOLD_BREACH_EVENT</NotificationType>
<PublicUserIdentities>
<PublicUserIdentity>123</PublicUserIdentity>
</PublicUserIdentities>
<BalanceElementId>840</BalanceElementId>
<BalanceElementCode>USD</BalanceElementCode>
<CurrentBalance>-3.00</CurrentBalance>
<ThresholdAmount>[-4.5, -3.5]</ThresholdAmount>
<ThresholdPercent>[55.0, 65.0]</ThresholdPercent>
<BreachDirection>THRESHOLD_BREACH_UP</BreachDirection>
<OperationType>USAGE</OperationType>
<SubOperationType>INITIATE</SubOperationType>
</AggregatedCreditThresholdBreachNotification>
</Notification>
The payload published for a top-up uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<RARNotification>
<NotificationType>TOP_UP_NOTIFICATION_EVENT</NotificationType>
<PublicUserIdentities>
<PublicUserIdentity>123</PublicUserIdentity>
<PublicUserIdentity>456</PublicUserIdentity>
</PublicUserIdentities>
<ActiveSessions>
<ActiveSessionId>SESSION1</ActiveSessionId>
<ActiveSessionId>SESSION2</ActiveSessionId>
</ActiveSessions>
<ProductType>VOICE</ProductType>
<ProductId>test</ProductId>
<CustomerId>12345</CustomerId>
<DuplicateEvent>True</DuplicateEvent>
<OperationType>USAGE</OperationType>
<SubOperationType>UPDATE</SubOperationType>
</RARNotification>
</Notification>
The payload published for a credit limit ceiling breach uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<CreditCeilingBreachNotification>
<NotificationType>CREDIT_CEILING_BREACH_EVENT</NotificationType>
<BalanceElementId>840</BalanceElementId>
<BalanceElementCode>USD</BalanceElementCode>
<CurrentBalance>1.00</CurrentBalance>
<CreditCeiling>0</CreditCeiling>
<AlertType>2</AlertType>
<Reason>0x01</Reason>
<OperationType>USAGE</OperationType>
<SubOperationType>INITIATE</SubOperationType>
</CreditCeilingBreachNotification>
</Notification>
The payload published for a credit limit floor breach uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<CreditFloorBreachNotification>
<NotificationType>CREDIT_FLOOR_BREACH_EVENT</NotificationType>
<BalanceElementId>840</BalanceElementId>
<BalanceElementCode>USD</BalanceElementCode>
<CurrentBalance>-1.00</CurrentBalance>
<CreditFloor>0</CreditFloor>
<AlertType>2</AlertType>
<Reason>0x01</Reason>
<OperationType>USAGE</OperationType>
<SubOperationType>INITIATE</SubOperationType>
</CreditFloorBreachNotification>
</Notification>
The payload published for a billing notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<BillingNotification>
<NotificationType>BILLING_NOTIFICATION_EVENT</NotificationType>
<CustomerId>12345</CustomerId>
<BillingUnitId>2345</BillingUnitId>
<ExternalReference>1</ExternalReference>
</BillingNotification>
</Notification>
REPLENISH_POID_ID_NOTIFICATION_EVENT
The payload published for a replenish POID ID notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<ReplenishPoidIdNotification>
<NotificationType>REPLENISH_POID_ID_NOTIFICATION_EVENT</NotificationType>
<SchemaName>1</SchemaName>
<Quantity>10000</Quantity>
</ReplenishPoidIdNotification>
</Notification>
The payload published for a spending limit notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<SpendingLimitNotification>
<NotificationType>SPENDING_LIMIT_NOTIFICATION</NotificationType>
<CustomerId>340876</CustomerId>
<PublicUserIdentities>
<PublicUserIdentity>9986068473</PublicUserIdentity>
<PublicUserIdentity>login123</PublicUserIdentity>
</PublicUserIdentities>
<BalanceElementId>840</BalanceElementId>
<BalanceElementCode>USD</BalanceElementCode>
<CurrentBalance>2</CurrentBalance>
<ConsumedReservation>3</ConsumedReservation>
<Unit>MegaBytes</Unit>
<Breaches>
<OfferProfileName>Offer1</OfferProfileName>
<LabelName>Fair Usage</LabelName>
<StatusLabel>low qos</StatusLabel>
<DeltaToNextThreshold>8</DeltaToNextThreshold>
</Breaches>
<DuplicateEvent>True</DuplicateEvent>
</SpendingLimitNotification>
</Notification>
LIFE_CYCLE_TRANSITION_EVENT_TYPE
The payload published for a life cycle transition notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<LifeCycleTransitionNotification>
<NotificationType>LIFECYCLE_TRANSITION_NOTIFICATION_EVENT</NotificationType>
<PublicUserIdentities>
<PublicUserIdentity>0049100120</PublicUserIdentity>
</PublicUserIdentities>
<CustomerId>3135579</CustomerId>
<ExternalReference>1</ExternalReference>
<ProductId>3134811</ProductId>
<ProductType>TelcoGsmTelephony</ProductType>
<LifecycleState>103</LifecycleState>
<ExpirationTime>1439653419867</ExpirationTime>
<SubscriberPreferences>
<SubscriberPreference PublicUserIdentity="316-20150813-143831-0-21484--153892112-slc06bui:TelcoGsmTelephony, 0049100120:TelcoGsmTelephony">
<SubscriberPreferencesInfo>
<PreferenceName>Language</PreferenceName>
<PreferenceValue>French</PreferenceValue>
</SubscriberPreferencesInfo>
</SubscriberPreference>
</SubscriberPreferences>
</LifeCycleTransitionNotification>
</Notification>
EXTERNAL_TOP_UP_NOTIFICATION_EVENT
The payload published for a external top-up notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<ExternalTopUpNotification>
<NotificationType>EXTERNAL_TOP_UP_NOTIFICATION_EVENT</NotificationType>
<PublicUserIdentities>
<PublicUserIdentity>1000000</PublicUserIdentity>
</PublicUserIdentities>
<CustomerId>137826171</CustomerId>
<ExternalReference>1</ExternalReference>
<RequestTime>1325269800000</RequestTime>
<Id>RECHARGE_ID1</Id>
<BalanceImpact>
<ProductId>137826171</ProductId>
<ProductType>VOICE</ProductType>
<BalanceItemImpact>
<BalanceItemId>1</BalanceItemId>
<BalanceElementCode>FSEC</BalanceElementCode>
<Quantity>-10</Quantity>
<ExtendValidityFlag>false</ExtendValidityFlag>
<ValidFrom>1325269800000</ValidFrom>
<ValidTo>1388514600000</ValidTo>
</BalanceItemImpact
</BalanceImpact>
<SubscriberPreferences>
<SubscriberPreference PublicUserIdentity="1000001:VOICE, 1000000:VOICE">
<SubscriberPreferencesInfo>
<PreferenceName>Language</PreferenceName>
<PreferenceValue>French</PreferenceValue>
</SubscriberPreferencesInfo>
</SubscriberPreference>
</SubscriberPreferences>
</ExternalTopUpNotification>>
</Notification>
FIRST_USAGE_VALIDITY_EVENT_TYPE
The payload published for a first usage validity notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<FirstUsageValidityNotification>
<NotificationType>FIRST_USAGE_VALIDITY_INIT_NOTIFICATION_EVENT</NotificationType>
<CustomerId>12345</CustomerId>
<ExternalReference>1</ExternalReference>
<BalanceId>12345</BalanceId>
<validity>
<BalanceElementId>100025</BalanceElementId>
<BalanceItemId>1</BalanceItemId>
<ValidFrom>1325269800000</ValidFrom>
<ValidTo>1388514600000</ValidTo>
</validity>
<SubscriberPreferences>
<SubscriberPreference PublicUserIdentity="1000001:VOICE, 1000000:VOICE">
<SubscriberPreferencesInfo>
<PreferenceName>Language</PreferenceName>
<PreferenceValue>French</PreferenceValue>
</SubscriberPreferencesInfo>
</SubscriberPreference>
</SubscriberPreferences>
</FirstUsageValidityNotification>
</Notification>
SUBSCRIBER_PREFERENCE_NOTIFICATION_EVENT
The payload published for creating a subscriber preference notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<CreateSubscriberPreference>
<NotificationType>SUBSCRIBER_PREFERENCE_NOTIFICATION_EVENT</NotificationType>
<CustomerId>340876</CustomerId>
<ProductInfo>
<ProductId>12345</ProductId>
<PublicUserIdentities>
<PublicUserIdentity>9886753556</PublicUserIdentity>
<PublicUserIdentity>login</PublicUserIdentity>
</PublicUserIdentities>
</ProductInfo>
<SubscriberPreferencesInfo>
<PreferenceName>Language</PreferenceName>
<PreferenceValue>English</PreferenceValue>
</SubscriberPreferencesInfo>
<SubscriberPreferencesInfo>
<PreferenceName>Channel</PreferenceName>
<PreferenceValue>Email</PreferenceValue>
</SubscriberPreferencesInfo>
</CreateSubscriberPreference>
</Notification>
The payload published for modifying a subscriber preference notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<ModifySubscriberPreference>
<NotificationType>SUBSCRIBER_PREFERENCE_NOTIFICATION_EVENT</NotificationType>
<CustomerId>customer1</CustomerId>
<ProductInfo>
<ProductId>12345</ProductId>
<PublicUserIdentities>
<PublicUserIdentity>9886753556</PublicUserIdentity>
<PublicUserIdentity>login</PublicUserIdentity>
</PublicUserIdentities>
</ProductInfo>
<SubscriberPreferencesInfo>
<PreferenceName>Language</PreferenceName>
<PreferenceValue>English</PreferenceValue>
</SubscriberPreferencesInfo>
<SubscriberPreferencesInfo>
<PreferenceName>Channel</PreferenceName>
<PreferenceValue>Email</PreferenceValue>
</SubscriberPreferencesInfo>
</ModifySubscriberPreference>
</Notification>
The payload published for deleting a subscriber preference notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification>
<DeleteSubscriberPreference>
<NotificationType>SUBSCRIBER_PREFERENCE_NOTIFICATION_EVENT</NotificationType>
<CustomerId>customer1</CustomerId>
<ProductInfo>
<ProductId>12345</ProductId>
<PublicUserIdentities>
<PublicUserIdentity>9886753556</PublicUserIdentity>
<PublicUserIdentity>login</PublicUserIdentity>
</PublicUserIdentities>
</ProductInfo>
<SubscriberPreferencesInfo>
<PreferenceName>Language</PreferenceName>
<PreferenceValue>English</PreferenceValue>
</SubscriberPreferencesInfo>
<SubscriberPreferencesInfo>
<PreferenceName>Channel</PreferenceName>
<PreferenceValue>Email</PreferenceValue>
</SubscriberPreferencesInfo>
</DeleteSubscriberPreference>
</Notification>
ADVICE_OF_CHARGE_NOTIFICATION_EVENT_TYPE
The payload published for advice of charge notification uses the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Notification version="3.0.0.0.0">
<AdviceOfChargeNotification>
<NotificationType>ADVICE_OF_CHARGE_NOTIFICATION_EVENT</NotificationType>
<PublicUserIdentity>CUSTOMER1</PublicUserIdentity>
<Consumptions>
<BalanceElementId>840</BalanceElementId>
<ConsumptionQuantity>10.0</ConsumptionQuantity>
<ConsumptionUnit>Money{cur=USD}</ConsumptionUnit>
</Consumptions>
<Grants>
<BalanceElementId>840</BalanceElementId>
<GrantQuantity>1.0</GrantQuantity>
<GrantUnit>Money{cur=USD}</GrantUnit>
</Grants>
<CurrentBalance>
<BalanceElementId>840</BalanceElementId>
<CurrentBalanceQuantity>100.0</CurrentBalanceQuantity>
<CurrentBalanceUnit>Money{cur=USD}</CurrentBalanceUnit>
</CurrentBalance>
<ChargeInfo>
<OperationType>USAGE</OperationType>
<SubOperationType>UPDATE</SubOperationType>
</ChargeInfo>
</AdviceOfChargeNotification>
</Notification>