Creating APIs and frameworks (no code, just talk)

Well I’ve settled into my position at Dell now, and am starting to finally make some real changes now. We use a scheduling and automation suite here from a 3rd party that is pretty awesome, at least from a users perspective. The administration side of it feels like an afterthought in comparison, and it might be as they have a fairly extensive API to bang against, but it is an XML-RPC API, and not even a standard one so I cannot use the Python XML-RPC libs to get the job done. So I spent some time basically creating a giant wrapper that returns python objects instead of XML. The idea here being to make it easier to create other types of automation using this wrapper.

I created some classes that represent the different objects in our tool to hand back to the user so they can play with the data a bit easier. Then I went on to create the wrapper itself, which was interesting as I had never worked with XML-RPC before. Luckily I have worked with REST APIs a decent bit and the concept is similar enough. As stated above I wasn’t able to use the built in tools from Python, so I created some internal methods to assemble the URL, headers, and then call the appropriate procedure on the server with an XML document as the payload or data. Then I started creating methods that reflected the servers API, parsed out the returned XML and gives the user back a Python object that represents the data that they can now play with!

As I was saying, the admin interface is poor at best, it takes a long time to add resources and get them properly configured. Which is sad because it is such a powerful tool otherwise. We have found the current fastest way to add a device is to copy a similar one, and paste the new one in, then change all the meta-data associated with it. This would be less of a pain if the UI were snappy and intuitive, but it is not. One of my first tasks is to get my wrapper up to the point where I can make a tool that reads an Excel sheet (or csv as well), and creates the devices from that. This will end up saving us man hours every week, and sometimes every day. The next step will be for some automated configuration of the DUT (Device Under Test) that checks that the data we input was correct and sets up the device for us.

Some of the next steps are going to require some better infrastructure as well, if you have read my previous posts then you’ll know what I mean, and now those are in the works as well. Once I have the infrastructure to back me up, the sky is the limit! Or something like that anyway. I’ve got a lot of work ahead of me, and I’m trying to do things right, creating unit tests for the stuff I create, and getting things into version control. Wish me luck!

comments powered by Disqus