In this the third part of my mini series on using the CUCM API, we start to get further into the Ju-Ju, and check web app changes via the API, before then going on to make a change via the API itself.
As before if you haven’t gone through the previous two posts then please, head back to the start and we will see you back here shortly.
There are two reasons why you might want to use an API in your day to day changes.
In this part 2 of my API adventure, I will be looking at repeating what we did Part 1 via SoapUI, but this time in python using the suds library. If you haven’t read that yet, then really, please go back and do that. This will not be wildly useful otherwise.
Yeah I went there…
So, we have a process that allows us to programatically look stuff up. Only its not very repeatable, and therefore not much use yet. With this post I will take you through the creation of a python script that mimics what we did previously - finding things, and showing them to you.
Ick, I know.
Python has long been the language of choice for engineers looking to make their day go that little bit quicker or easier. With deepening skill levels, more and more complex repetitive tasks can be disected and segmented into functions and reuable code, such that a competent scripting engineer can go from blank page to automated process in a matter of hours in most cases. It is for this reason that I sit here to write this - an advocacy for ALL Cisco engineers to down tools and spend however long you need to get good at this.
This is one of those posts that I will constantly refer back to… ;)
In my day job it’s clear to me that we need to automate more and more of the dumb day to day stuff. One of those things is Leavers and Starters on our phone system.
We employ Cisco CallManager, much like the rest of the world, and if you have ever spent any time with it, you will know that its VASTLY over-complicated to manage. A single extension on someones’ desk requires (at least):
Oh how the world has changed since I started out in the wonderful trade.
We used to have VLANs and subnets; switches, routers and firewalls. People would moan things didn’t work and we did a traceroute to figure out why. We would bash out a fix, and if it broke, we would bash out another. It was the wild west, and that was fun. Cowboy hats were standard issue.
Then along came the bad guys, and with them, the policy doctors. Changes became more structured and requirements became more complex. Environments spiraled out into wider geographical areas and management became less about break fix and more about tightly structured architecture. The industry responded with protocols and toolchains, each with their own use case, and bit by bit, the sector split up into the key areas of WAN, DC and Campus.