You are on page 1of 24

Deploying and Configuring SQL Server Integration

Services Packages Without the Wizard


October 2, 2008
By Dee Quang
Bio
Send Email
More Articles
A deployment wizard is provided by Visual Studio's Business Intelligence Development Studio (BIDS) to
deploy and configure SQL Server Integration Services (SSIS) packages. However, deploying a package
with the wizard can be cumbersome and is also a little confusing if you are unfamiliar with the tool. It is
not always the most intuitive method to deploy and configure a package.
I will demonstrate deploying and configuring a SSIS package without the deployment wizard provided by
BIDS. I will show you how to deploy and configure SSIS packages all intuitively. Please note that this
article is not meant to derail developers from using the wizard. It is just a different method to accomplish
the same task.
Application and technology wise, this article only pertains to the following software and versions. All other
versions may have slight modifications to the instructions:
Microsoft SQL Server 2005
Microsoft Visual Studio 2005 v8.0.50727.42
Microsoft SQL Server 2005 Management Studio v9.00.3042.00
Microsoft SQL Server 2005 Integration Services v9.00.3042.00
Loading
Deploying a SSIS package requires either the SQL Server Job Agent to locate and execute the package
or execute the package directly from SQL Server's file system. For optimal performance, the package
should be stored on the same system as the deployment server's SQL Server 2005 Management Studio;
whether that is the file system itself, SQL Server's file system, or SQL Server's MSDB, it really doesn't
matter. It is the same deployment procedure for all three locations with the exception of where to select
the package for deployment. For the sake of time, this article will only demonstrate deploying the package
by storing it in SQL Server's file system.
Locating, Migrating, and Importing
When initially creating the project, BIDS allowed the developer to select the home directory of the project.
Locate the home directory of your project and find all the packages (.dtsx files) in a subfolder directly
under the home directory. The subfolder's name should be the exact name as the home directory. Figure
1 displays the structure of the project for the examples of this article.


Click here for a larger image.
Figure 1: Package Directory
The home directory of the demo is C:\Deployment_Demo. Within the subfolder
C:\Deployment_Demo\Deployment_Demo there are two packages to deploy, called
Deployment_Package_Demo_1.dtsx and Deployment_Package_Demo_2.dtsx. As mentioned earlier,
deploying these packages at optimal performance requires the package to reside on the deployment
server. Copy and migrate all the packages to the server.
Because all the packages should have migrated to the server, the next few steps should all be performed
on the server. Import the packages to SQL Server's file system by first connecting to server type
Integration Services from the Microsoft SQL Server 2005 Management Studio (SSMS) application. The
Integration Services server type does not allow for SQL Server Authentication; only Windows
Authentication is allowed. Set the server name to be LocalHost and click Connect. Figure 2 shows the
login screen for the Integration Services server type.

Figure 2 Integration Services Login
Once connected, SSMS should display the object explorer with the Integration Services directory
structure seen in Figure 3.

Figure 3: Integration Services Object Explorer
Create a new folder under LocalHost\Stored Packages\File System to separate the projects and import
the packages by right-clicking on the newly created folder. Choose Import Package...when the right-click
menu pops up. This should bring up the Import Package screen, as shown in Figure 4.


Click here for a larger image.
Figure 4: Package Import
Select File System as the package location and browse for the package's location. Once the package is
selected, click on the package name input box and a suggested name will appear. The name that
appears is simply the name of the package. Feel free to change it by overwriting the value in the box.
When done, click OK to complete the import. Figure 5 displays how the directory should look like after the
packages are successfully imported into SQL Server's file system. (If you were to use the BIDS
deployment wizard, this is as far as it will take you. Therefore, you have essentially performed all the
steps that were to be performed by the deployment wizard!)

Figure 5: SQL Server File System
Execution
After all packages are imported, there are two methods to execute the package. Packages can execute
by scheduling the package with the SQL Server Job Agent (SSJA) or on an ad-hoc basis by choosing to
run it from SQL Server's file system. All packages can be configured in their respective methods of
executing. However, configurations will not be explained until the Configuring Packages section. The
packages will currently run off the default package configurations.
SQL Server Job Agent
Packages that need to be processed in a timely manner can be scheduled by the SQL Server Job Agent.
To use SSJA, the services need to be enabled. Navigate to the Services folder by going to
StartSettingsControl PanelAdministrative ToolsServicesand locate SQL Server Agent
(MSSQLSERVER). Make sure that the service is enabled. If not, right-click on SQL Server Agent and
choose properties. Under the General tab of the Properties window, select Automatic for the startup type
and click on the Start button. Figure 6 below displays the Properties window.

