feature request: copy operations

[stephan.steiner]

The usual approach to doing something like "create me another X that looks like Y", is getX, followed by changing name/pattern/other properties of interest, followed by add (I'll call X the "template" from now on)

That involves extracting every property, send it over the wire, then sending every property back again. Of course, there's a more efficient way - one that has been present in ccmadmin as long as I can recall: select an object, press copy button, change properties you want, submit.

In the AXL context, it would therefore be useful to have copy operations that took the identifier of an existing template object (uuid, name/partition, etc.), and based on that created a new object (returning it's uuid, just like an add operation does). The only parameters that the operation would require is the identifier of the existing object, and the identifier for the new object. E.g. for a phone, copyPhone(string existingDeviceName, string newDeviceName).

Then, you could do an updateX, and change the properties you want to adapt from the copy (and only those.. so  while you have the same number of AXL commands you execute, the number of properties will vary by a great deal, you may want to change 10 properties, whereas the full object may have closer to a 100 properties (think phone..))

Using that approach has multiple advantages:

• Less data is sent over the wire.
• Less validation load on the backend (I figure for an add with all properties they are all being validated)
• Less version dependant. Assume you upgrade a CUCM cluster, and you keep the existing application running. Thanks to AXL compatibility, the application remains running (if you're in the supported lifecycle). However, if the upgrade brings new properties, those are not touched. So, if your template uses some of the new properties, upon creation using the get/add approach, the new properties remain unused.
  Using the copy/update approach, the new property values from the template would already be taken into account without having to adapt the application.
  
  

[npetrele]

It certainly would be a nice feature, and I can suggest it.  I can already see some hiccups, though.  Let's say there's a "copy phone" AXL function.  The reason it works in the web UI is because it leaves you in the form where you'd change the information.  If you try to save the new phone, it will tell you it failed because there's duplicate information where duplicates aren't allowed. 

So a "copy phone" AXL call would have to fudge some fields to make them unique and then tell you what has been fudged so you can take care of it.  If you don't take care of it, you leave an orphan phone out there. 

In other words, I can see why the developers haven't implemented it so far.  It's not as easy to implement as it is to do it with the GUI.

[stephan.steiner]

But.. the only way the copy phone can fail on save is if you don't update the name. My proposal requires that every copy operation has its own set of parameters.. those that are needed to make an object unique (for phone it's the device name, for a directory number it would be pattern/routePartitionName, for user the userId, etc.). That's just like the get operations that each have their own set of parameters (and in fact it's the same parameters as for the get.. except that you can't use uuid but need to specify the "other set of parameters").

Or am I missing a scenario I've never encountered where this doesn't work?

[npetrele]

No, I don't think you're missing anything.  Adding an request parameter with a new name should do it.  I'll suggest it as a feature request.