Hands-On Microsoft SQL Server 2008 Integration Services part 60 ppt

568 Hands-On Microsoft SQL Server 2008 Integration Services
T
ill now you have learned how to build SSIS packages on a server and run them
from within BI Development Studio (BIDS) or using the dtexec command
prompt utility, but you have not deployed the packages to other environments
or servers. In real life, you will be developing packages in development environment and
then deploying them into the production environment. The predecessor of SSIS, DTS
2000, struggled with the limitation of moving packages between development, test,
and production environments. Typically in DTS 2000, you had to edit your packages
manually to point the connection objects to the server to which you were deploying
your packages. DTS 2000 used an object called the Dynamic Properties task to update
package properties with the values retrieved from sources outside a DTS package
during run time to overcome the deployment issues, but it was not sufficient to address
the problems associated with complex deployments. This object has been removed from
the SSIS object model and has been replaced with SSIS package configurations.
Integration Services addresses the issues involved with complex deployments using
package configurations, as you will learn in this chapter. You can use different tools
and utilities to deploy a package in a step-by-step process. You can update properties of
package elements at run time using package configurations, create a deployment utility
to deploy the package, and finally run the Installation Wizard to install the package
either to the file system or to an instance of SQL Server.
The following table lists the development journey of a package:
Action Tool Used Result
Create package BIDS or SSIS Import and Export
Wizard or Programmatically
An XML-formatted SSIS package created—
e.g., package.dtsx
Create package configurations BIDS Package Creation Wizard Package configurations created in XML/SQL
Create deployment utility Build project Package deployment utility with manifestation file
Install package Package Installation Wizard Package deployed in SQL or file system
The first step in the deployment journey is to create a package, which you have

already learned in the previous chapters; you will be using those packages here to learn
about the various aspects of deployment.
Package Configurations
The next step in the deployment journey after having created a package is to create
package configurations. By now, you understand the versatility of variables and their
preferable use in packages over hard-coding the values. Also in Integration Services,
you can update the variable values using other components at run time to add some
dynamics to your package. Package configurations extend this concept to properties of
SSIS control flow components to add flexibility to the packages. Package configurations
Chapter 13: Deploying Integration Services Packages 569
allow properties of a package; its control flow container; or any of the tasks, variables,
or connection managers to be changed at run time. Package configurations are the
property/value pairs that you use to update the values of properties of a package or its
control flow components at run time. The package configurations make deploying a
package to other servers easier by allowing you to update properties exposed by the
package and its tasks at run time without actually editing them. You can use the same
configurations to deploy a package to several servers.
To use package configurations, you must first enable them for your package
using the Package Configurations Organizer utility provided in BIDS. The package
configurations are saved inside the package, which is an XML file. So if you want,
you can simply edit this file even in a basic tool such as Notepad to modify or add
a new package configuration; however, most people will prefer to use the Package
Configurations Organizer utility, as it makes creating a configuration very easy by
providing access to various objects such as already-defined configurations and available
properties to export, all inside a wizard-driven interface.
Once the package configurations have been enabled, you can add package
configurations. You can define more than one configuration for a package or apply
the same configuration to more than one package defined in your solution. You can
enable package configurations for one of your packages without affecting the way the
configurations are used in other packages. Various storage options are available for

storing your configurations, including reading them directly from the environmental
variables. The storage options for package configurations, discussed in detail in the
following section, include an XML configuration file, an SQL Server table, a registry
entry, or a variable.
Types of Package Configurations
You can open the Package Configurations Organizer dialog box by choosing the Package
Configurations option under the SSIS menu and enable the package configurations.
After you enable package configurations, you will choose the configuration types (see
Figure 13-1) in the Package Configuration Wizard before you can proceed to building
package configurations.
Depending on the configuration type you choose here, the package configurations
will be stored to different storage locations. The following list shows five different types
of stores supported by Integration Services package configurations. You can choose any
of these configuration types while adding a package configuration using the Package
Configuration Wizard:
XML configuration file
c
Environment variable c
570 Hands-On Microsoft SQL Server 2008 Integration Services
Registry entry c
Parent package variable c
SQL Server table c
XML Configuration File
When you select XML Configuration File in the Package Configuration Wizard,
you must then provide an XML filename, including the path. Here you can create a
new configuration file or open an existing file. Then you will be able to select any of
the properties or variable to add to the configuration file. You can include multiple
property/value pairs of configurations within the same configuration object using an
XML configuration file type. Selecting an executable (container) or a task adds all the
configurable properties in the scope of that container or task.

