0
Answered

Possibility of Adding AXL to SQL Table Attribute Name Correlation in CISCO UCM connector.

Mark Southwell 12 years ago in UNIFYBroker/Cisco Unified Communications Manager updated by anonymous 8 years ago 2

Hi guys,

I've been working with the CISCO UCM connector, one thing I've found is import failures can occur when using the sqlTrust=False communicator option. The issue is the AXL attribute names vary to the names used in the SQL tables.

Name variances are taken into consideration when configuring AXL objects and SQL tables in the connector communicator via the AXLName and SQLName options. However attribute names also vary and the connector first does an AXL executeSQLquery to get all objects, then performs a native AXL Get request to extract data, using the same attribute name for both.

Example:

<entitySchema>
<field name="name" validator="string" key="true" required="true" readonly="true" />
</entitySchema>

Inital request to AXL:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Body><axlapi:executeSQLQuery xmlns:axlapi="http://www.cisco.com/AXL/API/7.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><sql>SELECT name FROM device</sql></axlapi:executeSQLQuery></SOAP-ENV:Body></SOAP-ENV:Envelope>

Subsequent request to AXL (per object received from first query)

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Body><axl:getDeviceProfile xmlns:axl="http://www.cisco.com/AXL/API/7.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><name>MTP_2</name></axl:getDeviceProfile></SOAP-ENV:Body></SOAP-ENV:Envelope>

Error returned:

ERROR http-8443-9 axl.AxlValidator - org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'name'. One of '

{"":profileId, "":profileName}

' is expected

The subsequent AXL request failes as it requires "profileName" instead of "name" as the "profileName" attribute is the AXL equivalent of the SQL "name" attribute . If profileName is used in entitySchema the first query fails as the attribute is not found in the SQL table.

Lowered priority. I'm not sure if this is the way to do this in the long run as attribute names even vary by function (e.g. Add/Update/Delete have different names for the same parameters). Might have to stick with what we did for APRA where we have a specific connectors I've created for specific purposes.

Ok, IDBUCM-4 should take care of this. For reads you can do things like "SELECT pkid as profileId FROM device" to make sure the right key name is used - anything more complicated than that is out of the question as there's just too much disparity between the different API functions (parameter names different between add/update/get/remove). Gonna work with Adam to see if we can find a more long-term solution than what I've been doing for APRA (code each attribute individually to deal with the inconsistencies)