کد:
http://blogs.dirteam.com/blogs/jorge/archive/2010/03/08/automatically-deleting-expired-objects-in-fim-2010.aspx
With FIM it is possible to automatically delete objects when those objects meet certain criteria. Examples of criteria are:

  • Expired objects at the end of their lifecycle. This could be based upon for example the defined ExpirationTime, which in turn may be based upon the EmployeeEndDate + 1 day.
  • Objects that were created but have never been used within a defined amount of time. This could be based upon for example the defined CreatedTime + 30 days
  • Objects that were created and have been used, but are not used anymore while still within their valid object lifecycle (between EmployeeStartDate and EmployeeEndDate). This could be based upon for example the LastLogonTimeStamp + 180 days.


The basic idea here is that you first define which objects are candidates to be deleted. Let's use the first example. In addition to the following you need to make sure that in this case the the "ExpirationTime" attribute is set. That could be based on the "EmployeeEndDate" + 1 day. Why "+1 day"? Well if the EmployeeEndDate is the last working day, you do not want to delete the object on that same date, but rather a day later.
You could create the following SET:
Name: "_SET: All People For Which ExpirationTime Has Passed Today" (Remark: I'm not saying "Expired Objects" because what's the definition of an expired object? I like to have clear naming so that's why the SET is called like this)
XPATH Filter: "/Person[ExpirationTime < fn:current-dateTime()]"

Then you need something (a process) that will carry out the deletion of the object. By default, FIM provides a workflow that will delete an object. The name of the workflow is "Expiration Workflow". The description is "This workflow will delete the resource to which it is applied."

Then you need something that's triggered based on the required condition and that it executes the workflow.
You could create the following MPR:
Name: "_MPR: TRN - Notify and Delete Expired Identities"
MPR Type: "Set Transition"
Transition Type: "Transition In"
Transition Set: "_SET: All People For Which ExpirationTime Has Passed Today"
Policy Workflows (Action Only): "Expiration Workflow" + "_WFW: Send Notification Because Of Expired Identity" (The first one suffices, but I also wanted to send the manager of the user a notification that the object was deleted)

So with this configuration, and after making sure an object has an ExpirationTime defined, the results are as follows. As soon as the user becomes a member of the SET ""_SET: All People For Which ExpirationTime Has Passed Today" because the ExpirationTime < Today AND the "FIM_TemporalEventsJob" has executed, the MPR will be triggered and execute the Workflow. In the requests you will see stuff like below. As soon as the object becomes a member of the SET a system event is generated as shown below, but with a PostProcessingError.

As you can see the, Expiration Workflow is the actual requestor/originator when trying to delete the object "Anne Pinto" and in this case it has been denied that action.
Looking closer at the System Event Request, you will see:

You will also see which MPR caused the System Event



What did we forget here? We made sure the action is carried out, but we forgot to assign the correct permissions so that the action is carried out correctly. In this case the "Expiration Workflow" needs to have DELETE permissions to be able to delete the objects in scope. Let's go through that configuration to see what's needed.


Permissions can only be assigned through SETs and a SET is just a grouping of objects that match certain criteria.
So we first need to create a SET that includes the Expiration Workflow. An example of such a SET is:
Name: "_SET: Expiration Workflow System"
XPATH Filter: "/*[ObjectID = 'f6d0bfce-df36-4756-98a2-cb8917428bae']" (this just references a specific object with the GUID specified. If I'm not mistaken this GUID is the same for the Expiration workflow in all FIM deployments)

Then you need something (a process) that allows the deletion of the object. Because it is about assigning permissions you need/must use a REQUEST based MPR. You cannot use TRANSITION based MPRs.


You could create the following MPR:
Name: "_MPR: RQP - Expiration Workflow Can Delete Expired Identities"
MPR Type: "Request"
Requestor: "_SET: Expiration Workflow System"
Operation: "Delete Resource"
Grants Permission: "TRUE"



Target Before Request SET: "_SET: All People For Which ExpirationTime Has Passed Today" (In this case I'm assigning permissions only to those objects that meet certain criteria. If I would have objects meet other criteria that are also candidates for deletion I would create additional MPRs/SET to fulfill that need.)
Resource Attributes: "All Attributes"
Policy Workflows (Action Only): "NONE"

Now a question that could arise is "Could I combine MPRs?" In this case the answer is NO. Why? Well for the action itself I need a transition based MPR which is great for time-based criteria. For the permissions part I need a request based MPR. Transition based MPRs cannot assign permissions.

Let's try this again. So with this configuration, and after making sure an object has an ExpirationTime defined, the results are as follows. As soon as the user becomes a member of the SET "_SET: All People For Which ExpirationTime Has Passed Today" because the ExpirationTime < Today AND the "FIM_TemporalEventsJob" has executed, the MPR will be triggered and execute the Workflow. The other MPR will allow the action to be performed.


As you can see the Expiration Workflow now successfully completed the request to delete the object "Anne Pinto"

As you can see below the actual request to delete the object matches the MPR that assigns the permission to do so. If you expected to see the MPR called "_MPR: TRN - Notify and Delete Expired Identities", then that's not correct. That MPR would be matched in the System Event that causes the action.


Cheers,
Jorge




موضوعات مشابه: