Showing results for 
Search instead for 
Did you mean: 
Rising star

updateRemoteDestination - not returning uuid

Here's the latest return from an updateRemoteDestination.. as usual, the uuid is returned:

<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv=""><soapenv:Body><ns:updateRemoteDestinationResponse xmlns:ns=""><return>{D2C9E109-6F86-45A8-989A-C87285586308}</return></ns:updateRemoteDestinationResponse></soapenv:Body></soapenv:Envelope>

Then I try to extract the object again using the uuid

<soapenv:Envelope xmlns:soapenv="" xmlns:ns=""><soapenv:Header/><soapenv:Body><ns:getRemoteDestination sequence="0"> <uuid>{D2C9E109-6F86-45A8-989A-C87285586308}</uuid></ns:getRemoteDestination></soapenv:Body></soapenv:Envelope>

Same uuid, result

?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv=""><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server</faultcode><faultstring>Item not valid: The specified Destination was not found</faultstring><detail><axlError><axlcode>5007</axlcode><axlmessage>Item not valid: The specified Destination was not found</axlmessage><request>getRemoteDestination</request></axlError></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>

The schema says I can use the uuid - how.. and I suppose you can. The underlying issue is quite different though. For updates, you get back a string (uuid of the object that was updated). That works for all the objects I'm aware of (directory number, phone, device profile, remote destination profile, user, line group, hunt list, ...). For the RemoteDestination however, it appears that if you do an update, you get an uuid back, but it's different from the object you just updated. If I extract my remote destination by its destination, things are fine, and it also works with the uuid.. I just need to use the uuid that was returned upon addRemoteDestination.



I do not think the uuid you use to get remote destination it is correct. You can use listRemoteDestination to check uuid

This function (listRemoteDestionation) it will show all remote destinations and from there you can check your uuid and uuid

from listRemoteDestinationReponse.


Thuy Doan


I guess I should use the <bug> tag when I mean to report something that I deem a bug  - but I don't want to be presumtuous either, some things might be by design or I'm misunderstanding because it is not documented and I'm just making an educated guess based on past experience.

The guid that is being returned by updateRemoteDestination is obviously not the uuid of the remote destination. Obviously, a list operation would return the proper uuid.. but I already know it anyway since I created the object with addRemoteDestination, and extracted it with getRemoteDestination using the return value from addRemoteDestination (in an add scenario, the return value for a successful operation is always the uuid of the newly created object).

My argument is that given that all other update* operations I'm aware of do return the uid of the object you're updating (if successful), updateRemoteDestination should do so, too. Alternatively, it should be documented which update operations do return the object uuid, and which don't (and what the value is that is being returned.. I suspected a versionStamp first, but not all object have it and remote destination does not have it.


Hi Stephan,

Yes, I would assume that the UUID would be returned when sending updateRemoteDestination considering other update requests return the UUID. I was able to reproduce the issue in the lab, and I'll see if I can log a defect for this.




Hi Stephan,

We've created defect CSCus84862 for this issue.