In order to start SSIS packages from ASP.NET web applications you can use a Web Service.
Following page shows how to implement this: Running packages programmatically on the server by using a Web service or remote component.
What you should know about running SSIS packages from ASP.NET is that there is a problem with the threads SSIS processes use.
Even Impersonation does not work successfully. The impersonation applies to the calling thread only, but SSIS creates additional threads in order to be able to perform multiple steps simultanously. Unfortunately, the impersonation context is not passed to these additional threads, so any data base access occurs under process user context, not under impersonated context.
So it is better to execute SSIS package outside of ASP.NET process, e.g. using DTEXEC or Agent Job (Agent proxies are convinient if you want to execute under specific credentials).
Important:
With its default settings for authentication and authorization, a Web service generally does not have sufficient permissions to access SQL Server or the file system to load and execute packages. You may have to assign appropriate permissions to the Web service by configuring its authentication and authorization settings in the web.config file and assigning database and file system permissions as appropriate.
Solution:
IIS 5.0: only solution seems to be assigning Administrator rights to the ASP.NET User
IIS 6.0: create new Application Pool with Administrator user context and set the Web Service
using this context in order to initiate SSIS packages
Here is an example Application Configuration for a SSIS & ASP.NET project:
Image may be NSFW.
Clik here to view.
Following error messages can show that you’re running into the problem with the SSIS threads:
– package validation failed
– TaskHost validation failed
– cannot access file location
– component xyz validation failed