Figure 6: SQL Server Agent Properties
After Start is pressed, the SQL Server Agent should now be started. Click OK to close the window and
get out of the Services folder.
Job Creation & Execution
Scheduling a package requires that a SQL Server job be created for the package. Load the Database
Engine server type and connect using the LocalHost server name with Windows Authentication. After
connection, navigate to the bottom of the LocalHost directory and expand the SQL Server Agent folder.
Right-click on the Jobs folder and choose New Job... to display the New Job window. as seen in Figure
7.


Click here for a larger image.
Figure 7: SQL Server Job Creation
Give the job a name and navigate to the Steps tab on the left side to create a step process. Click on


Click here for a larger image.
Figure 8: SSIS Step Creation
Give the step a name and select SQL Server Integration Services Package as the type. Ensure that the
value of Run as is SQL Agent Service Account. Now, navigate to the General tab located below the drop
downs and select SSIS Package Store as the package source. Input LocalHost as the server and browse
for the package in the file system. Select a package and the window should now resemble Figure 8. Click
OK to close the window.
Now that the step is created, the package needs to be scheduled. Navigate to the Schedules tab on the
left side of the New Job window and click on the New... button to display the New Job Schedule
window. As seen in Figure 9, the New Job Schedule window is pretty self explanatory. Set the desired
schedule and click OK to exit the scheduler.


Click here for a larger image.
Click OK again on the New Job window to create the job. The job should now be created and resemble
Figure 10.

Figure 10: Directory after Job Creation
At the scheduled time, the job will process and complete. If the job completes without any errors, give
yourself a pat on the back because you have successfully deployed an SSIS package via SSJA.
Ad-Hoc Execution
Whether packages are executed on a scheduled basis or not, packages can always be executed ad-hoc.
Executing a package on an ad-hoc basis can be done in two methods. The first method is directly from
the package in SQL Server's file system (SSFS). Find the package in SSFS and choose Run Package
from the right-click menu to display the Execute Package Utility window. Click on the Execute button
and the ad-hoc execution is complete. Figure 11 displays the Execute Package Utility window.


Click here for a larger image.
Figure 11: Execute Package Utility
The second method is by executing it through the job created for the package. Simply right-click on the
job and choose Start Job. That is all that is needed to execute the packages ad-hoc.
Configuring Packages
Packages can be configured in a multitude of ways. They also can be configured individually or globally.
This article so far has only used the default package configuration to individually configure and execute
the package. In addition to the default package configuration method, this section will describe two other
methods to configure the package.
Default Package Configuration
The default package configuration method uses the package's connection manager's OLE DB connection
transformation to configure the server credentials. This method is used to configure the packages
individually. As seen in Figure 12, the server name and server credential can be entered in the
Connection Manager window.

Figure 12: Connection Manager Window
When a package is schedule by the SQL Server Job Agent or executed ad-hoc and configurations are not
specified, the default package configuration will be used.

Step & Execute Package Utility Configuration
After packages are loaded into SQL Server's file system (SSFS), reconfiguring the packages can be a
hassle when using the default package configuration. However, there are alternative methods to
configure the packages either individually or globally after the packages are loaded into SSFS.
Configuring the packages individually can be done by using the Step and Execute Package Utility
Configuration window. In the Step windows of a SQL Server job, navigate to the Data Sources tab to
see all the data sources of the package's Connection Manager. Clicking on the check box as seen in
Figure 13 will allow the user to edit the connection string.


Click here for a larger image.

Within a connection string, there are many variables representing a login credential. The following table
describes the important variables of the connection string.
Variable Description
Data Source/Server Name Simply the name of the server
Initial Catalog The database of the server
Table 1: Connection String Important Variables
Simply changing the value of the Data Source or Initial Catalog will be like changing the data source
connection on the default package configuration screen within a package. The rest of the connection
string represents the authentication mode that unfortunately will not be explained in this article.
Configuring the packages individually by using the Execute Package Utility window is very similar to
configuring the package by using the Step window. In the Execute Package Utility window, navigate to
the Connections Manager tab and check the appropriate boxes to make the data connection changes.
As seen in Figure 14, the options are very similar to Figure 12.


Click here for a larger image.
Figure 14: Execute Package Utility Connection Manager
Packages also can be configured globally by the use of configuration files. The notion of global
configuration means that once a single change takes place in the configuration file, all packages that are
pointing to that configuration file for the data source connection will be affected. Configuration files are
created by choosing the Package Configurations... option from the right-click menu within the package's
control flow. Unfortunately, this article will not get into the details of creating a configuration file.
Configuration files can encompass the entire package and can get very complex. This article will only
cover the aspect of the configuration file that is necessary to make a change to the data connection.
Figure 15 represents the important variables of a data source connection in XML format.


