FIM Workflow vs SharePoint workflow
Hi, We are building a SharePoint 2010 extranet that will be used as the interface for external users to update information about their accounts. Their accounts are all managed by FIM and some changes require approval. Would it be better to use the FIM Web Service to try to enact account changes on the FIM side or would a SharePoint workflow be better. My instinct is that the FIM Web Service would be the better approach, but I'm not very familiar with how Workflows in SharePoint 2010 might interact with FIM 2010, so wondering if there is anyone who has tried either approach and what your experiences are. Thank you in advance for any help. Thanks, Sami
August 23rd, 2011 9:54pm

Sami- I don't know anything about SharePoint workflow options, really, but, if you can do approvals there then I'd think either would work. If you want to run the approvals through FIM, though, you're going to need to build a custom webpart/etc for SharePoint of some sort that calls into the FIM Web Service APIs...My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com
Free Windows Admin Tool Kit Click here and download it now
August 24th, 2011 12:55am

Hi Brian, I think I'm leaning towards the FIM workflows to keep requests in the audit log and not impact any of the reporting features that may rely on that. It's a little more work for the web developers, but keeps all change history in one place. Does that seem like I'm thinking this through properly? Thank you for your help. Sami
August 24th, 2011 4:05pm

Sami - WSS (SharePoint) workflows are generally anchored off WSS lists (this is kind of like a custom resource type in FIM speak), i.e. you tie a workflow to certain changes you define to your list items. SharePoint devs are used to working with WSS lists, and these can be hooked up to FIM via a management agent like any other data source ... it just so happens that there are already a few examples around the place of WSS List management agents (UNIFY has one). Another resource type in WSS is called the UserProfile ... and in MOSS this is extended significantly (full-blown extensible user schema). The UserProfile drives "presence" information, and is also linked to the logged in user by domainName\sAMAccountName. However when I last worked with these profiles it wasn't obvious if there was any way of anchoring a WSS workflow to changes to the UserProfile ... it *should* be possible, but I haven't been able to do it myself. The UNIFY management agent for SharePoint can talk to this object class too ... and one other (the Organisation class). So ... the first question is what resource type are you talking about when you say "update information about their accounts"? The second question is would you consider using the sync engine to synchronize WSS user objects with FIM user objects? If you pursue the above idea (as I have) then you can leverage FIM workflows AND WSS workflows - whatever makes best sense - and you can still have your complete audit trail in FIM as a result of the sync. Make sense? The benefits of such an approach would include leveraging the existing skills of your development team, without having to learn how to integrate with FIM. However, if you wanted to wrap FIM approvals around a change that was synced from WSS, you couldn't ... for starters changes applied to FIM by the sync service can never fire an AuthZ workflow. So you start thinking down this path, and you want to wrap approvals around "self service" changes in WSS, you would either need to do this in WSS workflows, or do what you were thinking and teach your developers to integrate directly with FIM as Brian talks about. Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine
Free Windows Admin Tool Kit Click here and download it now
August 24th, 2011 4:32pm

Thank you both! We are still fleshing out the exact steps that the workflows need to take as well as how the Extranet will function, so I'll have to weigh these options as we make decisions. Thanks, Sami
August 24th, 2011 4:44pm

The approach I would be looking to take would be to keep the WSS and FIM workflows separate (theoretically it is possible to export/import XOML from WSS to/from FIM, but I personally wouldn't even try). By default WSS workflows have always been driven from WSS lists, and so if you want to invoke WSS workflows using FIM you would normally be thinking about synchronizing say FIM Portal attributes with a WSS List management agent (ECMA) ... for example you may have a "status" attribute in your WSS list which is used to drive WSS workflows, and you would synchronize this with a similar FIM attribute. I don't know how much things have changed for MOSS 2010, but it may also be possible to trigger WSS workflows for changes made to User Profiles (which can be synchronized with FIM user objects via a MOSS User Profiles ECMA (or perhaps something OOTB now?). I had been using ECMAs with WSS 2003, but since 2007 I've used Identity Broker for SharePoint to do exactly this. So which workflows to use? "Horses for courses" as they say ... use FIM for all your identity management workflows to trigger workflows such as leave notification workflows which may have previously been built in MOSS. There are always going to be some workflows which are harder to build in FIM, mainly because MOSS/WSS workflows have been around many years longer, and the tools for building these workflows (e.g. Nintex) are much more advanced. In the end you will decide which platform to used for which workflow based on cost, supportability, and best fit for purpose.Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine
Free Windows Admin Tool Kit Click here and download it now
November 4th, 2011 8:18am

Hi Bob, we have a case similar to sami's. we are working on a sharepoint page to manage user accounts that are in FIM. actually we decided to use a custom Sharepoint page because of the limitations in the FIM user management portal. we are not sure yet how to get the users into the sharepoint page we are thinking of two options: either by calls to the FIM web service to retrieve users and then update them or by synchronizing user accounts in FIM to sharepoint user profiles. i guess the second option is better in terms of performance. Now the main question is for workflows, now that FIM 2010 R2 will be integrated with sharepoint 2010, is there an integration in the workflow sense? moreover we are not sure which workflows are better to use. i read your answer above but i am not sure i understood what you mean by leveraging FIM and WSS workflows. if we use userprofiles we would be using WSS workflows right? where would FIM workflows come here. thanksMM
November 5th, 2011 5:14am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics