cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1374
Views
3
Helpful
8
Replies

updateUser AXL Caps Sensitivity

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

1 Accepted Solution

Accepted Solutions

npetrele
Cisco Employee
Cisco Employee

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>


View solution in original post

8 Replies 8

npetrele
Cisco Employee
Cisco Employee

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>


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 .

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>

...

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

Yep, that's the difference   What you are seeing would be expected, then...

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.

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

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