Scoping

Scoping is a term used to describe the visibility or availability of an object in a given context. This is the meaning of scoping in Integrations Services as well and is a function of containers. Containers define the scope of transactions, variables, execution, configurations, logging, connections, and events. In other words, depending on in which container the given object is created, it is visible to different parts of the package. As you might expect, scoping takes on slightly different meanings and is implemented in different ways for each of the object types. The following few paragraphs explain how scoping affects each of the workflow features.

Scoping in DTS

Scoping actually existed in DTS as well, it just wasn't as obvious. The name Global Variable actually hints at scope. The difference is that in IS, the concept of scope is formalized to a greater extent with the introduction of containers. The IS equivalent of DTS global variables is those variables found at package scope. Although, that's not "true" global scope, it is the equivalent to DTS global variables. True global scope variables would be variables that are available to multiple packagessomething the Microsoft team hopes to make available in a near-future release.

Transaction Scope

Containers expose the properties needed to configure transactions. If the container is configured to support a transaction, it begins the transaction when executed and either commits or rolls back the transaction, based on the container execution results, when it completes execution. Generally speaking, if the container execution succeeds, the container commits the transaction and if it fails, it rolls back the transaction.

Configuration Scope

Currently, only package containers expose configurations. Microsoft didn't see any compelling reason to extend the scope of configurations inside the package. So currently, configurations are only scoped at the package level.

LocaleID

LocaleID is, perhaps, self-explanatory. It is the ID of the locale that is used for all data operations in a given container. How the LocaleID property works and how it is scoped by containers is, perhaps, not so clear. LocaleID is inherited from the parent container to the child. By default, the package LocaleID adopts the system LocaleID and all children containers in the package inherit their LocaleID from their parents. However, you can override the LocaleID for a given container and all children of that container then inherit the new LocaleID. LocaleID affects how data conversions are performed. For example, the format of dates varies from locale to locale. For those tasks that perform locale-sensitive operations, such as data conversion or formatting operations, the LocaleID is important.

Variable Scope

Variable scope is mostly about visibility. For example, if a variable is defined at package scope, all objects in the entire package have access to the variable. Local scope variables, those defined closer to a task, are visible to the task and hide variables with the same qualified name at global scope. Chapter 12, "The Venerable Variable," covers variable scoping in detail.

Execution Scope

Typically, you might not think of scope relating to execution, but in Integration Services, the notion applies quite well. For example, in the designer it's possible to execute only portions of a package. If several tasks are in a container, right-clicking on the container and selecting Execute Task executes the entire container. Also, disabling a container disables all its child containers and tasks. Because containers are hierarchical, executing the parent executes the workflow it contains subject to the constraints within the container. This is true for all containers from the package to the Taskhost.

Connection Scope

Currently, connections are only scoped to the package level and visible to the entire package.

Note

Since the early releases of Integration Services, many users have commented to Microsoft that they want to see connections participate in scoping to simplify packages and provide more global connections "above packages" and to bring them closer to the object that's using them "down into packages," or on all containers. Currently, Microsoft is considering these options.

Logging Scope

Logging settings are configured in two package locations. Log providers are those components responsible for outputting log entries to different formats. Log providers have package scope and represent the actual objects that perform the logging. However, you configure log options on all containers. Log options are simple settings on containers that control the columns and log-entry types as they flow through the Integration Services object model to the log providers to be written out to the log destination. This design makes it possible to finely control the logging output from containers. For example, it's possible to log only errors from one portion of a package within a given Sequence container, while logging progress, errors, warnings, and information events from another container. The notion of scoping comes from the fact that logs destined to arrive at the same log table or output file can be filtered differently depending on the scope of the log settings. Logging is explained in detail in Chapter 11, "Logging and the Stock Log Providers."

Event Handler Scope

Each container has a collection of event handlers. Event handlers are containers that the runtime contingently executes when a task or other component fires an event. Each container can have event handlers associated with it that are dedicated to handling a given event just for that container. For the purposes of this discussion, it's enough to understand that event handlers are specific to, or in other words, associated with, only one container. Each container can have multiple event handlers associated with it, but an event handler has only one parent container.