08-17-2016 01:55 AM
Hi,
I have an identity system which is automatically managing end users in CUCM via AXL.
The system is caps sensitive, so if a user is provided as "bob test", it will be created in CUCM as "bob test". If the user is then amended to be "Bob Test", the identity system will calculate that it must export an update to CUCM. It will send an update to AXL such as:
<ns:updateUser> <userid>user123</userid> <firstname>Bob</firstname> <lastname>Test</lastname> </ns:updateUser> |
However, the user remains "bob test". When my identity system reimports from CUCM, it notices the change was not performed and calculates the update must be exported again.
If the value were to change (e.g. "bob test" became "Bobby Testing"), the updates export correctly, suggesting the AXL is valid.
Is there a way to enforce a case change? Should case change updates work, could it be I'm doing something wrong?
Any advice much appreciated.
Andrew
Solved! Go to Solution.
08-17-2016 02:07 PM
Hi Andrew,
It works fine for me on 10.5.1. I think the problem you're having is that the tags are case sensitive, too, and you've got the case wrong. It should be:
<firstName>Bob</firstName>
<lastName>Test</lastName>
08-17-2016 02:07 PM
Hi Andrew,
It works fine for me on 10.5.1. I think the problem you're having is that the tags are case sensitive, too, and you've got the case wrong. It should be:
<firstName>Bob</firstName>
<lastName>Test</lastName>
08-18-2016 04:06 AM
You're absolutely right Nicholas, that fixed it, thanks!
I've since updated the cases of all the attributes I export to, to match those listed in the schema.
It's unfortunate that when selecting users and receiving the XML from the API for those, the case of element names is always lower case! Nevertheless, problem solved. Thank you .
08-18-2016 06:58 AM
Can you elaborate (maybe with an example response) on getting the incorrect camel-casing when retrieving info from AXL..? AXL should definitely be returning the valid casing per the schema...all seems OK on a quick test with my 10.5 system:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns:getUserResponse xmlns:ns="http://www.cisco.com/AXL/API/10.5">
<return>
<user uuid="{3735CB81-25F6-1598-913B-7CCCC47BE7F3}">
<firstName>David</firstName>
<middleName/>
<lastName>Staudt</lastName>
<userid>dstaudt</userid>
<password/>
<pin/>
<mailid/>
<department/>
<manager/>
<userLocale/>
<associatedDevices>
<device>CSFDSTAUDT</device>
<device>BOTDSTAUDT</device>
</associatedDevices>
...
08-18-2016 07:25 AM
That's interesting to hear - I'm using an executeSQLQuery request rather than a getUser request (as I import up to 1000 users in one request) - could that be the difference?
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns:executeSQLQueryResponse sequence="1" xmlns:ns="http://www.cisco.com/AXL/API/9.1">
<return>
<row>
<pkid>5f946bb2-07b5-a595-845b-62ca4d16e609</pkid>
<assocpc/>
<firstname>Bob3</firstname>
<middlename/>
<lastname>Test</lastname>
<userid>641234567</userid>
<manager>bob3.test@example.com</manager>
<department/>
<telephonenumber/>
<tkuserlocale/>
<mailid>bob3.test@example.com</mailid>
<status>1</status>
<facsimiletelephonenumber/>
<mobile/>
<pager/>
<homephone/>
<title/>
<building/>
<site/>
<fkdirectorypluginconfig/>
<uniqueidentifier/>
<nickname/>
<deletedtimestamp/>
<passwordreverse>69c4f936f9cdf45f6bbca2570c31215629bb5d6fb97493478b8ff3db6fffbc55</passwordreverse>
<fkmatrix_presence>ad243d17-98b4-4118-8feb-5ff2e1b781ac</fkmatrix_presence>
<tkuserprofile>1</tkuserprofile>
<fkcallingsearchspace_restrict/>
<allowcticontrolflag>t</allowcticontrolflag>
<enablemobilevoice>f</enablemobilevoice>
<maxdeskpickupwaittime>10000</maxdeskpickupwaittime>
<enablemobility>f</enablemobility>
<remotedestinationlimit>4</remotedestinationlimit>
<ocsprimaryuseraddress/>
<enableemcc>f</enableemcc>
<fkucserviceprofile/>
<directoryuri/>
<islocaluser>t</islocaluser>
<fkfeaturegrouptemplate/>
</row>
</return>
</ns:executeSQLQueryResponse>
</soapenv:Body>
</soapenv:Envelope>
The above is the output from a streamreader in c#. As you can see, no camel casing on the attribute names, there is correct casing on the SOAP enveloping though.
Edit: To add to the above, the SQL query I sent was select * from enduser where userid='641234567'
Thanks
08-18-2016 08:14 AM
Yep, that's the difference What you are seeing would be expected, then...
08-18-2016 08:17 AM
Thanks - good to know it's expected - still a little odd that it drops the case for a SQL query!
Really appreciate the help again.
08-24-2016 02:16 AM
a sql query will just have the plain column names in the return, the SOAP schema is not the same,
it's best to download the axl soap schema for your cucm version and look at the xml
08-24-2016 02:48 AM
Thanks, that makes sense I suppose. I did end up downloading the schema and correcting the case on applicable management agents in the way you suggested. All appears to be working as expected now
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