Support for rename operation in PowerShell connector

Hi Adrian,

I'm not quite sure what you're trying to achieve here to know how to propose a solution. Would it be possible to map out a scenario / use cases to help me understand?

Hi Matt, no problem.  The 'rename' terminology comes from LDAP - it means changing the anchor field value (key) for an object.

Let's say a hypothetical PowerShell connector has the following fields:

DepartmentID string KEY,REQUIRED
DepartmentName string REQUIRED

During an organisational restructure, a department changes DepartmentID from 1000 to 2000.  The API that the PowerShell connector is using supports a 'rename' operation - where the DepartmentID can be changed and all other internal data structures associated with that entity within the application (most of which are not even exposed to UNIFYBroker) are retained.

As far as I can tell in UNIFYBroker when the update script is called it is only passed the new DepartmentID value (2000).  How do I tell that this update is for the entity which previously had DepartmentID 1000?

Hey Adrian,

Thanks - that explains it perfectly.

Unfortunately this isn't something that the Powershell connector supports currently, but Broker definitely has the ability to support this and it's something we could add to the Powershell connector. 

I did some looking to see if there's something you could do elsewhere in the interim (like in the adapter) but unfortunately the event triggered by this LDAP operation is only passed through to the connector.

Based on that, it'd be something we'd have to add to the backlog. Do you have a priority you'd like attached to this?

Just as a note, it'd be a separate script for this specific scenario in the Powershell connector. The anchor change operation is run prior to the normal update operation being run, so the new anchor is available for the update portion.

Thanks Matt, I'll find out and let you know.  In the meantime perhaps this Question topic can be closed, and the new functionality raised as an 'Idea' instead.

Moved to an Idea and added to the backlog!

Hi Matt - this is something that CASA have already commissioned Birch to add to their API and it's now available for us to work with - so if there's work required to support this initiative then we'll either need that done as a prerequisite, or have to workaround it somehow with extra MIM flows.  We'd obviously prefer not to rely on MIM.

As far as a timeline is concerned, the work will proceed, but we have to go through the presales cycle still starting with a ROM (already prepared) and then proceeding to a formal SOW. So if you could please give an estimate of how much work would be required and a timeframe we can factor that into the SOW when we're asked to proceed with it.

Thanks

Feature planned for 6.0 release