Administrative XML Web Service (AXL) is an XML/SOAP based API that provides a mechanism for inserting, retrieving, updating and removing data from the CUCM configuration database. The AXL API provides you with access to the entire CUCM database. The AXL API is purely for provisioning and does not provide access to run-time or performance data. There are several other APIs we will discuss later that are used to provide this type of information.
Before exploring more of the AXL API using SoapUI, here are a few things you should know about the API:
AXL API utilizes HTTPS Basic Authentication. Any CUCM User (Application or EndUser) will have read/write access via AXL if they are members of the Standard CCM Super Users access control group or any group with the Standard AXL API Access role assigned to it. This means that all super user accounts implicitly already have access to the AXL API. To create an account dedicated for AXL API use, you must first create an access control group and assign the Standard AXL API Access role to it, then associate the application user with the newly created group.
To provide read-only AXL API access you can create a separate Access Control Group and assign only the Standard AXL Read Only API Access role to it.
In the interests of simplicity in this lab, you will use the admin account which is a member of the Standard CCM Super Users group. However, the best-practice in a production environment is to use a separate account dedicated for each AXL API application.
AXL has two distinct method types which operate in very different ways.
AXL API has built-in supports versioning for Thick AXL API requests only. Thick AXL API requests can specify the AXL schema version in the request header SOAPAction: CUCM:DB ver=15.0 as well as in the XML namespace URI for the the SOAP Envelope element within body of the request xmlns:ns="http://www.cisco.com/AXL/API/15.0". Both SOAPAction header and the XML namespace URI should indicate the same version. SOAPAction request header is optional but if supplied it supersedes the version specified XML namespace URI. AXL schema version in the XML namespace URI is always required.
The version specified in the AXL API request indicates which AXL schema version the request payload will follow and the response should follow.
CUCM maintains backwards compatibility with the running release minus 2 major versions. For example, applications written with CUCM 12.5 schema will still be supported through CUCM version 15 (because there was no version 13, so the next two versions are 14 and 15).
Although not recommended for schema dependant Thick AXL methods such as addPhone or updatePhone, if an AXL API client wishes not to specify a specific schema version, for example, when using the getCCMVersion method, we can omit the SOAPAction header and include a particular schema version 1.0 in the AXL XML namespace URI. In this case, CUCM will attempt to apply the lowest schema version supported by that CUCM release. For example: The AXL Developer Guide - Versioning on developer.cisco.com has more information including supported schema versions per CUCM major release as well as backward compatibility best practices and more.The AXL SOAP Service has dynamic throttling to protect system resources. When receiving an AXL write request, the CUCM publisher node via Cisco Database Layer Monitor service dynamically evaluates all database change notification queues across all nodes in the cluster and if any one node has more then 1500 change notification messages pending in its database queues, the AXL write requests will be rejected with a "503 Service Unavailable" response code. Even if the CUCM Cluster is keeping up with change notification processing and DB queues are NOT exceeding a depth of 1500, only 1500 AXL Write requests per minute are allowed.
The database change notifications queue can be monitored via the following CUCM Performance Counter on each node (\\cucm\DB Change Notification Server\QueuedRequestsInDB). This counter can be viewed using the Real Time Monitoring Tool (RTMT), but we will also show you how to retrieve CUCM Perfmon Counter values programmatically as well in the next section.
AXL read requests are NOT throttled even while write requests are being throttled.
In addition to AXL requests throttling, the following AXL query limits are always enforced: A single request is limited to returning under 8MB of data. Concurrent requests are limited to under 16MB of data.
The Data Throttling and Performance page on developer.cisco.com has more information on this topic.
As mentioned earlier, XML objects are defined in an XML schema file. The latest CUCM AXL Schema Reference (CUCM 15) can be found at https://developer.cisco.com/docs/axl-schema-reference/. This guide shows you the detailed structure of hundreds of methods available as part of the AXL API.
Although AXL schema changes are rare you may refer to older CUCM AXL Schema versions at https://developer.cisco.com/docs/axl/#archived-references You may find the older AXL Schema archived as a ZIP file that contains all the rendered HTML files.
You may refer to the AXL Operations by Release Matrix located at https://developer.cisco.com/docs/axl/#!operations-by-release to identify changes between Releases.
Now, with a background on the AXL API, you can use the SoapUI application to perform some common tasks via the API. At this point you are using the SoapUI application to construct the raw XML messages that will be transmitted to CUCM. Later you will do this in an easier, more programmatic way. The two tasks you will accomplish are:
Follow these steps to perform the above listed tasks:
The same optional input element is documented in the AXL Schema for AddPhoneReq/phone element as shown below. Notice how the box around the word description has a dotted line. This indicates that parameter is optional:
The response data above contains the UUID (Universally Unique IDentifier) for this Phone device just added to the CUCM database, which uniquely identifies this device in the database. It may be useful for modifying or removing this device. Within the CUCM Database, this is how this phone device will always be referenced. You can actually see this same ID if you log into the CUCM admin and, from the Device > Phone page, hover over the link to this phone. The URL would be something like: https://cucm1a.pod6.col.lab/ccmadmin/gendeviceEdit.do?key=06ea28c2-18ef-ecce-9ad1-e47f41c7e46f. In practice, if you are using Thick AXL, you should not need the UUID because you can always reference the device by the device name for any additional queries on the device.
If you need to look up the database configuration details of several phone devices or want to search for a device using wildcards because you don't know the exact device name, you can use the listPhones AXL API method. Follow these steps to perform a query for a set of phones.
Your Pod's Device UUIDs will differ from the ones shown below
Now that you have your phone registered to CUCM using AXL Methods with the SoapUI tool, let's look into a few more AXL Methods but in a programmatic way using Python.