One of the updates found in FIM 2010 RC1 Update 1 as David points out is the ability to ensure Requests and Workflows (WF) created on a specific FIM Service Partition are executed only on the same FIM Service Partition that it was created on. FIM Service Partitions only matter if you run 2 or more FIM Services that are connected to the same FIM Service DB.
To give you some context on this change, it is important to understand some background information about how Request & WF Host works in RC1.
Requests come into our system via the web service and are then handled internally via the Request Processor, if there are any Workflows generated, they are added to a WF queue. This means we operate on a polite first come, first served basis.
This is fine for end users, but when you account for administrative tasks like sync or run on policy update, which can generate hundreds of thousands of Requests, then your end user Request with its associated Workflow(s) could be at the end of a very long line before its Workflows execute. You wouldn’t want an end user trying to create a distribution group waiting behind 100k WFs kicked off from an export that you just finished from Sync.
The solution is providing the ability to setup separate middle tiers where one or more can process sync\admin Requests & the other can handle your end user Requests and WFs
In RC1 this was possible as each Web Service has it’s own WF queue and puts WFs it generates into it’s own queue.
The problem in RC1 was that when a FIMService starts it can resume any Request or WF that was previously persisted to disk (cases 1-4 below). Therefore a Request or WF from the “Admin” portal can be resumed by the “User” portal and vice versa. At this point you no longer have control of your queue size and can’t protect your “User” Requests from being queued up behind Admin Requests.
Requests and WFs save their execution state in the following cases:
We resolved this by introducing (in RC1 Update 1) the concept of Service Partitions. A Service Partition is just a unique way of identifying one or more servers that will share the processing of Requests and WFs in the system.
In the above diagram I have the following Service Partitions created.
There is also an additional consideration of which of these servers do you want to process mails from Exchange & generate Requests. These servers will need to have polling enabled, which will be shown in the next section.
Configuration of multiple middle tiers in your environment is pretty straight forward. Here are the steps to setup the above topology.
Now what you have is a guarantee that FIMPortal will only ever execute Requests & WFs that were created by end users in the Portal, FIMAdminPortal will only ever execute ones from it or Sync, & FIMPassword will allow Requests & WF processing to execute on either of the 2 NLB Password boxes.
Note: To fully take advantage of this topology you will need to also need to configure your clients appropriately to send password reset Requests, Outlook plug-in mails, & Portal links to the right servers. I will cover that in my next post.