SSIS variable that is pragmatically modified

Question

This is an addendum to this question that was asked earlier without an answer.

The problem I have is the need to periodically update a set of 35 single parent parent SSIS packages. They are all the same, differing only in what data they process. When I make the changes, I delete all the children and paste them again into the same folder, updating the value of the variable telling the package which child package it knows what data to process (has a value of 1-35),

My goal was to find a solution that allows the packages to somehow know who they are (by file name, variable, configuration, etc.) so that it reduces maintenance and production settings after the upgrade.

The package file names contain the added numerical value after insertion (packagename 1, packagename 2, .... packagename X) in the same folder. I use package deployment in SSIS 2012, so I do not have access to the file name as a parameter, as if I were using project deployment. All packages are in the SSDT solution with the parent package, in which all 35 children are involved. When deploying packages, I use the configurations in the SQL table to change the file path as it moves from server to server.

I would like to automate other things related to children, but I cannot, unless I first resolve this part. In addition, I need to add another 15 children or so, and this will save a lot of time.

Any help is appreciated

Answer 1

Have you tried using environment variables? And run the packages with different parameters. Packages_with_Parameter_from_Environments

(Sorry, I can’t comment.)

Answer 2

upgrade a set of 35 single parent parent SSIS packages. They are all the same, differing only in what data they process.

It seems you should not use 35 different copies of the same package as the child, and instead just use the options to fix the problem.

If the way they are processed is in the file name, you can use the mask file name parameter to pull the variables, using for each cycle, pass these parameters to the called package. If not, you can save the processing parameters in the sql table, load those that have the name and parameters of the file, and contain all your information and provide this information to the parent package and use it to call the child packages.