The FIM Service provides workflow activities that support creating, reading, deleting, and enumerating resources in the FIM Service database. For example:

1. Creating Resources: Use the CreateResourceActivity activity to create resources in the FIM Service database.
   
   
2. Reading Resources: Use the ReadResourceActivity activity to obtain a specific resource from the FIM Service database if you know the ObjectID of the resource.
   
   
3. Updating Resources: Use the UpdateResourceActivity activity to update resources in the FIM Service database.
   
   
4. Deleting Resources: Use the DeleteResourceActivity activity to delete resources in the FIM Service database.
   
   
5. Enumerating Resources: Use the EnumerateResourcesActivity activity to query for resources in the FIM Service database. You should use this activity when you are retrieving multiple resources, or when the ObjectID of the resource that you are retrieving is unknown. If you know the ObjectID of the resource, you can use ReadResourceActivity instead of EnumerateResourcesActivity.
   
   

Caution:
Authorization workflows should not modify resources in the FIM Service database. For more information, see Authorization Workflows Should Not Create, Modify, or Delete Resources later in this topic.

FIM provides the CurrentRequestActivity activity so that you can retrieve the current Request resource that is associated with the running workflow instance. A custom activity can use this activity to obtain information from the request that triggered it. A workflow activity may require the need to parse the RequestParameter property of a Request resource. This is commonly done in custom activities that perform some validation on the input of the request that triggered them. The RequestType class provides a ParseParameters() method to parse the RequestParameter property of a Request.

The following example demonstrates how to parse the values in the RequestParameter property of a Request resource and store them as a collection of the CreateRequestParameter type. If the request that is being parsed is performing an update operation instead of a create operation, you should use the UpdateRequestParameter type, because this type exposes additional information about the mode of operation (modify, add, or remove).

C#	Copy Code
ReadOnlyCollection<CreateRequestParameter> requestParameters = this.currentRequest.ParseParameters<CreateRequestParameter>();

Note:
In the previous example, currentRequest is a ResourceType property whose value is populated by the CurrentRequestActivity activity. The CurrentRequestActivity activity retrieves the Request property that is attached to the current workflow.

The SequentialWorkflow type derives from the System.Workflow.Activities.SequentialWorkflowActivity class. All workflows that are hosted in FIM must derive from the SequentialWorkflow class. An activity can use the TryGetContainingWorkflow method to retrieve information about the workflow that contains it.

Some scenarios may require that an authorization workflow share some information with an action workflow that runs for the same request. (For more information, see Request Processing.) The recommended approach for accomplishing this scenario is as follows:

Passing Data from an Authorization Workflow Activity to an Action Workflow

Caution:
All workflows should handle the case in which information about the original request, including data that is stored in custom attributes on that object, is not available when the workflow is run. For more information, see Workflows Might Terminate at Any Time later in this topic.

A workflow activity that is used in FIM may have all or part of its work repeated multiple times. An authorization or action workflow is re-created from its last persistence point when the FIM Service recovers from a service interruption. Any work that the workflow performs after its last persistence point is repeated. The same workflow activity may be run multiple times on the same target resource. This may happen unintentionally as a result of policy misconfiguration, or intentionally as a result of forced rerunning of a workflow.

For the previously mentioned reasons, it is important that repeating the actions of a workflow does not result in negative or irreversible impact.

You can also use persistence points as a defense against interruptions, particularly in long-running workflows. However, remember that the use of workflow persistence points in a custom activity introduces additional overhead to the workflow runtime. (For more information, see Performance later in this topic.) For information about workflow persistence, see Windows Workflow Foundation Persistence Overview.

Interrupted Workflow Behavior defines what the FIM Service does when it is restarted to handle each workflow that was not completed when the FIM Service is interrupted.

A running workflow in FIM can encounter an error or be canceled at any time, either by a user or by the FIM Service. Custom activities must ensure that the FIM Service, or any other systems that the activity interacts with, are left in a desired state in the event the activity is canceled or terminated before it completes its actions. You should design a workflow so that it can be restarted if it does not finish (for example, if the server goes down during processing). In this case, a new instance of the workflow is created that does not have access to the original Request object that caused the workflow to be run.

Consider the following guidelines to help make sure that custom activities behave appropriately if the activity does not complete correctly:

• Ensure that a workflow that runs partially does not have a significant negative impact, or cause irrecoverable damage.
  
  
• Wrap the activity’s operations in a transaction. You can do this by using Windows Workflow Foundation (WF) Transactions.
  
  
• In the event of a failure, use Windows Workflow Foundation (WF) Compensation to clean up after previously completed work.
  
  
• If a cancel request is issued for the activity, override the Activity.Cancel method to clean up appropriately.
  
  

All workflows should be serializable, so that if the FIM Service is stopped while a workflow is in the process of executing, the workflow’s state can be persisted and later resumed exactly where it left off. If a workflow is not serializable, the workflow fails to be persisted and is rerun from the beginning when the FIM Service is restarted. For more information about serialization, see Windows Workflow Foundation Serializable Overview.

For general guidance around exception handling in workflow activities, see Exception Handling in Windows Workflow Foundation.

If you want to terminate a workflow, the easiest way to do this in FIM is to throw an unhandled exception in the activity. This results in the workflow that contains the activity to terminate, and the message that you include in the exception is appended to the RequestStatusDetail attribute of the Request object that triggered the workflow.

All unhandled exceptions are also appended automatically to the WorkflowStatusDetail property of the WorkflowInstance resource in the FIM Service database.

An authorization workflow that creates, modifies, or deletes resources may leave an unwanted result if the Request that it is attached to does not finish its operation. You should not assume that after an authorization workflow activity finishes, the attached request will become authorized and commit its operation. Other authorization workflows that do not finish can cause the request operation to be denied or cause other problems to occur.

We recommend that you do not run two or more approval activities (see ApprovalActivity) in parallel. Doing this may cause the request to become stuck in the authorizing phase (see Request Processing). If multiple approvals are required, you can either include a larger list of approvers in an approval, or run the two approval activities sequentially.

The ReadResourceActivity activity and the EnumerateResourcesActivity activity enable custom activities to retrieve resources from the FIM Service database. Both of these activities expose properties that enable you to be selective about the attributes that are retrieved. Custom activities should use these properties to make sure that only the minimum set of attributes that are required by the activity are retrieved. Retrieving additional data can adversely affect the performance of the activity and the FIM Service.

The use of workflow persistence points in a custom activity introduces additional overhead to the workflow runtime. This can adversely affect performance if a large volume of persistence occurs.

Use the WorkflowStatusDetail property of the WorkflowInstance resource as a starting point in investigating workflow-related errors. All unhandled exceptions that a workflow encounters are automatically appended to the WorkflowStatusDetail attribute of the resource in the FIM Service database. For more information about how to debug FIM, see Troubleshooting Forefront Identity Manager Service.

It is important to always make sure that you thoroughly test custom workflows and activities before you incorporate them into a production environment.

In addition to verifying that the functionality of the custom workflow and activity is as expected, consider the following additional tests:

1. Verify the workflow activity has sufficient permissions to perform its operation.
   
   
2. Trigger multiple instances of the same workflow on the same target resource.
   
   
3. Stop the FIM Service while the workflow is running.
   
   
4. Start the FIM Service and verify that the workflow can resume successfully.
   
   
5. Cause the workflow to be terminated and verify that adequate information is provided about the reason for termination.