Friday, October 4, 2013

Declarative or Bust!

Michael Pearn from down under wrote about his experience trying to use just Declarative Sync Rules

His experience -- especially the religious debates are similar to my own. It made me recall my presentation at TEC 2012 the FIM 2010 R2 Showdown: Classic vs. Declarative

The vast majority of old hands at the presentation declared for Classic both before and after the presentation. During the presentation I attempted to view anything you could do without code as declarative whether it came from a sync rule or not, especially if it was a new feature. But the crowd wouldn't let me claim anything configured in the sync engine as declarative. But in this post only classic code counts as not declarative.

Michael found that he needed classic code for Advance Join rules, doing anything with multi-valued attributes other than just flowing them and "Converting Binary values to ISO8601 Datetime." In his example he could have modified his SQL query that gets the data from HR and avoided the need for the Advanced Join rule.

In addition to Michael's list here are some other things that you may need classic code to do:

  • Advanced Filtering scenario to cause disconnections
  • Changing the Metaverse object type when a connector joins to it
  • Join Resolution Rules
  • Manual Precedence Import Flows
  • Provision objects with Auxiliary classes
  • Decide on a case by case basis whether to deprovision as a Disconnector, Explicit Disconnector or just delete the object.

But what does the FIM Sync engine bring us beyond what we had in ILM 2007 FP1?

  • A lot less need for MVDeletion rules extension since we can indicate that disconnection from any of a list of MA's should trigger MV Deletion or if it is disconnected from all MA's (but ignore this one and that one)
  • Many, many attribute transformations can be done with Sync Rules and don't need code
  • A way to do fairly sophisticated provisioning logic without code (Transition Sets, MPRs, Workflows, OutBound Sync Rules)
  • R2: A way to do some basic provisioning logic with filter based Outbound Sync rules that performs pretty decently and doesn't require a detour through the FIM Service
  • New ways to trigger deprovisioning (Transition Sets, MPRs, Workflows, OutBound Sync Rules)
  • OU creation w/o code (That sure is nice and no worried about the OU being a connector to the MV object that first needed it)
  • DN Rename w/o code (also very nice)

In my presentation I contrasted the new sync rules with the classic config and code:

image

 

image

image

image

image

image

image

image

image

Finally here were my recommendations that many disagreed with but it sounds like Michael would agree:

image

There are some high volume scenarios where sync rules are too slow and there are still some customers that get all they want out the classic sync engine and don't want to pay for CALs.

3 comments:

Craig Martin said...

I see two challenges:
1. There is not feature parity between the two types of sync rules
2. The imperative support (VBA) in the new sync rules is limited and difficult to debug

My wish is that we had better extensibility in the new sync rules (scrap VBA, or figure out how to improve the extensibility and debugging).

Also, choosing between declarative or imperative is a bad choice because you'll always need bits of both. PowerShell is a good example, in the new Desired State Configuration feature:
http://www.powershellmagazine.com/2013/07/05/imperative-versus-declarative-syntax-in-powershell/

Guy Horn said...

This is a very technical comparison. Let’s look at other arguments.
• Skilled people for declarative are easier to find. Software writers are scares.
• The portal knows the sync, but not vice versa. So Understanding the whole logic is much easier when using Declarative.
• Are we integrators or a software house? We don’t write our own virus scanner, do we?
• Reporting over Declarative is OOTB. Reporting over Classic is not available.
• Clients dislike these DLLs where all the “secret stuff” is.
• While it’s true that classic can do anything, that’s also the problem. If you look at the code you will often find some very creative stuff… I would lough if it wasn’t me.
• Judging by the development since ILM 2007, the future is Declarative. Who wants to be left behind?

Craig Martin said...

I think I get your perspective, Guy; you prefer a system that is easier to build and operate, and your priority is not extensibility. That sounds reasonable, but I think the goals are not exclusive. Maybe someday we'll have both, but in the interim Microsoft agrees with you ;-)