Event Handlers and Checkpoints

[James Beresford]

I was recently playing with creating a Package based logging and auditing system using Event Handlers. The principle being that I would use the firing of the Event Handlers to drive Inserts into a database table that could log package events. In doing so I came up against one problem I knew about and could work around and one that I didn’t that frustrated my plans. I have created a sample package which demonstrates both issues here

Why do Event Handlers fire multiple times?

Event handlers fire multiple times because they fire both at the package and control flow component level. If you run the sample package you will note that the OnPreExecute event fires 3 times - once for the package and once for each of the two steps on the control flow. If you want to control the Event Handler so that it only fires once at the package level, you need to precede any activity with a constraint that means it will only execute if System::SourceName = System::PackageName. I usually do this by just putting in a Script Task with no code as the preceding task on which to base the constraint - it will always succeed and doesn’t slow things down.

Which Event Handlers fire when resuming from a Checkpoint?

This one’s easy - none of them. This caught me slightly off guard, but the Checkpoint file resumes the package from the exact point at which it failed, and does not re-run already fired Event Handlers - if you run the sample package twice (once to fail, once to resume from the checkpoint) you’ll notice that first time you run it, my annnoying message boxes pop up showing all sorts of events firing. The second time you run it, it resumes from the precise point of failure - no validation, pre execution or even error events fire at all. Which means if, like me,* you want to log a package restarting from a checkpoint by using an event handler - you can’t!



More...