Please point out anything I forgot to add or got wrong.
I'm working with SSIS in SQL Server 2012 and I am attempting to write to a parent package variable from a child package. The hitch here is that the child package is not in the same project as the parent package.
From what I've read, the new project model requires an execute package task to target packages stored in the same project. If I'm using an external reference, the task is unable to target packages stored in projects in SSISDB and can only reference MSDB or the file system.
Inside the child package I have a single script task that contacts a web service and invokes several methods and contains logic around the invocations. It also accesses several parent variables, some to read through parameters, some to write by directly referencing them. Ideally this script task would be centralized so that if the logic needs to change, I only need change the centralized package, and the cost to link a new package with the child package should be minimal, which is why I liked the idea of using an execute package task and a child package in the first place. These are the options that I see right now:
1) I realize I could just have the child package in every single project that gets created, but this will most likely lead to maintenence problems down the road.
2) I could call a stored procedure in SSISDB to kick-off the child package but I do not believe the child package will have access to the parent package's variables, as, from what I can tell, it would be initiating the package with no ties to the parent's execution ID.
3) I could also store the package in the file system, but I have doubts about the acceptance of using the file system by my administrators.
4) I could compile a .dll with the code from the script task in the child package. The problem is, I don't know how the new model treats referenced .dll's.
Can anyone provide advice on how I should proceed?