In the real environment of college, billing engines need to be handled simultaneously.User identity, online status, number of terminals, billing cycle, abnormal interruptions, inter-school behaviouris a complex variable.
The following, from the very beginningProduct and realization dimensionsDismantling of billing engine capabilities.
I. LINKING OF THE COST-BASED ENGINE: NO“Counting money.”Yes.“Status controller”
In the mature campus network Authentication & Billing system, the billing engine takes on three things:
-
Define who can use the network in what state
-
Real-time changes in user network privileges according to time and rules
-
Translating all changes into auditable, retrospective data
So, the billing engine is not a stand-alone module, but rather...State system with authentication, online session, terminal management strongly coupled。
There is only one core characteristic:
Cost status ≠ Account balance, but“Network Permissions Status”
ii. Dismantling of costing models: universities are common but the difficulty in achieving them varies greatly
The billing engine must support a variety of models in the university andOverlayable：
1 cyclical billing (mainstream)
-
Monthly/ Annual payment
-
Fixed start and end time
-
Autotrigger policy for maturity
Internal system requirements:
-
Exact time to second level
-
The due event must be connected to the online session in real time
-
Do not rely on manual batch operations
2 x long-term
-
Cumulative online hours
-
Interlinking, interconnecting.
-
High peaks are frequently downlined.
The billing engine needs to be addressed:
-
Whether the abnormal break is withheld
-
The time of the heart's loss belongs to
-
Clean-up mechanism for session residuals
3 ⁇ Portfolio set charge
-
Main package + Additional Package
-
Different packages for different rates, terminals
-
The package changes are effective immediately.
The difficulty of such a calculation is that:
-
The package is not interrupted.
-
The first and new ones are smooth migration
-
History accounts cannot be overridden
The four core design points where the billing engine is most vulnerable to neglect
1 Billing and authentication decoupling, but the meeting was strictly tied
mature systems:
-
Certification only.“Release”
-
Fee decisions“How long will you be released?”
But...Online sessions must be informed of real-time changes in the billing status：
-
Due → Speed limit / Disconnect
-
Continuation → Restore instantaneously
-
Arrears → Permission Down
Any delay is infinitely magnified in the university environment.
2 All costing events must be“Replayable”It's...
The university has a long cycle and the following problems are common in years:
“Why did you charge that amount?”
Therefore, the costing engine design must:
-
All billing events are traceable.
-
Revert user status at any point in time
-
History rules are isolated from current ones.
Otherwise, the longer the system is running, the higher the risk.
3 The billing engine must tolerate anomalies rather than assume network stability
The real university environment:
-
Switching back on.
-
Core Links Dithering
-
Terminal abnormally delineated
The costing engine must have:
-
Anomalous break line threshold
-
Autocleaning of meetings with freezing
-
Cost-based suspension and restoration mechanism
This is...“Laboratory systems”and“Real Available Systems”The watershed.
4 The rule of costing must be manageable
The situation of co-existence in higher education is common:
-
Different schools have different strategies.
-
Different rates for different accommodation areas
-
Special User Temporary Release
The costing engine needs to be clear:
-
User-level priority
-
User Group Second
-
Global strategy.
The confusion of priorities inevitably leads to complaints and the explosion of DMV costs.
IV. FACTUAL CASE OF ACCIDENT: HOW THE LABOR OF A LOT-BASED HOUSE RATTER OPERATION
Below are anonymous colleges of higher learning, data structure and behaviour are real project logics that do not involve specific school names.
Project background (simplification)
-
Students in schools: approximately 28,000
-
Accommodation areas: 6
-
Object of billing: Student Hostel Wireless Network
-
Billing method: monthly package + terminal limit
Cost engine behaviour in operation
1 ⁇ maturing of the package
-
Exact time to seconds
-
Online users do not force offline
-
Auto-switch speed strategy
-
3 After renewal–Recover strategy in 5 seconds.
Keypoints：
Nothing.“Focus on the net.”, avoid a peak period system shaking.
2 st, peak breaker reconnected.
-
20:00 p.m.–23:00. Visible increase in breakout rates.
-
The system avoids double deduction through the session cache mechanism
-
Unusual reconnection does not create additional accounting records
3 ⁇ Terminal replacement scenario
-
Student replacement cellular or computer
-
New terminal access automatic occupancy slot
-
Remind and block when exceeding terminal number
-
Manage endable batch release of old terminals
The billing engine is connected to the terminal management in real time and does not require manual intervention.
4 ⁇ Holidays and special periods
-
Cold summer strategy preset
-
The billing has been suspended but account numbers maintained
-
Start school automatically restores the billing state
The billing rules are time-bound and not manual.
Why the billing engine determines the system“It'll take years to get it right.”
The project is a major project for the university.The billing engine is not a selling point, but it must be a risk point.。
A true and operational costing engine often has the following characteristics:
-
There are many parameters of the rules, but logic is clear.
-
High automation and low manual intervention
-
Historical data retroactive
-
The scene has a mechanism for the bottom.
These abilities, usually onlyRe-painting in long, multi-university environmentsIt's not until it's formed.