Policy event consumer
The Subscriber Policy Charging Manager (SPCM) sends out events that can be consumed by 3rd party applications and APIs. The Policy Event Consumer (PEC) allows these 3rd parties to be notified of events (see Event types) from the SPCM. These events are passed through the PEC via RabbitMQ and onto the external application or api.
An example might be that a particular application wants to know when a PLAN_EXPIRED event type has occured so the application can trigger a notification to offer a plan renewal.
| This document (and the PEC) assumes that the SPCM and SPCM exchange are established prior to configuration of the PEC. This is typically configured by Tango Support. |
PEC Flow
-
The event comes in through the exchange from the SPCM.
-
The event enters the
event_processqueue. -
The event is processed and a CDR is written.
-
If there are no errors, it moves onto the external API.
-
If there is an error, a CDR is written on the error and it is returned to RabbitMQ and sits in the
event_retryqueue for the configured amount of time.
-
You can configure how many retries an event will attempt from the event_retry queue by checking out pec-max-retries in PEC general configuration.
|
| To account for the 3rd party application/api being unavailable, internal configuration is setup that utilizes TTLs and Dead Letter Queues in RabbitMQ that informs the system of unavailability. |
Event types
Typically, the SPCM has a set of data types that are produced. Of these data types, events are our primary concern in this context. These events are made available to an external API through the PEC via a JSON payload.
{
"eventType": "PLAN_PURCHASED",
"subscriber": {
"msisdn": "35386147258399",
"imsi" : "4654654646"
}
"plan": {
"id" : "112933,
"planDefinition" : {
"name" : "WEEKLY 10GB"
}
}
}
You can configure which event types you want consumed by the 3rd party application or API in the [General Configuration] section with the pec.policy-events-include property.
|
Event Type Table
| Event Type | Description | Included Data Types | ||
|---|---|---|---|---|
|
A new subscriber was autoprovisioned on the system.
|
subscriber
|
||
|
A plan was purchased, provisioned, or added for a subscriber. |
subscriber
plan
|
||
|
Charging a plan failed. This can occur for a number of reasons such as insufficient funds or the subscriber being unknown. |
subscriber
plan
|
||
|
An error occurred during charging. This happens with system timeouts and communication failures and is not indicative of an error with the subscriber. |
subscriber
plan
|
||
|
A plan has entered the pending state. Proper activation will occur later on on first data usage, manual activation, or timeout. |
subscriber
plan
|
||
|
A plan was activated. |
subscriber
plan
|
||
|
A plan was deactivated. |
subscriber
plan
|
||
|
An inactive plan was activated. |
subscriber
plan
|
||
|
An inactive plan was reactivated due to a timeout. |
subscriber
plan
|
||
|
A plan was terminated. |
subscriber
plan
|
||
|
A plan expiry warning threshold has been reached. For example, |
subscriber
plan
|
||
|
A plan has expired meaning it has reached the end of its current validity. |
subscriber
plan
|
||
|
An attempt to charge for a plan renewal failed. |
subscriber
plan
|
||
|
A plan has been cancelled meaning it will not renew at the end of the current validity period. |
subscriber
plan
|
||
|
A plan rule has been violated. |
subscriber
plan
rule
|
||
|
The full plan quota has been consumed. |
subscriber
plan
|
||
|
The full plan quota is available again. |
subscriber
plan
|
||
|
A data session has been initiated. |
subscriber
|
||
|
A data session has been initiated. |
subscriber
|