The need for custom FIM 2010 sync rule functions

September 20, 2009 at 2:32 PMHenrik Nilsson

All of you that have been working with the ILM”2”/FIM 2010 sync rules have found the functions and custom expressions in sync rules and in the Function Activity (Ok, the Function Activity wasn’t very useful but there was a workaround, see Cortego Update Value Activity, this bug will be fixed in RC1) extremely helpful for extracting and formatting attributes or evaluation but most of you have also realized the functions are limited and in many cases you have to fall back on custom workflow activities or legacy flow rules for this.

For those of you out there that aren’t familiar with the functions and custom expressions could have a look at these excellent blog posts for more info:

During the session What’s New in FIM 2010 RC1 held by Mark Wahl at TEC 2009 Europe in Berlin we were told that custom functions wont make it to RTM but during the FIM 2010 Chalktalk session I called out for this to be added as soon as possible and I got strong support for this by Markus Vilcinskas (Thanks Markus!!!). The not perfect but positive answer I got was that this might end up in a future Feature Pack that the product team already seems to be planning and these Feature Packs might even be pushed out using Windows Update.

So why is this something I find so important?

The functions are simple and powerful but the available functions in RC0 are limited, maybe they’ll add more functions within RC1 but it wont be enough for all possible cases you’ll get into. Those of you that have had a look at my Activity Library could see that Normalize Diacritic Characters Activity, Regex Replace Activity and Generate Password Activity would make more sense as function calls but except for the Regex Activity they probably wouldn’t be suitable as a built in functions. The remaining two activities in my library, Unique Name Activity and LDAP Search Activity (the Update Value Activity will be removed from RC1 since the Function Activity included in FIM will be able to update values from RC1) would probably not be suitable as functions since they call out for external information.

Having a look at some of the functions found in the common .Net objects and compare this to what is available in RC0 you probably understand what I mean:

  • Conversion functions – For example converting accountExpires, lastLogonTimeStamp and pwdLastSet to and from Int64.
  • IndexOf or Contains - To find out if a string is contained and where, without this the included Mid function isn’t useful unless you’re absolutely certain your attribute has an exact format.
  • Len - To be able to find out the length of a string, useful to find out if for example the userAccountName attribute is longer than the allowed 20 characters in AD.
  • StartsWith, EndsWith - similar to IndexOf and Contains but could be easier to use in some cases.
  • Format - I just love this function on the .Net string object and I think it could be really useful even thought I understand it could be hard implementing a user interface for because it takes any number of input values.
  • Now – Date function to get the current date and time.
  • AddDays, AddHours, etc – System.DateTime functions for decreasing and increasing date and time values perfect for setting ExpirationTime attribute.
  • DayOfWeek, DaysInMonth, IsLeapYear, etc. – Other date time functions that could be useful in some cases.
  • Any more advanced function you might be in need of as long it’s kept simple and static.

If you have an idea of your own of what could maybe be implemented as function please add a comment to this blog post.

Am I alone in this wish?

I don’t think so, if you have a closer look at the feedback session at the ILM”2” connect site (you must have a connect account for access) or the ILM”2” forum at TechNet you’ll find a lot of request for this and cases where this could have helped out.

With custom functions FIM 2010 will be a lot more complete product!

What's the problem then?

If you have a look at Administration/All Resources in the portal you’ll see there’s already an object type called Function and when having a closer look at any of the functions you can see there’s a referenced dll and namespace, pretty much like with workflows so I believe custom functions are already prepared for unless this is for presenting functions in the UI only but then the reference to namespace and dll would be unnecessary. Personally I think the product team found out it was going to be hard to evaluate and execute function calls not to mention the possibility for abuse if they were allowing for custom functions since the function calls are executed on behalf of the sync engine.

Functions from within the portal

Having a deeper look at the bits and pieces of the current implementation the available functions together with the code for evaluating and executing the functions are implemented in the FunctionLibrary.dll, the dll referenced from the portal. Inside the FunctionLibrary.dll there is a class named AttributeFlowMappingHandler that derives from the interface IMASyncRuleCallout that is a part of the Microsoft.MetadirectoryServicesEx.dll – the same library you reference when creating MV and MA extensions! This is interesting because then there’s already an extension point from within the sync engine to a custom function library but unfortunately that’s not enough unless you wish to disassemble the FunctionLibrary.dll and make your own additions to it and then replacing the original one but that’s nothing I recommend even thought you’re an experienced developer and I’m not sure it would work anyway. What we need is a simple extension point, like for workflow activities where we reference our function library (the functions only), maybe evaluation code for each function and documentation.

Agree?

If you agree with me on this you’re welcome to join the struggle! You could for example make a comment on this blog post, make a post on your own blog, talk to any FIM 2010 team members you might know or meet, post a feedback to the connect website (Feedback is still open) or why not all of the alternatives! :-)

Posted in: Forefront Identity Manager | Identity Management | Sync Functions

Tags:

Comments (1) -

For me the lack of custom sync rules are a jolly good reason not to use them at all. Other reasons include:
- I don't want to mess with EREs and DREs just to get export flow rules working and,
- I fundamentally don't like the idea of managing sync rules away from the sync engine. There is no preview function available until you have actually imported the sync rule into the metaverse. It will be too easy for someone to change a portal sync rule without a full understanding of the potential impact.

If it wasn't for that "Create object in FIM" tick box on the import rules, I would not use them at all. As it is I will probably use the portal sync rules for import only.

Reply

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading