The Package Container

The Package Container

We come now to the Package container. The package is to the Integration Services user what the canvas is to the artist. It is the starting point upon which you build solutions. It's not just a container either. Most of the settings that impact the contents and execution of the package are found on the Package container. Get to know the package properties better and you'll increase your understanding of workflow in Integration Services.

Packages are essentially souped-up Sequence containers. In fact, if you were to look at the code for the Package container, you'd see that the code that is run when the package executes is the same code that is run when a Sequence container executes. The difference is that packages are treated differently internally. They are considered the top-level container and represent the outermost structure of packages. They also have a lot more properties and collections of objects than do the Sequence containers. The following are collections found only on the Package container.

• Connections All the connection managers

• Configurations All configurations

• LogProviders All configured log provider objects

• ExtendedProperties A collection of variable-like objects for package clients to store values

The first three have already been discussed in some detail, and later chapters cover these collections in even greater detail. However, the final collection, ExtendedProperties, hasn't yet been discussed. This collection is a place where clients of the package can store data and is interesting because it's the only property or collection on the package, or any other container for that matter, that the object model persists but doesn't use. The object model provides this collection so that third-party developers or object model clients can have a place to store private data related to a package and that remains with the package, but is not modified or lost when saving or loading. This is how the designer stores the layout information for a package.

If you open a package created in the designer in Source View, the ExtendedProperties are visible at the very beginning of the package. There is a package variable node that looks similar to the following:

[View full width]
<DTS:PackageVariable>  <DTS:Property DTS:Name="PackageVariableValue" DTS:DataType="8"> &lt;Package xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001 /XMLSchema-instance" xmlns:dwd="http://schemas.microsoft.com/DataWarehouse/Designer/ 1 .0"&gt;&lt;dwd: DtsControlFlowDiagram&gt;&lt;dwd:BoundingTop&gt;1468&lt; /dwd:BoundingTop&gt;&lt;dwd: Layout&gt;&lt;dds&gt; More of the same... </DTS:PackageVariable> 

This is the substantially shortened layout portion of the package. The designer stores all the information about where the objects are located and saves it all into an XML document. The designer then stores the XML document in an ExtendedProperty.

The ExtendedProperties collection isn't exposed through the designer. It's only available to object model clients. But, it's included in this discussion to help further differentiate packages from other containers and to emphasize their extended role as the outermost containers.

Note

In the "how products evolve" category, the node for ExtendedProperties is called PackageVariable even though the collection is called ExtendedProperties and the object is called ExtendedProperty. Originally, the collection was called PackageVariables, but people were confused by this. Some thought that PackageVariables were just variables at package scope. The node name remained PackageVariable so as not to break packages that were written before the change and Microsoft never revisited the issue to make the persisted node consistent with the name of the objects.

Important Package Properties

In addition, several properties are unique to the package. Many of these properties are covered in detail in other chapters. However, some brief introductory discussion is in order.

PackageType

This property should have been called WhichDesignerCreatedThisPackage, but that would have been a little long! So, it's called PackageType. It's actually a holdover property from DTS and is an enumerated value. There are six possible values as follows:

• Default This value is what is used if the client doesn't change it. For example, if you create a package through the object model, the type is the default.

• Wizard This value indicates that the Import/Export wizard created the package.

• Designer This value indicates that the package was created with the DTS designer. If a package has this value, it was likely migrated from a DTS 2000 package.

• Replication Replication used DTS for some purposes and still does. This setting is rare, but if a package has this value, it was likely migrated from a DTS 2000 package.

• Designer90 This value indicates that the package was created in the Integration Services 2005 designer. Each future designer will have a unique value with an incremented postfix version identifier.

• DBMaint This value indicates that the package was created in the Database Maintenance utility in SQL Server Management Studio.

Changing these values is not advised, especially for the DBMaint types because DBMaint is a scaled-down Integration Services designer and usually fails to load packages it did not create.

CreatorName

This is the NetBIOS username of the individual who created the package. It is set when the user creates the package and Integration Services never changes it again. It's OK to change this at any time. Integration Services never uses this property.

CreatorComputerName

The is the NetBIOS computer name of the computer used to create the package. It is set when the package is created and Integration Services never changes it again. It's also OK to change this at any time.

CreationDate

This is the date when the package was created. Integration Services does not use this value in any way and it can be changed at any time.

MaxConcurrentExecutables

This property has confused and confounded newby and experienced Integration Services users alike. It's a simple concept, but the name is confusing. Basically, this is the number of threads the runtime execution engine uses to execute executables. The default is four. The maximum is 128. If you set the number higher than 128, the engine automatically uses 128. If you set it to zero, the engine automatically uses four threads. Finally, if you set the value to -1, the number of threads used is the number of processors on the machine plus two. So, if there are four processors and you set MaxConcurrentExecutables to -1, the runtime execution engine uses six threads. Also, don't confuse this number with the Data Flow Task's EngineThreads property. That property is a hint to the Data Flow Task how many threads it should use.

PackagePriorityClass

This is another holdover from DTS. It changes the priority the runtime engine uses for its threads.

VersionMajor

This is the first of three values you can use for versioning your package.

VersionMinor

This is the minor version and can be used anytime you make minor changes to the package.

VersionBuild

The designer increments this value every time you build the project in which the package is found. You can change any of the version number properties at any time without a problem. Integration Services does not use these properties other than incrementing the VersionBuild value.

VersionComments

This property can be used for any comments you might have about the current or past versions. It's provided to give you a way to document the changes to the package at certain milestones.

VersionGUID

The Integration Services runtime changes this value every time you save the package. It is read-only and should not be modified.