Friday, February 04, 2011

How Delta Sync and Full Sync Compare During Provisioning

A while back I posted on an obscure bug that the vast majority of customers will never see due to the scale required for it to repro: Reference Depth.

Turns out this taught me a lesson about a key difference between Full Synchronization and Delta Synchronization.

The scenario is this: you ran a sync and have objects pending export in a connector space.  Those objects are pending because you have not exported them to the target system yet, they’re just sitting there waiting to be exported.

If you were to Preview one of those objects from the source system again, using a Full Sync Preview you would see the following in the preview results:

“Auto-Deleted” followed by “Added”

So during a Full Sync of that object, the pending export is whacked, then replaced by a fresh new pending export.  This made total sense to me; something could have changed, our rules fired again, so the new object is created. 

Now if you were to Preview the same object using a Delta Sync Preview you would NOT see this behavior.  This is where I got confused, because I had a breakpoint in my rules code and watched as all the code was called, all the way down to CommitNewConnector().  But after watching that happen, there was no “Auto-Deleted” and no “Added”, there was no status reported for provisioning at all, like it never happened.

Turns out the rules extension IS called on both Delta and Full in this scenario, but on Delta the action is just thrown away silently by the server.  Well, it is only silent if you haven’t littered your code with trace logging, and if you’re not nosing around with a debugger.

The moral of the story here is that I’ve been working with this engine for a decade now and STILL learn new things about it – so one could argue the moral of the story is that I am not the sharpest tool in the shed, but most certainly a tool.

The real morals of the story are:

  • if you need a pending export deleted then added then you do not get this for free on delta synchronizations, only on full.  So code accordingly.
  • test, test, test.  If found this when I was writing test scripts against my MV code. 

Had I not been scripting this test case, I probably would have finished the engagement and nobody would have ever noticed my bug.  As much as it sucked to admit the mistake, I did learn something new about the engine, but most importantly it showed me that better test coverage increases deployment quality (duh).  In the end my tests were smarter than me, providing me with both humility and relief. 

No comments: