Small fixes for Cisco.UnityConnectionRestSdk

[stephan.steiner]

Hi

I downloaded the latest release and compare it with the changes I made in previous releases to see if all the things I fixed had made it in.

Let's start with one that's probably up for debate:

LdapCcmPkid, LdapCcmUserId and LdapType. It appears you can change them with stored procs, so I'm not sure they should be private (probably takes a change in the code that's behind the rest api to actually execute the change though)

Then RestTransportFunctions.cs - in my attempt to troubleshoot the file is locked issue (dev support knows all about this), I thought I make sure on my end that the file is never used and wrapped the access to streamTemp and binReader using the "using" statement.. so they'll both be released no matter what

Then, and now it gets less detatable

GreetingStreamFile.cs.GetStreamingFiles. If an upload doesn't work properly (Jeff once tried to repro this for me without success - I have a productive system where uploading wav files to the secondary server will work, but no wav file is ever uploaded), then your streaming file extraction will result in pGreetingStreamFiles containing null values. That in turn causes a nice null exception on line 436. So I added a filter on pGreetingStreamFiles that removes all null values before the iteration. Add

pGreetingStreamFiles.RemoveAll(u => u == null);

before

foreach (var oObject in pGreetingStreamFiles)

Cheers

Stephan

[lindborg]

1. Those properties related to LDAP integration out of the VOS system are private on purpose (at TAC’s request) – horsing around with them in our database with no access to the VOS hosted database (used to be available via SOAP AXL calls but got locked down a while back) is a recipe for danger.  Yes, they’re available via ODBC but ODBC is not supported by TAC and if/when you get your sync fouled up they don’t have to help you…

2. Fair enough – this change is in build 51.

3. Change is also in build 51.

Haven’t been following the travails of the failed WAV file upload thing – I did try that with both pub and sub variants without issue – so is that the source of the server side issue?  A sync issue from the sub?  That’s odd.

Anyway – 51 will be on NuGet later today once I finish a few tests first…

[stephan.steiner]

Thanks

As for the greetings - I remember, you tried it. There's the suspicion that it's something with my setup. If I hit the primary, I can flood the system with requests, just as you did in your tests, and all is well. It's tac case 632278139. The result of it is that I have to add a primary check prior to uploading greetings to deal with the unlikely case that there's a switch while my provisioning operations run. That's something I'm going to add in the coming days (not really a problem with your lib.. the info is all there, I simply need to add an optional primary check for certain operations in the code where I'm trying to send the request to a working server). I could very well imagine that there really is something a very tiny bit off with that system - you may recall that a longer while ago, I reported issues with setting pins/passwords immediately after creating if I was doing a large number of users (you also couldn't repro that).

With regards to #1: Me wanting to horse around where I'm not supposed is a sign of desperation. I have changes coming in to my provisioning system that may contain userid changes - so now I have to adopt a split personality where I do not process all changes, but add a delayed execution operation that's supposed to run after the ldap sync has run and verifies that the desired state has been achieved). As it stands now, the publicly available CUCN releases can't even handle this in normal operating mode - you have to disable ldap integration, change alias, re-enable ldap integration. The fix is in 11.0 and I should be getting a fix for the 10.5.2 as well - the steps I took with changing those properties (and the database monkeying..) were all attempts to replicate the cuadmin workaround.

If you're in the business of writing provisioning solutions, the LDAP integration really throws a wrench into your gears. You can get things to a workable state in CUCM, but in CUCN, it's out of your hands