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 . 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. 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. 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