While working with FIM there are a few things to consider which may affect how your system functions (or doesn’t). One of these items is how the workflows are developed. As part of this, a basic understanding of how workflows work is required.
Workflow operation can be summarized using these simple rules:
- Workflows activities called from an MPR run in parallel. Therefore, if an MPR calls multiple workflows, they all start at the same time and may complete at different times.
- Workflow activities can be run in series only if they are contained within a single workflow. Therefore, if you want to make sure something happens prior to the next step, you build a workflow with a series of activities instead of two workflows that do each activity separately and in parallel (see rule 1).
- If a request fires multiple MPR’s, the workflows of each type (authentication, authorization and action) are all started at the same time and all must finish before a request is completed. Therefore, if there are two MPRs that fire and each MPR has an Authorization workflow, both Authorization workflows must complete successfully before the data is written to the database. If you think about this, it really makes sense because if either of the “authorization” workflows fail, you want the whole request to fail otherwise, authorization failures in one MPR and successes in the other MPR may cause data updates that shouldn’t really occur (you’ve essentially short circuited the second authorization workflow by means of allowing the first to pass).
The key thing to remember, is that you have to decide on the balance between how many workflows you want to maintain and the overall manageability of the system itself. Personally, I like granular workflows because if they are independent tasks, then I don’t want a failure in one workflow to prevent the other activities from occuring (for example, setting default values).
I write this entry because I had put together a simple MPR with a single workflow with a series of activities that set default values. However, periodically there would be an issue setting one of the default values which would throw an error. Logically, this would stop the workflow execution therefore, preventing any of the other value settings I’m setting to be left “unset” (which is particularly troubling when dealing with booleans that control sets if you want to test for “explicit” true or false values because there is also the “unset” value as well. See my post on Boolean values.)