Collection is the first task of any billing cycle. This consists in fetching or receiving all new events to process. As an illustration, one traditional technique consists in reading a file containing all events. The collection layer will read the events and push each of them in a repository roughly keeping its initial format.
For security purposes, this data is archived and will remain available.
Let’s take an example:
In the Telco postpaid business, a file containing all events is made available daily with typical events containing the following information:
You can imagine easily the wide variety of information you could get in these events : SMS, Data packet size, device location information, … and you can also foresee what it could be if you manage a Parking Lot, a VOD service or a Swimming Pool access…
We have many existing technical connectors to fetch the information:
Across all these sources and input formats, we constantly monitor the progress of the collection activity, we can cope with any connection issue through a proper recovery mechanism and we notify an operator if an external manual intervention or further investigation is required.
Once the event is stored in our repository, we trigger the next layer.
This is where all events are translated into one unique format.
Re using the example of a typical telco event, it will usually look like :
What is the Magic Number ? It is an event unique identifier calculated as a numerical combination of the previous inputs. Thanks to this method, we can automatically identify and eliminate any duplicate : we all hate to be charged twice for the same thing ! This Magic Number will also be used to track the transaction inside the system, through all the different processing layers.
A few other treatments can be executed at this level :
consolidate all time indications under the same Time Zone if you’re on multiple TZs.
Calculate the duration in a unique way : rounding per minute or per sec … or per ticks….
Aggregate CDRs : complex but mandatory for Conference business or when we receive two messages for one event : one for the beginning, one for the end….
Once everything is done, we trigger the next layer.
The last ‘Event relative layer ‘is the one consisting in assigning the flow of events to the relevant accounts.
In short, as an example, in a B2C Telco business, we take the Normalized Event as generated and identify the right account, usually based on the Caller. The process might sometime be slightly more sophisticated depending on the use case:
As for all the BillingLabs layer, this consolidation can be replayed at any time in entirety or limited to a subset of inputs. This allows to take into account any late changes in the overall billing ecosystem.
Throughout these entire event management layers, we guarantee every single event is properly processed invoking manual intervention whenever required. We care too much about your business to take the risk of losing any data !
This is the end of our activity on the Planet of Events, let’s now move to the Planet of Subscription.
