Heads Up :
The post you are writing will appear in a public forum. Please ensure all content is appropriate for public consumption. Review the employee guidelines for the community here.
We have begun upgrading our large enterprise environment from Unity 9.1 to 10.5. We have a number of applications developed in-house utilizing the vmrest API. One of them allows end users to update the SmtpAddress of their SMTP Notification Device. E...
We have begun upgrading our large enterprise environment from Unity 9.1 to 10.5. We have a number of applications developed in-house utilizing the vmrest API. One of them allows end users to update the SmtpAddress of their SMTP Notification Device. E...
Cross-posting from support communities:Using Cisco Call Manager 8.5We have a homegrown AXL solution that provisions phones via addPhone, and is doing so successfully. However, seemingly without a consistent pattern, some of the phones subsequently fa...
Using Cisco Call Manager 8.5We have a homegrown AXL solution that provisions phones via addPhone, and is doing so successfully. However, seemingly without a consistent pattern, some of the phones subsequently fail a getPhone request. The publisher re...
You can go about getting the objectid a bit easier than that. Query for the alias like so:https://<server>/vmrest/users/?query=(alias is <ALIAS>)The resulting XML will give you the objectid. You can also use startswith.
Solution update! I found that the offending tools were building SOAP objects for each individual vendorConfig element, e.g. (with Perl):SOAP::Data->name('vendorConfig' => \SOAP::Data->value( SOAP::Data->name('elementOne')->value('valueOne')->type('x...
Aaand fixed! I found that the offending tools were building SOAP objects for each individual vendorConfig element, e.g. (with Perl):SOAP::Data->name('vendorConfig' => \SOAP::Data->value( SOAP::Data->name('elementOne')->value('valueOne')->type('xsd:X...
