The most problematic place before the deployment of a school network billing system is often not equipment debugging or network configuration, but account numbers and data streams are missing. When the system is online, problems with matching accounts, miscalculation of billing data, user identification errors etc. are centralised and difficult to reconcile."Blood."It is important that every link of origin, flow, storage and archiving be clearly thought out before deployment or the consequences will be dire.
The account must be unique.
There are several systems in school that involve user identification.——The system should be used to collect the account numbers from which the school network billing system should be connected. It is common practice to draw the home account number from the school’s unified identification system (usually LDAP or OAuth) and to use data from other systems as a supplement to attribute it. However, some schools have different departments that do not share data, and where information in the uniform identity certification system is outdated, before they can eventually find their account numbers in disarray.
The account synchronisation mechanism is to be selected
There are a number of ways to achieve the same: real-time synchronization (pull at every user's login), time synchronization (retrawing full volume per hour or daily), event drive (post-translation of the SAS account). Real-time synchronisation is the most accurate but complex, timed sync is the simplest but delayed data, and events drive is accurate and efficient. The school network billing system should be based on the actual school scene: students start their season with frequent changes in accounts that require real-time or event drivers; teachers account numbers are relatively stable, so that the timing is done.
Data flow first.
The data stream of the school network billing system is approximately: user certification requests → RADIUS Server → Costing system → Operational database → Reconciliation system → Financial system. Each link is in and out, and any chain of access is a whole chain. It is better to draw the data flow map before deployment, with each data node clearly marked: what to enter, what to export, how long to store, who has access rights."How do billing data from the billing system go to finance?"、"Where do we keep the audit log?"、"Whether user behaviour data involve privacy compliance"All of this is planned before deployment.
Borders for sensitive data processing
The school network billing system deals with a large number of sensitive data: school numbers, identity card numbers, cell phone numbers, Internet behavior records, and billing transactions records. There are compliance requirements for storage, transmission, access, destruction. Before you go forward, it is clear which data must be collected. What data is optional? Are the data transfers encrypted? Who has encryption permissions to store the database? How long does the log keep it? What is the process to delete?
Document the field definition for interface
The interfaces between the school network billing system and other systems are connected, and field definitions must be documented and formatted. For example, campus card systems are docked with fields that transmit a number, amount, transaction time, type of transaction, length, type, emptiness, meaning of each field. Interface version numbers are also required because interfaces may change when the system is upgraded, and interfaces that do not have version management will almost inevitably become problematic in projects that span the inter-school year. These files are placed in shared wiki or git warehouses to reduce skin removal when multiple collaboration takes place.
Several key points in database design
The database design for the school network fee system is several key points that can be ignored. First, there are few time zones in China’s high schools over time, but if servers are on cloud, they will be united to Beijing time, or there will be problems with cross-day reconciliations. Second, a historical data archiving strategy, which has huge billing data after 3-5 years of operation, requires an archive programme and cannot be fully stored in the main bank. Third, a split sheet strategy whereby users will lose their performance after 10,000 tons, leaving a preset.
The retreat program can't be avoided.
School network billing systems, once online, are almost impossible to stop. Pre-deployment programmes must be designed: how can you quickly return to the previous stable version if there is a problem at some point after going online? How can accounts be synchronized and wrong data? How can databases be migrated back to their original state if they fail? These options are not for paperwork but for real exercises.