01-30-2015 08:39 AM
Hi
Is there any reason the following does not work
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">
<soapenv:Header/>
<soapenv:Body>
<ns:updatePhone sequence="1">
<uuid>{54C9B67C-C4B4-64B0-9FBA-7CC0DC8FFFDB}</uuid>
<ownerUserName uuid="{AE3E867E-948A-6A17-01AC-AE2AD3A3318C}"/>
<mobilityUserIdName uuid="{AE3E867E-948A-6A17-01AC-AE2AD3A3318C}"/>
</ns:updatePhone>
</soapenv:Body>
</soapenv:Envelope>
if I leave out the uuids for ownerUserName and mobilityUserName and instead use the value, things work out just fine.
Here's the error
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring>Missing key in referenced table for referential constraint (informix.fk_device_fkenduser).</faultstring>
<detail>
<axlError>
<axlcode>-691</axlcode>
<axlmessage>Missing key in referenced table for referential constraint (informix.fk_device_fkenduser).</axlmessage>
<request>updatePhone</request>
</axlError>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
I think I saw a similar message posted by somebody else.. given that the schema states that both uuid and actual value for the tag are optional, aren't we supposed to be able to freely switch between the two? If not, what are the rules.
01-30-2015 08:45 AM
Here's a countersample where just using the uuid does work.. setting the ipccExtension in an updateUser command:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">
<soapenv:Header/>
<soapenv:Body>
<ns:updateUser sequence="1">
<uuid>{0FBF7ABB-8A1D-38CE-EED4-90C2BDFFE0FE}</uuid>
<primaryExtension>
<pattern>7306</pattern>
<routePartitionName>p_phones</routePartitionName>
</primaryExtension>
<lineAppearanceAssociationForPresences >
<lineAppearanceAssociationForPresence>
<laapDeviceName>UPCTEST</laapDeviceName>
<laapDirectory>7306</laapDirectory>
<laapPartition>p_phones</laapPartition>
<laapDescription>Added phone SGRO</laapDescription>
</lineAppearanceAssociationForPresence>
</lineAppearanceAssociationForPresences >
<ipccExtension uuid="{75E397FD-F7F8-BFFB-E4D4-8CD4DBCFDB43}"/>
</ns:updateUser>
</soapenv:Body>
</soapenv:Envelope>
Well.. that is... I get a success message in return, neither the primary extension nor the ipccextension were set. Conversely, the lineAppeareanceAssociationForPresence WAS set, even though I did leave out some tags (notably the laapAssociate because there is some confusion as to what type it is, bool or guid with value).
02-18-2015 02:03 PM
I filed this. It will probably escalate to a defect, and then I'll give you a defect ID.
01-30-2015 08:52 AM
I suspect this is a defect. I'll file it with the engineers as a potential bug.
01-30-2015 09:11 AM
Speaking of which.. the ipccExtension is an XFkType.. so value and uuid. But.. given that an extension is only uniquely identified by either uuid or pattern AND partition.. shouldn't ipccExtension be the same as XUser/primaryExtension, or an object that that either takes an uuid attribute or pattern/routePartitionName combo (and perhaps routePartitionName should be XFkType given that it is mostly used that way and using routePartitioNname as a string is not common)
I have to revise my statement about the line appearances - the above may work, but doesn't do anything (the user name is not listed in the line config in ccmadmin)
However, the following does work, and it does take every single tag to make it work
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">
<soapenv:Header/>
<soapenv:Body>
<ns:updateUser sequence="1">
<uuid>{2B12EDFE-4D88-9FB1-8652-D82541880A6E}</uuid>
<lineAppearanceAssociationForPresences >
<lineAppearanceAssociationForPresence>
<laapAssociate>t</laapAssociate>
<laapProductType>Cisco Unified Client Services Framework</laapProductType>
<laapDeviceName>UPCTEST</laapDeviceName>
<laapDirectory>7306</laapDirectory>
<laapPartition>p_phones</laapPartition>
<laapDescription>Added phone SGRO</laapDescription>
</lineAppearanceAssociationForPresence>
</lineAppearanceAssociationForPresences >
</ns:updateUser>
</soapenv:Body>
</soapenv:Envelope>
And.. laapAssociate really acts like a boolean.. since I've confirmed it works like that ('f' = false, 't' = true), I can definitely conclude that it is not of type XFkType thus, the documentation is wrong.
And funny enough.. my get then shows two lineAppearanceForPresence - with the exact same value. Could that be due to having the same device (with a single number on it) controlled and cti controlled by this user?
Last but not least.. note the incorrect XML in the above? it appears the XML parsing on CUCM is quite lenient
01-30-2015 09:24 AM
Additional information:
This is a working user update that sets the line association for presence, and the primary extension.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">
<soapenv:Header/>
<soapenv:Body>
<ns:updateUser sequence="1">
<uuid>{2260C8C8-04C6-52C1-908C-6F6D7F0D4CC0}</uuid>
<primaryExtension>
<pattern>7306</pattern>
<routePartitionName>p_phones</routePartitionName>
</primaryExtension>
<lineAppearanceAssociationForPresences>
<lineAppearanceAssociationForPresence>
<laapAssociate>t</laapAssociate>
<laapProductType>Cisco Unified Client Services Framework</laapProductType>
<laapDeviceName>UPCTEST</laapDeviceName>
<laapDirectory>7306</laapDirectory>
<laapPartition>p_phones</laapPartition>
<laapDescription>Added phone SGRO</laapDescription>
</lineAppearanceAssociationForPresence>
</lineAppearanceAssociationForPresences>
</ns:updateUser>
</soapenv:Body>
</soapenv:Envelope>
Add the following to the statement
<ipccExtension uuid="{75E397FD-F7F8-BFFB-E4D4-8CD4DBCFDB43}"/>
and the operation will still return success, the line association for presence will be done, but neither the ipcc extension nor the primary extension will be set.
02-19-2015 08:32 AM
You can refer to this cdets defect id: CSCus84492
Fix is available from build 11.0.0.98000-187 onwards.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide