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

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 inst

Till 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:

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

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

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

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

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

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

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

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

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 f5

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

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