Many schools underestimate the complexity of a cartoon.
A school-based cartoon is almost marked in a college: eating, bathing, barring, lending books and using this card. Later on, the campus network also charges fees. Many schools naturally think of adding WiFi to a cartoon system, an account number, a card, a back office, which sounds good.
When you actually landed, this..."Shun."Words often become"Puddles"Word.
The technical logic of handling this is not complex: a cartoon system has student identification and account information, and WiFi needs to know who's online and from which account. Data exchange between the two systems through interfaces seems standard. But standard operations often encounter problems outside standards in the actual environment.
First pit: the two systems' account system is not the same thing.
The logic of a cartoon system is"Advances"The money in a cartoon account is the real renminbi balance.
The logic of WiFi ' s account system may be multiple: it may be prepaid (filled after Internet access), followed by payment (spent after settlement) or a monthly package (the long pack on time does not involve single deductions).
When the two accounts are connected, the problem arises: a student has $5 left in a cartoon account and 20 dollars per month for the WiFi package.——Is that five bucks enough to open WiFi? How can you get it off? Proportional number of days? Or must the minimum be charged to open?
There is more trouble: a cartoon account is in arrears, should WiFi be stopped simultaneously? WiFi is in default, should the consumption of a cartoon card be affected? Should the balances of both accounts be presented in a uniform manner? These business rules are not clearly aligned, and they can only be implemented temporarily, often with loopholes.
Second pit: Real-time requirements for data synchronization are underestimated
A cartoon consumption is real-time: students spend their cards, and the balance is immediately deducted. If the WiFi system query interfaces are slow to respond, it takes several seconds for a student to connect to WiFi to confirm that the balance is insufficient, which will cause a lot of complaints.
More seriously, the double deductions due to data mismatches. Students try to connect WiFi when they just use a cartoon to charge it and WiFi's billing system is not synchronized.——The system may find the balance insufficient to reject the request, but then the data is synchronized to see that it is useful. This border situation occurs a lot when it is co-mingled and its handling can lead to a crisis of confidence in the system among students.
The data synchronization is also a dimension of post-school account write-off. Graduates leave school, a cartoon account is sold, and WiFi’s billing number is cancelled simultaneously. If not, graduates can use the campus web to find out who will charge them.
Third pit: different standards of interface between the various manufacturers
There are several mainstream manufacturers in a toon market. The interface protocols, data formats, and field definitions vary from one place to another.
The pit of custom development is that the development cycle tends to be longer than expected, that border situations are frequently encountered during the commissioning process and that two manufacturers assume responsibility for each other ' s interfaces, often with school coordination but very inefficient.
Many cartoon manufacturers are concerned about opening interfaces to third parties, fearing data security or competitive risks, incomplete interface documents, and slow technical support responses. This often remains undisclosed at the docking negotiations stage, when a project is launched and delays in progress are normal.
Fourth pit: business rules adjustments to link two systems
Assuming that the school decides to adjust the WiFi package pricing strategy from a month-on-a-month to a two-way model, this adjustment involves changes in the logic of a cartoon account deduction charge, it will be accompanied by an interface and operational rules on both sides of the cartoon system and the WiFi billing system.
The change of two systems is much more complex than the change of one system, requiring both developers to be present, tested and connected. If the two systems are separate suppliers, the cost of coordinating changes is higher.
Before closing, one thing is clear: whether the subsequent changes in business rules require a vendor ' s involvement to make them or whether the billing system itself provides a visual interface for the configuration of operations that the carrier can adjust on its own. The former means that every change in rules requires project processes and the latter is the real flexible configuration capability available.
In the end,
The source of the pits is often not technology per se, but rather a lack of in-depth collating of business rules before the connection, insufficient understanding of differences between the two systems and inadequate estimates of subsequent transportation costs. Before deciding on the interface, think about the logic of accounts for the two systems, data synchronization requirements, interface standards, change mechanisms, and avoid most of the pits.