If you open the configuration file after it has been created, using any XML
editor or Notepad, you will notice that the root element, <DTSConfiguration>,
has two child elements, <DTSConfigurationHeading> and <Configuration>. The
<DTSConfigurationHeading> element contains details about the file, such as the name
Figure 13-1 Choosing configuration types for different storage locations
Chapter 13: Deploying Integration Services Packages 571
of the login that generated the file, the package name, the ID from where this file was
generated, and the generated date; the <Configuration> element contains information
about the configurations, such as the property path and the configured value.
Environment Variable
Selecting this option in the Package Configuration Wizard allows you to choose an
environment variable from the list provided. Using this type of configuration allows you
to update a property directly based on an environment variable.
Registry Entry
Integration Services allows you to store the configuration in a registry key by using the
Registry Entry configuration type. When you select this configuration type, you must
then specify a registry key and choose a target property that will have its value updated
by the registry key.
Parent Package Variable
When you are running a package as a child package using the Package Execute task
in the parent package, you may want to use a variable defined in the parent package to
set a property in the child package. To do this, you use the Parent Package Variable
configuration type in the Package Configuration Wizard. You can then specify a
variable name defined in the parent package to store the configuration value used to set
a property in the child package.
The package configurations are applied at the package loading time and not at the
package execution time, which occurs after the package is loaded and the configurations
have been applied. So, when you run a package, the package is loaded as a first step,
then package configurations are applied, and then the package is executed, though
there is one exception to this: when you use the Parent Package Variable configuration

option, the configuration is applied at execution time. This makes perfect logical sense,
as the parent package variable needs to be already populated by the time the child
package is being executed.
SQL Server
By choosing SQL Server as the configuration type in the Package Configuration
Wizard, you can store the package configurations in an SQL Server database table.
Using the SQL Server configuration type, you can store multiple property/value pairs
of configurations within the same configuration object. You can use the SQL Server
configuration type to store all the configurations for your project in the same table and
use it as a central store to keep configurations.
572 Hands-On Microsoft SQL Server 2008 Integration Services
The connection to the database that you select to host the table can be created as a
new OLE DB Connection Manager, or you can specify an already-existing connection
manager. The SQL Server configuration creates ConfigurationFilter, ConfiguredValue,
PackagePath, and ConfiguredValueType columns in the new table you create.
Hands-On: Applying Configurations
to Contacting Opportunities
In this Hands-On exercise, you will use package configurations to change e-mail
addresses and demonstrate how package configurations can affect the working of a
package. For demonstration purposes, you will use the Mailing Opportunities.dtsx
package you built in Chapter 4.
Method
As you will be modifying the existing Mailing Opportunities.dtsx package, to avoid
any confusion with package names, you will create a new project in which you will
add the Mailing Opportunities.dtsx package with a new name: Mailing Opportunities
with Configurations.dtsx. You will then open the newly added package, Mailing
Opportunities with Configurations.dtsx, and enable package configurations. The
ToLine property of the Mailing Opportunities task determines who will receive the
e-mail message. You will change this property in the package configuration file to
demonstrate how the properties of a package can be modified at run time.

Exercise (Enable and Add Package Configurations)
You will enable configurations using the Package Configurations Organizer utility
provided in BIDS. Then you will add a ToLine configuration in the package.
1. Start BIDS and create a new Integration Services package with the following details:
Name
Contacting Opportunities with Configurations
Location
C:\SSIS\Projects
2. Add an existing package from the File System using C:\SSIS\Projects\Contacting
Opportunities\Mailing Opportunities.dtsx as the Package Path. When the package
is added, rename this package as Mailing Opportunities with Configurations.dtsx.
Then delete the Package.dtsx package.
3. Double-click the Mailing Opportunities with Configurations.dtsx package to
load it. When the package is loaded, right-click anywhere on the blank surface of
the Designer and choose Package Configurations from the context menu. This
will open the Package Configurations Organizer dialog box. You can also open it
by choosing SSIS | Package Configurations.
Chapter 13: Deploying Integration Services Packages 573
4. Select the Enable Package Configurations check box. This setting is package
specific and will not affect any configurations defined in other packages in
a multipackage project.
5. Now you can add configurations in this package. Click Add to start the Package
Configuration Wizard. Click the Next button on the Welcome screen.
6. Leave the XML Configuration File option selected in the Configuration
Type field.
7. Next, choose to specify a configuration directly or indirectly by using an
environmental variable to pass the value. In this exercise, you will use the direct
package configuration. In the Specify Configuration Settings Directly field, type
the filename and path for the XML configuration file as shown in Figure 13-2—
C:\SSIS\Projects\Contacting Opportunities with Configurations\conoppo

.dtsConfig. Note that the package configuration file has a .dtsConfig extension
when saved as an XML file. Click Next.
8. In the Select Properties To Export page, you can select to export the variables,
properties of the package, properties of the connection managers, or properties of
any of the executables or tasks used in the package. Under the Objects pane, expand
the Executables folder in the Mailing Opportunities package. Under the Executables
folder, expand Iterating October Opportunities followed by the Executables
subfolder used in this package. Again under Executables, expand the Mailing
Opportunities subfolder, followed by Properties, and then check in the Subject
Figure 13-2 Specifying configurations directly
574 Hands-On Microsoft SQL Server 2008 Integration Services
and ToLine properties to select them, as shown in Figure 13-3. After selecting
these properties, click Next to move on to the Completing The Wizard window.
9. Type Config_emails in the Configuration name field and review the options
before clicking Finish.
10. When you return to the Package Configurations Organizer dialog box, you will
see the configuration you just added listed there. You can return to this dialog box
later to add more configurations, edit already-defined configurations, or remove
configurations from the package. The configuration we added updates multiple
properties (Subject and ToLine properties). You can add multiple configurations
in the way you’ve added the Config_emails configuration into your packages. The
configurations are applied in the order they appear in this list. The configurations
are applied at loading time, so when multiple configurations update the same
property, the value updated last is used at run time. You can control this order
by using the direction arrow buttons provided on the right side of the dialog box
(shown in Figure 13-4) to move configurations up or down.
11. Pay some attention to the columns that appear under the Configurations
area. The configuration name you defined is shown under Configuration
Name; Configuration Type shows the type of configuration you have chosen;
Configuration String shows the path where the configuration is located. You

