Passing data from a custom Workflow via the Request object

I have been writing an activity that resets forgotten BPOS passwords (more on that later) and I wanted to include a Notification activity that would inform the user about the password reset request. To make the notification useful I want to include whether the reset succeeded, and if it failed, what the reason was. To do this I need to be able to pass information from the custom “Change BPOS Password” activity to the Notification activity.

What does the documentation say?

The first thing I did was consult the official document Developing Custom Activities and Workflows. The only thing I could find about passing data was this:

Passing Data between Workflow Phases

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

1. Create and bind one or more attributes to the Request resource type in the FIM schema that can store the information that you want to share between activities. You can do this through Web services or by using the FIM Portal.
2. Grant permissions to the person or resource that will be assigned to the ActorID of the activity to read and modify the new attribute. Note that this step is not required if the ActorID is set to the FIM Service Account resource. For more information, see Microsoft.ResourceManagement.Workflow.Activities.
3. In the authorization workflow activity, use the UpdateResourceActivity activity to set the desired value on the new attribute.
4. In the action workflow activity, use the ReadResourceActivity to get the value of the new attribute.

However this didn’t seem to address my simpler situation. I’m not trying to pass a value between an AuthZ and an Action workflow – I just want to pass the data between two steps in the same Action workflow. Perhaps I can use a WorkflowData parameter?

But as I thought about it I decided that maybe the method mentioned in the documentation was the right way to go. Essentially I am updating the request object itself with the results of the activity, and this then forms a permanent record. To jump ahead in the story, here’s what a request object looks like after a failed password reset operation. I think that’s pretty useful!

Create the Attributes

So following step one from the documentation, I created the following attributes and bound them to the Request resource type:

• “Activity Status” – indexed string. This will normally contain “Succeeded” or “Failed”.
• “Activity Status Message” – unindexed string. Here I can put extra info about why an activity failed.

Grant permissions to the new attributes

I added the new attributes to both of the following MPRs:  Request management: Request creators can read their approval resources and Request management: Request participants can read their request resources.

I also updated Administration: Administrators can control requests because I’m using the FIM service account to make the changes to the request (note the documentation above says you don’t have to do that if using the service account . I think that may be a mistake as rights always have to be granted, and I certainly had to).

Code the custom workflow activity to update the Request

The custom workflow must include a CurrentRequestActivity to get the details of the current request – I think this is probably standard anyway. Here I’m finishing up with two UpdateResourceActivities which update respectively the “Activity Status” and “Activity Status Message”. And I also need a code activity somewhere to feed the values to the UpdateResourceActivities. I tack this at the end of the code activity where I’m running my password reset code, because that’s where I have easy access to the results of the reset attempt. This code that sets up the UpdateResourceActivities is below. Note I am using the Built-In Admin account to update the request object. The variable “failureMessage” was already set earlier in the code.

    Const FIMADMIN_GUID As String = "7fb2b853-24f0-4498-9534-4e10589723c4"

    '' Prepare variables for UpdateRequest activities which write the activity status back to the Request object.
    Me.updateRequest1_ActorId1 = New Guid(FIMADMIN_GUID)
    Me.updateRequest1_ResourceId1 = Me.currentRequestActivity1.CurrentRequest.ObjectID
    Dim updateInstruction1 As New UpdateRequestParameter
    updateInstruction1.PropertyName = "ActivityStatus"
    If success Then
        updateInstruction1.Mode = UpdateMode.Modify
        updateInstruction1.Value = "Succeeded"
    Else
        updateInstruction1.Mode = UpdateMode.Modify
        updateInstruction1.Value = "Failed"
    End If

    Me.updateRequest1_UpdateParameters1 = New UpdateRequestParameter() {updateInstruction1}
    Me.updateRequest2_ActorId1 = New Guid(FIMADMIN_GUID)
    Me.updateRequest2_ResourceId1 = Me.currentRequestActivity1.CurrentRequest.ObjectID
    Dim updateInstruction2 As New UpdateRequestParameter
    updateInstruction2.PropertyName = "ActivityStatusMessage"
    If success Then
        'No message
    Else
        updateInstruction2.Mode = UpdateMode.Modify
        updateInstruction2.Value = failureMessage
    End If
    Me.updateRequest2_UpdateParameters1 = New UpdateRequestParameter() {updateInstruction2}

Accessing the values from an Email Template

My final step is to create the Email Template that will be used by the Notification Activity.

For the Subject:

BPOS Password Reset [//Request/ActivityStatus]

And in the body I add the following:

<p class="MsoNormal"><b>Request Status:</b></p>
<p class="MsoNormal">[//Request/ActivityStatus]</p>
<p class="MsoNormal">[//Request/ActivityStatusMessage]</p>
<p class="MsoNormal"><o:p> </o:p></p>

The result is that the password reset operation runs and depending on the result of the attempt, the user gets one of these emails:

And I think that that’s pretty cool!