CMS Northbound Interface Integration

CMS Northbound Interface Integration

When designing the fiber management system (FMS), one feature that is heavily needed is a way to provision, change, delete and query customer hardware. Being a Calix shop, we have our access hardware, and a CMS (Calix Management System) which aggregates all of our access systems together. The result is a one stop shop where ONT’s can be managed across one interface. Upon our first deployment, we used the CMS client to provision and manage all of our ONTs for customers. We quickly hated using the client for most of our operations. Now, I am in no way trying to bash on Calix’s software, I believe CMS is a great tool. The client on the other hand… I cannot say the same.

CMS features a northbound interface, which uses an XML http request to exchange information between CMS and 3rd party applications. The CMS API is by far my most favorite/hated feature of CMS. The ability to use any language to make and retrieve requests is awesome, but can be difficult in some languages. Let me provide a bit more information. My FMS system uses PHP for a majority of its server side rendering. I know how bad PHP is, but in the case of making a system web accessible from any device drastically limited my options. Further details on why I used PHP will be made available in later posts. The access diagram for the FMS is below.

cms-fms-access

Since PHP is a server side translator, it allows our information to processed within the same network as our CMS server, ultimately allowing clients to process information in the management VLAN where the CMS and Calix equipment resides. With the ability to serve clients with data via web, any mobile or web accessible device can use the FMS.

 

Tying it all in

Given my current situation, I cannot explain in detail what I have fully done with this API, but what I can explain are some of the modules we tied the northbound interface in with. Some modules that reside within the FMS are: customer records and basic inventory. Which means that we can record our ONT inventory and tie it in with customers, allowing me to knew exactly what customer has what piece of equipment. Further with the northbound interface module, I can use the inventory data to generate a configuration linked with a customer and have one click customer provisioning. Behold! I have made our jobs so much easier! Upon creating a customer, I can provision an ONT in under 15 seconds, record where it is going, where it was and I don’t even have to unpack the unit. I can hand it to an installer, whom installs it at a customers house, plugs it in, turns it on and it provisions instantly. Now, while a lot of this does not involve the northbound interface, you can see how I have taken three tasks and combined them in to a fluid cycle. (Note, this cycle does not work for everyone, or every deployment, which is why I am currently redesigning the process). Inventory is linked to a customer, and linked to CMS, and the installer does not have to carry a buttset around and punch in registration ID’s. I wish I could explain more, because with the addition of other modules, and more detail, A LOT more cool stuff can be automated.

 

Building the module, take one

When I first designed this module, I honestly knew almost zero about http requests, Python, XML, SOAP, PHP, JS and Love. Refrain from laughing as much as possible when you see my code and keep in mind that I was learning. Also keep in mind that once I got this working, it became the bomb-diggity for our company. I decided to use Python, because WHY THE HECK NOT?!? Mostly I was aware of how bad PHP was, and I wanted to make the service available even in non web based environments (Yes, I am aware that CLI PHP is thing, but still I wanted to refrain from using it as much as possible). So I got to work writing python scripts that would take in FSAN numbers, ONT ID’s, bandwidth profiles and everything else as arguments. I could then process it and and spit out the result. The code was messy, some outputs were XML, others were strings, and some just returned a 1 or 0. If you want to see how bad it is, here is the link to the github repo. A lot has changed and is not reflected there. It is now a lot more structured and allow for provisioning of SIP services, RG interfaces, and other stuff.

ont-provision

Provisioning was a simple three click process, auto assigned the ONT to a customer, and made an note in the inventory on the whereabouts of an ONT. It even allowed for error checking allowing us to make sure things went smoothly during the provisioning process.

ohno

CMS integration was a module added in the early stages of the FMS development. After the module was created, it didn’t really change mostly because it just worked. Only until recently, have I had to make drastic changes to the FMS, which pretty much required a redesign of the whole module.

The process effectively went from this

old-api-flow

to something like this

calix-niapi-filtered

🙁 I am sorry that I cannot show you the inner workings of my new process, but I have been instructed that I cannot display the secret sauce. As you can see, this new flow is a lot more structured and has a lot more going on. What I can explain is what makes the system a heck of a lot better than before.

 

Dynamic, TO THE MAX

One benefit this new module brings is the added dynamic that previously did not exist. The old code relied on a config file that stored all of the variables for connecting to CMS.

old-config

This limitation allowed you to only query one system from one CMS server. The new module allows for dynamic addition and deletion of systems, meaning that multiple CMS hosts with multiple access systems can be queried.

access systems blur

One feature, or more rather byproduct (but works as a feature) is that the result is transferred to the client as an http request. This allow AJAX queries from server to client to occur instantly and be encoded in JSON. I effectively created and API for an API :P. I feel that there is potential to allow access from 3rd party devices/systems in the future.

I must wrap up this post, but before I do, I want to show you a screenshot of what kind of useful data is possible through the new Calix-NIAPI module.


ont-show-blur

It is certainly cool what can be done when you tie services into one another! If you have questions regarding this system, processes involved please contact me at gbrewster@agoasite.com

 

Comments are closed.