I am having to debug the piece of code in ShouldDeleteFromMV and Deprovision methods.The MS defintion of
The ShouldDeleteFromMV method is called when a connector space entry is disconnected during an import operation. This method determines if the metaverse entry connected to the disconnecting connector space entry should be deleted
Will the Extension code get executed during an import operation ? I am not sure how to debug this .
The Deprovision method is called when a metaverse entry is deleted and the connector space entries connected to the metaverse entry become disconnector objects.
The debugger does not hit the deprovision even though i delete the MV entry by disconnecting all the CS objects connected to the MV entry,even though I select Rules Extension in Objection Deletion Rules.
Can you please advise?
SrinivasFriday, March 09, 2012 5:22 AM
Only importing the delete probably won't cause the code to fire. You would have to run a delta or full synchronization, either combined with the import in a single step, or as a separate step that occurs afterward.
Manually disconnecting the connectors may not cause the code to fire either. If you disconnect all the connectors manually, that will always remove the metaverse object regardless of your object deletion rule. In the case of deprovisioning, I've often seen different behavior between coded behavior and manual changes that should mimic it, though the last time I sincerely looked at that it was with an export-only MA and I'm unable to apply SP1 which contains a fix for the orphaned object problem caused by disconnecting an unconfirmed export that is deleted if done manually.
There is an object deletion rule for each object type and they are independent, so you should verify you selected Rule Extension for the deletion rule of the particular object type you are looking for. I'd guess you've already done this, but it doesn't hurt to double-check.
If you are having trouble attaching the debugger, try just adding a "Throw New Exception("blah")" in your ShouldDeleteFromMV subroutine to see if it is being called at all.
I prefer to do provisioning based on the presence of certain data rather than the lack of it, which means I essentially call my own deprovision routine from inside the Provisioning code.
ChrisFriday, March 09, 2012 2:15 PM
The best way to describe the 'ShouldDeletefromMV' rule extension is this-
The rules extension has read-only access to the connector space object that is deleted and to the metaverse object that it is linked to. The rules extension can examine the object's attributes and determine whether the metaverse object should be deleted.
The built in options cover most cases, but sometimes you need custom rules to decide what should happen. It is important to understand when the rules will be called. It's not very well understood by folks.
Object deletion rules are evaluated:
- When a connector space object is disconnected due to importing a deletion.
- When a connector space object is disconnected due to connector filter rules.
- When a connector space object is disconnected manually by using Joiner.
- When a management agent is deleted.
Object deletion rules are not evaluated:
- When a connector space object is disconnected due to
now on to the deprovision part...
Deprovisioning rules are called in the following circumstances:
- The metaverse object is deleted.
For example, if an object in connector space A is disconnected from the metaverse, and the object deletion rule causes the metaverse object to be deleted, the deprovisioning rules for management agent A will be called.
- Provisioning rules disconnect the connector space object from the metaverse object that it is linked to.
For example, you might have your provisioning rules configured to provision user objects from connector space A to connector space B, and you might also have your provisioning rules configured such that if the attribute EmployeeStatus is set to a certain value on an object in connector space B, then that connector space object will be disconnected. If a subsequent delta import to connector space A causes the attribute EmployeeStatus to be set to the specified value, the object in
connector space B will be disconnected, and the deprovisioning rules for management agent B will be called.
Deprovisioning rules are not called when:
The connector space object is manually disconnected from the metaverse object.
For example, you can use Metaverse Search to locate a metaverse object and view its properties, and to disconnect the object in a specified connector space, or management agent. In this case, deprovisioning rules for the specified connector space, or management agent, will not be called.
Frank C. Drewes III - Senior Consultant: Oxford Computer Group
Sunday, March 11, 2012 9:23 AM
- Edited by Frank Drewes Sunday, March 11, 2012 9:24 AM
Thanks for the reply.
I picked two scenarios for debuggin "ShoulddeletefromMV" but no luck.
When a connector space object is disconnected due to connector filter rules.-- I filtered a record based on some condition in my filter rules .The debugger hits the method "Provision" but not "ShouldDeletefromMV".
When a management agent is deleted. - I picked an identity from MV which is connected to few CSs . I disconnected all of the connectors using deprovisionall() method .Here the provision code is hit twice (as expected as the object is deprovisioned) and also the MV object is deleted.But the debugger didn't stop in "shoulddeltefromMV".Neither the "Deprovision" method got called in MAs code as you suggested above.
Am I missing something?Tuesday, March 13, 2012 12:59 PM
Did you select to run the MA in a seperate process? That could cause you not to hit the deprovision method.
and sorry if this is asking the obvious, but did you configure object deletion rule to use a rules extension? and did you configure it to run in its own process?
Frank C. Drewes III - Senior Consultant: Oxford Computer GroupTuesday, March 13, 2012 3:42 PM
It sounds like you're doing everything right..
The only other thing I can think of.. a little extreme.. is to add Debugger.Launch() in the method you want to debug and force the extension to stop, and then you can attach to it.
Here's a link to a blog I wrote about it for a former employer.
Frank C. Drewes III - Senior Consultant: Oxford Computer GroupFriday, March 16, 2012 12:51 AM