Another stream of thought post...
Some questions keep popping up about validation and I thought I'd try to clarify it a bit.
What is Validation
I've never seen a good definition for what validation in IS is supposed to be or what it's supposed to do anywhere. There is a lot of discussion about what components do when validating, but before launching into a discussion about it, I thought it would be helpful to give a little history and explain a little of the philosophy behind validation. This will likely be better than a straight definition because, hopefully, you'll understand the evolution and reasoning behind it rather than just a static description.
Early Design Iterations
Early on, I remember walking into perhaps the first design review of what was later to become the runtime. Among all the proposals in that review, there was a new method on the task interfaces called Custom or something similar. (Can't remember, after all, it _has_ been 5 years now) Nobody liked the name but everyone liked the concept. The idea was that it would be a method that the runtime would call “sometime” before execution to give the task a chance to “do stuff” before executing. Pretty vague, yes. I wished all ideas and designs would just spring into my mind fully formed on the first day of a project. Just doesn't seem to happen that way. If you know of anyone that does this, let us know. We're hiring. :)
As I recall, Gert Draper, who was our PUM at that time suggested that we call it Validate. Hmmm, has a nice ring to it. Makes sense, because, typically, what folks want to do before executing is make sure that execution will succeed. Gert asked why we need to pass in variables, and connections etc. Well, I said, somewhat unsure of my answer. After all, this was Gert. :) “Well, because the tasks may need to use them for the work they do during validation.“ Knees knocking, hands shaking, teeth chattering. Gert says, “Oh, OK“. Boom? A new method is born and with that the start of a new concept that needed to be developed. It's interesting how one little old method can spawn multiple discussions and philosophical discussions.
Validation caused a whole lot of confusion and discussion. We talked about “deep validation” vs. “light validation“. That debate raged for months. What type of validation should components do? We talked about what other components should do. At the time, we still didn't have the notion of extensible log providers, connections or enumerators. Later, when those were “componentized“, we only passed variables. The logic went, “Why would anyone need connections for a log provider?“ Hmmmm...
The light validation discussion was very interesting. A lot of talk about how to indicate to the task that the validation was just preliminary vs. pre-execution validation etc. The thought being that you wouldn't want to validate a task strictly if the task was being configured or had property mappings etc. We didn't have the notion of warnings and information events either. Only errors which were inflexible and for purposes of validation, terminating. Out of these discussions grew the notions of Warnings, later came information events. Eventually, we scrapped the whole idea of light validation vs. deep validation. Warnings enabled tasks to give information and yet still say they could function in spite of the issue they were reporting. Slowly we migrated to a point where validation was just validation. No variants. Then we arrived at the definition we have today.
Validation is what a component does to detect any issues that would cause it to fail during execution.
This led to a few other “rules“
- When a component validates, it should always validate that given it's current property settings, it will succeed during execution.
- Components should not return when they find the first error. They should continue to validate until finding all errors. This allows for a better picture when the whole error stack of errors is visible.
- Components should emit warnings for cases where the error is not fatal, but could cause problems. For example, when the send mail task doesn't have a subject. Non-terminative errors.
- Some others I can't remember right now...
Now the problem is, when do components get validated? Essentially we look at validation in a number of different ways depending on the situation. If you're designing a package, you'd like to know that it has errors during design, not when you go to execute it. So, the designer takes some liberties here and validates components whenever the UI for the component is modified. When a package is opened, the designer validates it as well. These are design time validations that should not be confused with execution time validations. These are done to ensure that the package writer is alerted ASAP to problems with the package.
Execution Validation
Execution validation is perhaps where most folks get tripped up. Execution time validation happens at two key points. When the package is executed and when the runtime executes tasks in the package. In the designer, this can be confusing. Because it's validating all the time and because it appears that the package is running in the same process as the designer, it seems there is no clear distinction between design time and execution time validation. But the designer doesn't run the package in it's own process. It actually runs it out of process (for a number of reasons I won't go into here). So a host process loads the package and executes it. When the designer calls Execute() on the package, the package validates. Everything in the package gets validated from the package down to the containers to the components. This is general validation. Then, when the runtime calls execute on each task, the TaskHost calls validate again. This is component validation.
Early vs. Late Validation
Why? This is the confusing part. Since we want folks to always do strict validation, (remember no light validation), and since packages have the notion of late configuration or dynamic configuration via property expressions and foreach loops etc., and since we make the assumption that you would rather have a task fail validation then to corrupt data or otherwise fail execution in a destructive way, we validate twice. We validate the whole package and we validate each individual task right before execution. In fact, if you were to look at the TaskHost code, you'd see something like this:
ExecResult Execute(parameters)
{
ExecResult = Task.Validate(Parameters)
if(FAILED(ExecResult))
return ExecResult;
return Task.Execute(Parameters)
}
Now, some tasks aren't going to be ready to execute when the package Execute() method gets called. They may rely on a variable value that gets set by another task further up the package call chain. They may be waiting for a file to be generated or dropped etc. So, if there was no way to validate tasks after Execute() gets called on the package, the package would never run successfully. However, the runtime needs to know when this is the case. There is no way for the runtime to know when to validate early or late. Enter the “DelayValidation” property.
DelayValidation
This property tells the runtime, “Don't validate me until the very last instant”. This property is on all containers and all hosted objects. It's a simple flag. When the early, package level, validation happens, the runtime checks this flag. If set to true, the runtime skips validating that part of the package. Think scope here. If there is a container with multiple children containers with multiple grandchildren containers, and that container has set DelayValidation to true, none of it get's validated early. The whole thing gets skipped.
Late Validation
Later in the package execution, the runtime will call the individual Execute() method for tasks. Then the runtime will call the Validate() method of the task implicitly when it calls the Execute() method. Now, if the task fails validation, you're sure that it would have also failed execution because there is very little chance that anything will change between the time that the runtime calls Validate() and Execute().
Validation is important because it gives early warning of critical issues. It's the way all the nifty little icons pop up in the designer when there's an error. When you move your mouse cursor over the little red x in a task, and the error message shows up in the tooltip? That's the result of validation. Validation keeps your system safer because components check to ensure that the operation will be successful, or at least has a good chance of success before performing potentially invasive or damaging operations. Validation is to packages what compiling is to source code.
Hope this helps.
You can see more about Validation in books online here:
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/dtsref9/html/dc224f4f-b339-4eb6-a008-1b4fe0ea4fd2.htm
Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden