This is not a post on UCCX Scripting. This post is about using the REST API as it is implemented in the UCCX Configuration API. This is also a post about adding functionality to the Administrative Interface of UCCX by providing a Bulk Provisioning tool. What I will leave you with today is a Command Line Tool that can and will improve the efficiency of creating configuration objects in the Cisco Unified Contact Center Express 9.x and later platform.
This is not my first foray into Representational State Transfer (REST). I previously wrote about using REST to reset a VoiceMail PIN (password): a utility that can be nicely integrated into a companies internal Website. REST is all the rage currently within “all” product lines (especially new ones or ones that didn’t have any APIs exposed previously such as the product we’ll be talking about today) within Cisco’s product portfolio. Why APIs? Why REST? Does this have implications when mentioned in the same breath as “Software Defined Networking (SDN)”? I believe so! But I’ll let that industry speak for itself..REST versus everything else I’ve seen is a simple choice. When working with REST, in order to get a list of data back from a source you merely call the HTTP GET method for what it is you want and what is returned is either an XML and/or JSON object (depends on who created the web service). Once you have the list of data you want, then you construct like objects (xml/json) to either create and/or modify (delete as well..but you don’t have to create an object) additional and/or existing configuration objects. In contrast, web services such as the Simple Access Object Protocol (SOAP) requires you to always pass an XML based object in the Request..this simply isn’t efficient. And if you notice in other posts I’ve created, CUCM still utilizes SOAP; they just call it Administrative XML (AXL) most of the time.
I may not get this write 🙂 the first time..if that is the case..let me know. As a pre disclaimer..there aren’t any UCCX Scripts written for this post…this is a primer for it though..
How often do CCX engineers find themselves on an engagement that has DB integration as part of it? Today I’m going to start a series on Database Integration. Pickup any UCCX Scripting Statement of Work, and 9 times out of 10 you will see DB Integration referred to as ‘Database Dips’ and as standard procedure these are typically disallowed (along with screenpops!). My guess to the disclaimer might be the steep licensing costs for DB Dips but from my viewpoint it is because they strike fear in the heart of the engineer who has to integrate with them. From experience, I was one of those fearful engineers (and I’ll just go out and say that I’m mostly speaking for myself here..but I would imagine someone reading this post will be able to identify with me). Database Integration is not so difficult though. As the developer, the first thing you need to know up front is the DB we’ll be dealing with because Cisco’s documentation is very straightforward on what is/is not supported just refer to the CCX Administration Guide. So the first step is NOT to panic..as much as you might not think it, you can find the support you need to be successful; you have me..but with the Caveats that go along with me..I’m not going to do your job for you..if you want me to do that..someone does have to pay for my time and efforts..You can find a prime example of how I might help you here; in fact that is a good place to ask the questions that I might be able to help you with to begin with..Ultimately, if I don’t break it down good enough for you (eventually) then I’m not doing the job I set out to do with this blog to begin with..So Let’s Get Started.
I’ve hardly mentioned it..but I will be at Cisco Live this year..and will be exclusively hanging out in Moscone West in the DevNet (Developer Network) Zone (May 19-22). One, because that’s what I could afford ($49 or $185 for Lenny) considering I’m funding my own way there (everything!) and two, writing software is all my rage if you couldn’t tell from the content I provide in this blog :).
I’m really excited about Cisco’s new drive to recruit more software engineers/developers to their events; this is the first year at CiscoLive they’ve had an area exclusively carved out for this group of professionals..and to cap it off..there will be a Contest to see what Development “Team” can plan/design(pitch/sale) and write/implement a software solution in 24 hours..otherwise called a Hackathon.
Every so often a question appears in the Cisco Technical Support Forums concerning the SubFlow Step in a UCCX Script. And it’s always a pleasure answering them and collecting my 5 points. For me the riddle has been solved..but I remember the time when I used these tricky elements within my scripts and I didn’t have the slightest clue as to how they worked their magic..Today in this short, I hope to “break down” the mystique by simplifying what is occuring in these things..and the code is short..as it should be..
The SubFlow Step is a cool little widget that is similar to function calls in procedural programming languages such as C and even Python..and from an OOP (object-oriented) perspective you can almost look at it as if you are calling a method on an object..For those of you who have no idea what I just said, you can look at a SubFlow Step as a “call” to a script that performs a very specific task such as checking for a Holiday, get queue statistics, performing a DB dip (perhaps), et al. SubFlows are typically very small and the ideal for code reuse because they are normally used by all the organizations/departments that use the same CCX system. If you’ve read my blog before you’ve probably seen some Python code with multiple functions and function calls..but I will show you what that looks like below..
Posted in UCCX
Tagged Coding, UCCX