PowerShell connector use original entities on update

Thanks Adam van Vliet
Continuing on from Yammer

Does the exported entity contain the attributes that you are expecting? If so then it's working as intended. Most of the connectors that we've written export using the whole object, so needing to know which fields have been cleared is pretty rare.
Not sure if anyone has used it, but ContextEntities is designed for these sort of problems where you need to know the previous state.

The HTTP OData method we are invoking here via PowerShell is an UPSERT (insert or update - the server works it out). It is designed so we don't have to provide values of columns we don't care about (i.e. we can do what I'm doing now, and filter out all but the columns needed by Broker). So in this case, when a value is nulled (by FIM) for export via IdB to the target OData endpoint, I really need to know two things:

• the specific attribute that was nulled (at present I can't seem to work out how to determine this - apart from deducing that it's the only one now missing a value based on the ContextEntities collection; and
• determine whether or not there was a value previously (presumably there will only be a ContextEntities entry if there WAS a value previously, so this might be a redundant check).

Resolved. Kevin, please confirm.

Bob Bradley:

the specific attribute that was nulled

This issue is the same as with the compiled connectors, and we have the same options available to us. Either use the context entities, or retrieve the item from the target system. We've used both options with success, usually saving the latter for when we need the original object type to perform the update. Depending on the pattern being used in the script, you could loop through the schema and check the old and the new entity for that field (the pattern that I believe you're using); or loop through the values in the the entity; or access the known fields by name, one-by-one.

determine whether or not there was a value previously

Really only useful for update, I can't think of a reason to check the ContextEntities on add, as it won't be there.

Yes on the second point Adam van Vliet - only applies to update (which is where I have the challenge right now).

Also what would be REALLY handy right now is some sort of PowerShell connector test harness that would enable me to run the script in debug via the IDE. I'm not sure if you can attach the ISE to a process like you can with VS.Net, but something that would aid in script debugging would help enormously, and save hours and hours of "educated guessing", particularly when it comes to simulating the IdB object model.

Bob Bradley, that would be possible with the connector test harness. Unfortunately not available in the product as it'd be a security flaw to allow everyone to access it. See IDB-900.

Adam van Vliet - while I'm in build/troubleshoot mode this test harness would be very handy indeed. It would be OK to use in DEV I presume so long as we never deployed to Prod? Longer term, when the "security enhancements" are made we could indeed include it in the product - and considering the amount of time I could have saved if I had a debugging feature, this could pay for itself very quickly.

Confirmed original entity made available to powershell script.