0
Answered

How do I delete an entity in a Powershell connector?

Carol Wapshere 9 years ago in PowerShell connector updated by anonymous 9 years ago 8

The issue is on a Delta import - we can detect that an object has been deleted from the connector system (LDAP) but I can't delete the entity in IdB. (I think a Full Import will but I wanted this to work on the Delta).

The example on this page https://unifysolutions.jira.com/wiki/display/IDB50/PowerShell+Connector under "Delete Entities" is either missing something, or it's about exports.

Answer

Answer

Hi Carol,


Let me start by clarifying a few more points about the PowerShell connector. The Import All, Import Changes (for the "Entity" Import Changes Method), Request Changes and Get Entities (for the "Entity Id" Import Changes Method) are all import scripts. Import scripts are run when the Identity Broker connector's Import All or Import Changes operations are triggered.


The Add Entities, Updates Entities, Delete Entities, Delete All Entities and Change Password scripts are all export scripts. Export scripts are run when an IDM (e.g. FIM) sends adds/deletes/updates (e.g. during a FIM Export run step) to the relevant Identity Broker adapter via the LDAP endpoint. To avoid confusion with FIM's Full Import and Delta Import operations, please refer to IDB operations as Import All and Import Changes, as they are not part of the same process.


I'll give an example of deleting entities during a PowerShell connector Import Changes operation. The connector schema has two fields, ID (the key) and Name, and assume there are 5 entities in the connector context with IDs 1 through 5.

This is the Request Changes script:

function Get-UpdatedKeys
{
  return 1, 2, 3, 4, 5, 6;
}


foreach ($key in Get-UpdatedKeys)
{
  $changedKey = $keys.Create();
  $changedKey['ID'] = $key;
  $changedKey.Commit();
}

This indicates that all 5 entities have been changed, and a previously unknown entity (with ID 6) has also been changed.


This is the Get Entities script:

function Get-EntityByKey
{
  param ($key)
  if ($key -eq 3) { return $null; } # let's say entity with ID 3 is deleted
  return @{Key = $key; Value = "Value$key"};
}


foreach ($key in $components.InputKeys)
{
  $changedEntity = Get-EntityByKey $key['ID'];
  if ($changedEntity -eq $null)
  {
    # don't commit, deleted
    continue;
  }
  $entity = $entities.Create();
  $entity['ID'] = $changedEntity['Key'];
  $entity['Name'] = $changedEntity['Value'];
  $entity.Commit();
}

This iterates over the changed keys returned by the Request Changes script and retrieves the corresponding entities. If the entity is not flagged as deleted (Get-EntityByKey returns $null), then the entity is commited, otherwise it's ignored and the entity will be deleted from the connector space automatically by IDB. In this case, the entity with ID 3 would be deleted, the entity with ID 6 would be added, and the other entities would be updated.

Answered

Hi Carol,


If I understand the question correctly, you are asking how the PowerShell connector can, during an Import Changes operation, signal to Identity Broker that an entity was deleted? You are correct that the Delete Entities section is about exporting deletions. Please note from the documentation page that you linked, that the Entity Changes method of Import Changes is not capable of signalling deletions - only adds and updates. In order to signal a deletion, you must use the Entity ID Changes method. You must then write the Request Changes script to generate the keys of all the entities that have changed (adds, updates AND deletes), and then write the Get Entities script to commit the new state of each entity corresponding to the changed keys, or to not commit an entity in the case of a deletion.

Thanks Curtis. Do you have an example of how this can done with a Powershell connector import script? I have the source DN of the deleted object.

I've re-read your answer but it seems to be referring to what I do on a Full Import, and this issue here is about a Delta Import, so I think this is not possible?


I have another use case also from UoN - we have a Powershell connector that is registering users for SSPR. In some cases we also have to de-register them, so in this case the Update script knows they're getting de-registered and would ideally also delete the connector entity. A Full connector import takes many hours to run so we were only going to run it weekly. We do have a Delta import process that we can run frequently, however it can only pick up people registered that day, it can't pick up de-registrations.

Answer

Hi Carol,


Let me start by clarifying a few more points about the PowerShell connector. The Import All, Import Changes (for the "Entity" Import Changes Method), Request Changes and Get Entities (for the "Entity Id" Import Changes Method) are all import scripts. Import scripts are run when the Identity Broker connector's Import All or Import Changes operations are triggered.


The Add Entities, Updates Entities, Delete Entities, Delete All Entities and Change Password scripts are all export scripts. Export scripts are run when an IDM (e.g. FIM) sends adds/deletes/updates (e.g. during a FIM Export run step) to the relevant Identity Broker adapter via the LDAP endpoint. To avoid confusion with FIM's Full Import and Delta Import operations, please refer to IDB operations as Import All and Import Changes, as they are not part of the same process.


I'll give an example of deleting entities during a PowerShell connector Import Changes operation. The connector schema has two fields, ID (the key) and Name, and assume there are 5 entities in the connector context with IDs 1 through 5.

This is the Request Changes script:

function Get-UpdatedKeys
{
  return 1, 2, 3, 4, 5, 6;
}


foreach ($key in Get-UpdatedKeys)
{
  $changedKey = $keys.Create();
  $changedKey['ID'] = $key;
  $changedKey.Commit();
}

This indicates that all 5 entities have been changed, and a previously unknown entity (with ID 6) has also been changed.


This is the Get Entities script:

function Get-EntityByKey
{
  param ($key)
  if ($key -eq 3) { return $null; } # let's say entity with ID 3 is deleted
  return @{Key = $key; Value = "Value$key"};
}


foreach ($key in $components.InputKeys)
{
  $changedEntity = Get-EntityByKey $key['ID'];
  if ($changedEntity -eq $null)
  {
    # don't commit, deleted
    continue;
  }
  $entity = $entities.Create();
  $entity['ID'] = $changedEntity['Key'];
  $entity['Name'] = $changedEntity['Value'];
  $entity.Commit();
}

This iterates over the changed keys returned by the Request Changes script and retrieves the corresponding entities. If the entity is not flagged as deleted (Get-EntityByKey returns $null), then the entity is commited, otherwise it's ignored and the entity will be deleted from the connector space automatically by IDB. In this case, the entity with ID 3 would be deleted, the entity with ID 6 would be added, and the other entities would be updated.

I'm still not understanding how IdB knows I "got" an entity but then didn't commit it. The scripts I'm using do the same thing for both a new entity and an updated one:


$entity = $entities.Create()

$entity["key"] = $key

$entity["othervalue"]="value"

... (set other values)

$entity.Commit()


Are you saying if I execute the first two lines but don't do the Commit IdB will see it as a delete?


Also on your example above - be very careful using "return" in powershell functions as it doesn't do what it does in C# and vb.net.

As from my first reply,


Please note from the documentation page that you linked, that the Entity Changes method of Import Changes is not capable of signalling deletions - only adds and updates. In order to signal a deletion, you must use the Entity ID Changes method.

IDB understands that the entity is deleted because the key of the deleted entity is committed during the Request Changes script but no entity with that key is committed during the Get Entities script.

I'm using Entity and I really don't have any idea what the impact would be on the existing (quite complex) scripts if I switched to Entity Id. We're late into UAT here so no time for major re-development (unless you think it would be a simple change?). I've been putting a workaround in place for the connector where deletes are expected.

Hi Carol,


As per our discussion, I have created an item in our Team Services backlog to allow entity deletion from the single script "Entity" Import Changes method. Please let us know if the priority/urgency of this feature request changes.