OK, I have a lot on my plate, and a funeral does not help matters, but I am working out what to do over the next few weeks.
We have the VoIP work to progress, but what we have now is a good milestone of "usable PABX", and the next stage is all the integration with back end systems to make a large scale telco SIP router. Its a long term plan. I also have OSPF, just in case you thought I had forgotten.
However, there is increasingly a need to progress the "clueless B2B XML"...
WTF is that? you ask?
Well, we have a management system for DSL, FTTC, ethernet, domains, email, all sorts. It runs on clueless. It can link in to the accounting system (priceless) as well.
So the plan is to make a new XML interface. And seriously, no, I am not going to do SOAP. It is a waste of space. However, I have conceded to use XML.
The plan is that, with suitable username and password, you will be able to extract an XML definition of all services you have for an account or login.
Then you will be able to make changes to that, and send it back.
The back end will work out what the changes mean, and provide details. These will be URLs to fetch for a PDF or XML order confirmation, a text description of the changes, and also the charge for the changes (or credit) if applicable. There will be a confirmation URL. You can then use the confirmation URL to agree charges and request the changes and hence get the invoice URL, if applicable.
The idea is that a load of non-chargeable changes, like changing contact details, passwords, requesting interleaving on a line, etc, etc, can be done easily.
But if there are any charges, you have to have an account login, and then confirm the charges which will be invoiced.
This would allow changes to existing services, ordering new services, ceasing existing services. A special case is a new customer which means sending a bare XML in the first place rather than modifying the existing services XML and sending back.
Then we write a few front ends using javascript and the like to allow simple orders (new customer with single broadband) and more complex orders (multiple lines, etc).
It will allow dealers to manage their lines, and place orders. It will allow us to have more than one type of order form for normal customers. It should be good.
It may be started with some of the basic services and extended over time. I plan to have a published XSD for it as well.
Comments?
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Is it worth considering supporting JSON as well as XML, as I've found this is proving more and more popular among developers as it removes a lot of the 'bloat' of XML and seems far easier to parse in most languages...
ReplyDeleteNot sure of the merits of JSON as it is very easy to map XML to JSON in javascript (we do that a lot), but I guess it is something we could consider.
ReplyDeleteI am trying to incorporate accounts details changes as well, e.g. address, email, password, etc. That will be challenging as accounts is a separate system with very tight access controls.
I'll get in touch with you by e-mail separately.
ReplyDeleteAs I think you already know, I have wanted this kind of access ever since we became wholesale A&A customers and have enough experience of E*tanet's wholesale interface to be able to tell you what it should have and what it should *not* have.