can create multiple configurations and group them logically for a package in the
Figure 13-3 Selecting properties to export for creating configurations
Chapter 13: Deploying Integration Services Packages 575
Configuration Name column. In this exercise, we have modified two properties
under one configuration name, Config_emails. Two more columns, Target
Object and Target Property, refer to the name of a target object and that of a
target property, respectively. The use of an XML configuration file renders the
Target Object and Target Property columns blank, as it can update multiple
objects. Click Close to close the dialog box.
Exercise (Assign a Value to the Package
Configurations and Debug)
In this part, you will assign an e-mail address to the Subject and ToLine configurations
and see how they are used by the package during run time to update the values specified
(hard-coded) in the package.
12. So far, you have defined a package configuration for the ToLine property. The
next step is to assign a value to this configuration. Choose File | Open | File to
open a file. In the Open File dialog box, open the conoppo.dtsConfig file by
exploring to the C:\SSIS\Project\Contacting Opportunities with Configurations
folder and clicking Open.
13. When the conoppo.dtsConfig file opens in a new tab, click the Edit | Advanced |
Format Document menu bar command to format the XML layout. Locate
Figure 13-4 Package Configurations Organizer dialog box showing a configuration
576 Hands-On Microsoft SQL Server 2008 Integration Services
the <ConfiguredValue> element for the ToLine property, after the following
configuration:
<Configuration ConfiguredType="Property" Path="\Package\Iterating October
Opportunities\Mailing Opportunities.Properties[ToLine]" ValueType="String">
Type your alternative e-mail address between <ConfiguredValue> and
</ConfiguredValue>. Similarly change the ConfiguredValue of the Subject property
to Your first enquiry (see Figure 13-5). You don’t need BIDS to edit configurations

file, you could have done this using any text editor such as Notepad.
14. Now you’ll test your configurations. Execute the package by pressing the 5
function key to start debugging the package.
15. You will see the tasks turning yellow and then green to indicate the successful
completion of the package. Stop the debugging when all the tasks have
completed.
16. Switch to your e-mail application and check the inbox of the alternative e-mail
address you specified in the configuration file. You will see e-mails from your
package.
Review
You have successfully created a configuration for two of the properties exposed by the
Send Mail Task in your package and have assigned values to the exposed properties.
Upon executing the package, you saw that the values configured in the package were
modified to use the values specified for the configuration. The value can be assigned
to the configuration either directly, as you did in this Hands-On exercise, or by
Figure 13-5 Assigning values to exported properties in package configurations
Chapter 13: Deploying Integration Services Packages 577
directing it to read from an environment variable. In situations when you are sure that
the path used by the configurations will be the same for all deployments, use of direct
configurations offers a simple solution.
Direct and Indirect Configurations
You can specify the package configurations in two ways—direct and indirect.
In direct configuration, you specify the configuration using any of the five configuration
types mentioned earlier. For example, you specify a configuration for a property in an
XML configuration file and then assign a value to that configuration. As you deploy the
package, this configuration gets deployed with the package. You get an opportunity to
specify the configuration file path and modify the configuration value during deployment.
If you decide to deploy the configuration file in such a way that in different
environments you keep the same configuration file path and the value of the variable,
you can hard-code the configuration values. In this type of deployment, Integration

Services reads the configuration file from the path specified during deployment and
links directly the configured property in the package and the value assigned to it in
the configuration. For simple environments—i.e., those in which you can specify
the deployment path and the configuration values during deployment—direct
configurations are a better choice because they offer flexibility of making changes
during deployment.
However, bear in mind that the configurations become part of the package and
are deployed with the package. When your package needs to be deployed to various
environments on many servers, you may encounter different configurations for different
machines and the opportunity of modifying package configurations during deployment
in such situation becomes a hassle. This can cause some management and deployment
issues—for instance, if you have special environment needs for a package, then deploying
such packages to computers with different environments may call for a lot more work at
deployment time and cause some grief.
The solution to this problem lies in using indirect configurations, in which you
create a configuration file for each computer once and then use an environment
variable to access the computer-specific file. This computer-specific file doesn’t flow
with the package during deployment; instead, it lies at the deployment computer all
the time and becomes responsible for creating an environment into which the package
will be deployed. Unlike direct configuration, in this case the package will access this
computer-specific configuration file indirectly using an environment variable to free
you up from specifying the configuration path each time you deploy the package.
For indirect configurations, you create the configuration file and copy it to a folder
on the computer where you want to deploy the package, create an environment variable
that points to this file, and then on the development computer point your package to