Here it comes the last posting of the “Billing calls from meshed potatoes” sequel.
Coding is an interesting exercise of long term investment. In fact, “for every minute spent in organizing, an hour is earned”. In October 2009, Areski (A2Billing) visited IT46 in Stockholm. There were two main answers to our “easy billing” challenge: a quick hack that will never be reusable or to add an API to A2Billing so other applications could be build in the future.
The “quick hack” consisted in collecting the information from the user (the Installation Wizard GUI) to later alter the SQL database (dump a bunch of nasty INSERTS!). The other alternative (the nice one) was to build an abstract layer at the top of A2Billing that could perform several “primitives” on behalf of the wizard.
We spent a couple of days with pen and paper, starting with the technical requirements of the Village Telco. Finally, we concluded that an “ugly hack” was going to give us more problems in the long round… so we took the decision to build something that we should not be embarrassed of in the future. After all, open source is the result of peer pressure. :-D.
We decided (1) to build the Installation Wizard using a MVC framework (Cake PHP), (2) to use SOAP as a transport mechanism between the Wizard and A2Billing, (3) extend A2Billing to support our general API.
This was a very nice arrangement, Areski could concentrate in building the internal logic. There are so many tables in A2Billing that I still wonder how Areski could figure out what everyone is doing!. In our side we decided to concentrate in building the Wizard (full of round corners!). The Installation Wizard should be based in the well known user-friendly principle of (Next, Next, Next, Accept).
Louise has been programing intensively with Cake PHP for the last 6 months, and she did not want to write the code in anything else. It has been a very nice programming project, the new API glued all together… and every day we were figuring out a way to reduce the number of clicks that the user need to put the scenario up and running.
Our main finding was that there is still plenty of work to do in the provisioning of VoIP upstream providers and the potatoes themselves, when it comes to upstream providers our goal is to make sure that the user does no need to type any SIP parameters at all into the system (account, password, codec, etc). The wizard will present to the user a set of VoIP carriers and by means of an activation code the system will auto-provision! (One click!) There is plenty of things that can go wrong… when hooking our local telephony mesh to an external gateway… and that means lots of code inside.
Today, we can bill local calls with a few clicks and it is time to start thinking in the overall provisioning!. Provisioning, it is definitely a Village Telco component that it is going to need more than our brains! We are getting there, it is easy to forget that one year ago we were just imagining something like this! 🙂