Click here for a larger image.
Figure 15: XML Configuration File
There are three variables in the configuration file. The three variables are the Connection String, Server
Name, and Initial Catalog. Changing the Server Name and Data Source parameters within the
Connection String will change the server package refers to, and changing the Initial Catalog will refer to
the database that the package should refer to. Changing these values has the same exact effect of
changing the values directly in the Step or Execute Package Utility window. The only exception is that
only a single change is needed to affect all packages that are referring to the configuration file.
All references to a configuration file can be done in the Step and Execute Package Utility windows.
Select a configuration file under the Configurations tab of the respective window and it is complete.
Please note that if a configuration file is selected, it will override all other configurations done individually
to the package.
Conclusion
Although a deployment wizard is provided by the Business Intelligence Development Studio, there are
other methods to deploy the SQL Server Integration Services package more intuitively as described in
this article. Packages can be loaded, configured, and processed without a single use of the deployment
wizard. In addition, the deployment wizard only takes the user as far as loading the packages into SQL
Server. It is really not a "deployment wizard" per se because it does not take you through the entire
process of processing the packages. However, as mentioned earlier, this article is not meant to derail
users from using the wizard. The deployment wizard provides the greatest value when trying to update
packages after they have been loaded into SQL Server's file system. It removes the hassle of having to
re-import the updated packages into SSFS because the wizard will complete the task for you. Hopefully,
this article has helped those who are new to SSIS deployment understand the entire process better.
How to Configure an SSIS Package to Access a Web Service using WCF
dbrowne
8 Jul 2010 10:47 AM
Comments 0
When you are connecting to a web service from an SSIS Script component or transform using a WCF client, the
normal method of configuring the WCF client from the application configuration file doesnt work well. Your package
will be running in some host, like dtexec.exe, and you would have to put your client config its application
configuration file. SSIS packages have their own way of consuming configuration, by either setting package variables
(or other settings) from the command line, or using an external package configuration (stored in a SQL Server table or
XML file). To use the normal SSIS configuration mechanisms to configure a WCF client, the easiest way is to configure
your WCF client in code, and plug in package variables for things like the service URL, or perhaps the client credentials
or proxy settings.
Heres a quick walkthrough of calling a Web Servcie from a WCF client in an SSIS package, configuring the WCF client
in code and using a package variable for the web service URL.
First create a WCF Service for testing (or use some existing web service):

then hit F5 to run the service in the development server, and note the URL of the .svc file:

Create a new SSIS package and add a DataFlow and a Script Component configured to Source. Add output columns
to the script source to match the data flowing out of the web service. Here its just a single integer.

Edit the script for the script source and change the target .NET Framework from 2.0 to 3.5 so you can use WCF:

In the Script project add a Service reference:

Enter the URL of your web service, and give it a friendly name:

Create a Package variable to configure the service URL, and give the script source read-only access to the variable.

Now edit the script to configure the WCF client in code and pass in the package variable for the URL.
/* Microsoft SQL Server Integration Services Script Component
* Write scripts using Microsoft Visual C# 2008.
* ScriptMain is the entry point class of the script.*/

using System;
using System.Data;
using Microsoft.SqlServer.Dts.Pipeline.Wrapper;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;
using System.ServiceModel;
using SC_e9f00fa5cbb748d4b5b80e10f6c61d98.csproj.MyService;


[Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute]
public class ScriptMain : UserComponent
{

ChannelFactory<IService1> channelFactory;
IService1 client;
public override void PreExecute()
{
base.PreExecute();

//create the binding
var binding = new WSHttpBinding();
//configure the binding
binding.Security.Mode = SecurityMode.Message;
binding.Security.Transport.ClientCredentialType =
HttpClientCredentialType.Windows;

var endpointAddress = new EndpointAddress(this.Variables.ServiceUrl);
channelFactory = new ChannelFactory<IService1>(binding,
endpointAddress);

//create the channel
client = channelFactory.CreateChannel();
}

public override void PostExecute()
{
base.PostExecute();

//close the channel
IClientChannel channel = (IClientChannel)client;
channel.Close();

//close the ChannelFactory
channelFactory.Close();

}

public override void CreateNewOutputRows()
{

for (int i = 0; i < 10; i++)
{
this.Output0Buffer.AddRow();
CompositeType t = new CompositeType();
t.BoolValue = false;
t.StringValue = i.ToString();

var data = client.GetDataUsingDataContract(t);
this.Output0Buffer.id = data.BoolValue?1:0;
}

}

}
If youre not sure what binding to use look at the app.config that the Add Service Reference wizard put in your script
project. It will tell you. Here it requires wsHttpBinding with Message transport security and a Windows credential:

Add a simple data flow destination and test your package:

Then you can set the value of the package variable on the command line with dtexec.exe or SQL Agent, or create a
package configuration that has sets them.

You might also like