What is the purpose of parameterizing connection manager in ssis? - ssis

Question

I have ssis package with 2 connection managers.
When deployed to sql server and when I right click and click execute it allows me to set the connection manager configuration value.
Also in the above popup I can set parameter value.
Similarly I can right click and choose configure to set the parameter and connection manager values.
So what exactly is the purpose of parameterizing connection managers in ssis when I can anyways configure the connection manager via the pop-up?

Answer 1

A Parameter is a read only Variable that a package can receive at run time. An example of a package level parameter would be something like Processing Date. That way I can run yesterday's work and then rerun the package with Today's date.
A Variable can also be set at run-time but the mechanics of doing so are less intuitive. Net result is the same.
A Project Parameter is a read only Variable that all the packages in a project can reference. An example of a project level connection manager would be a file path. At least in my world, I define that as a path like C:\ssisdata\MyProject and then I have Input/Output/Archive folders hanging off that path. When I get to production, or another developer's machine, maybe that value becomes D:\data or \server2\share\MyProject
If each package had defined a Parameter of FilePath, then I would have to modify each package's parameter when it runs to reflect the server environment's value. If I change the value in the project, all of the packages pick up that new value.
That's all just in the execution environment from Visual Studio.
Running packages from the SSISDB
When you deploy to SQL Server's SSISDB catalog, you get some different options.
A simple case as you describe can be envisioned here.
Right click on the package and select Execute. The bold text for FilePath indicates I have changed it for this run of the package. The icon to the left show whether it is a project level parameter (first two) or package level (final one).
Behind the scenes, this generates the following SQL
DECLARE #execution_id bigint;
EXEC SSISDB.catalog.create_execution
#package_name = N'Package.dtsx'
, #execution_id = #execution_id OUTPUT
, #folder_name = N'So'
, #project_name = N'SO_66497856'
, #use32bitruntime = False
, #reference_id = NULL
, #runinscaleout = False;
SELECT
#execution_id;
DECLARE #var0 sql_variant = N'D:\ssisdata\MyProject';
EXEC SSISDB.catalog.set_execution_parameter_value
#execution_id
, #object_type = 20
, #parameter_name = N'FilePath'
, #parameter_value = #var0;
DECLARE #var1 smallint = 1;
EXEC SSISDB.catalog.set_execution_parameter_value
#execution_id
, #object_type = 50
, #parameter_name = N'LOGGING_LEVEL'
, #parameter_value = #var1;
EXEC SSISDB.catalog.start_execution
#execution_id;
GO
Every time I want to run this job and make it work for the environment (D: instead of C:), I would have to click the ellipses, ..., and provide a value.
Someone is going to mess that up so either you script the TSQL as I did and put that into the job definition. But if I run Package2, I would need to do the same run-time level change, set_execution_parameter_value to ensure that package also used the D drive. By the time I get to Package100, I'd say there must be a better way.
If I right click on my Project, SO_66497865, I have an option for Configure...
You can see me changing the value to an entirely different path on the D drive. Behind the scenes SQL is working with set_object_parameter_value
DECLARE #var sql_variant = N'D:\Set\Configure\Value';
EXEC SSISDB.catalog.set_object_parameter_value
#object_type = 20
, #parameter_name = N'FilePath'
, #object_name = N'SO_66497856'
, #folder_name = N'So'
, #project_name = N'SO_66497856'
, #value_type = V
, #parameter_value = #var;
GO
Now when I go to run the same package, look at that
It uses the Configured project parameter value without me having to provide a per run override (no bolded text).
For completeness, the last thing you can do is create an "Environment". An Environment is a set of shared variable values. For example, my Oracle User name and password (marked as sensitive) could be an Environment level thing because any of my 4 projects might want to use that value for configuration purposes. The Environment SOEnvironment is available to any of the projects.
I'm going to wire up MagicNumber from my Environment to my project's OtherProjectParameter.
Once again, right click on a project and choose Configure. Go to the References tab (this is a one time activity) and click Add and then find the Environment.
Now, back to Parameters tab and click the ellipses on OtherProjectParameters. Notice that Use environment variable is now longer greyed out. This shows you allowable environment variables based on data type. Pick MagicNumber
When you click OK, you now have an underscore on the configure screen
At this point, when I go to run the package, it will show me something like this
Pick your environment and that will get the OtherProjectParameter to fill in
That's a whirlwind tour of what your choices are and what/when they matter. How you should configure things is extremely dependent on your parameterization needs.
If you have multiple configurations enabled, then when you go to execute the package - either as a one-off execution or a SQL Agent job, you must pick the environment. Here I have SOEnvironment, SO_67402693_env0, and SO_67402693_env1 as sources for my package and for your deleted question, the latter two environments both provide a value for parameter p which is configuring OtherProjectParameter
When I go to execute the package, it will flag that it cannot start until an environment is picked. Here I select env0 and it results in the following tsql being generated. The #reference_id = 20002 is how that precedence would be determined an in fact, there is no precedence as only one environment reference is allowed at runtime.
DECLARE #execution_id bigint;
EXEC SSISDB.catalog.create_execution
#package_name = N'Package.dtsx'
, #execution_id = #execution_id OUTPUT
, #folder_name = N'So'
, #project_name = N'SO_66497856'
, #use32bitruntime = False
, #reference_id = 20002
, #runinscaleout = False;
SELECT
#execution_id;
DECLARE #var0 smallint = 1;
EXEC SSISDB.catalog.set_execution_parameter_value
#execution_id
, #object_type = 50
, #parameter_name = N'LOGGING_LEVEL'
, #parameter_value = #var0;
EXEC SSISDB.catalog.start_execution
#execution_id;
GO
Similar commands are generated if this is done via SQL Agent instead of right clicking on a package to execute but the same single environment reference allowed will hold true.
what exactly is the purpose of parameterizing connection managers in ssis when I can anyways configure the connection manager via the pop-up?
Backwards compatibility. The pattern for 2005/2008 was to have SSIS connection strings with expressions driven by variables which were then driven by classic Configuration or to just use Configuration to directly inject values to the ConnnectionString attributes. Some people continue to use that approach as is with the Project Deployment Model. Others use Package/Project managers to pass in credentials or a connection string. I favor using the pop-up window to handle configuring connection managers as it's one less moving part to deal with.
An argument for project/package parameters is ftp credentials. The existing FTP task, last I used it, would fail if the expected file wasn't there. My pattern was to write a .NET script to handle FTP activities as I could better handle missing file scenarios. But, I would need to get credential data passed securely to my package and thus, I needed package parameters and I would check the Sensitive box. Were I to have supplied them at run-time, then they would be saved in clear text in the SQL Agent job steps.