从 ASP.NET 远程执行 SSIS 时记录信息
我有一个 Web 服务器(未安装集成服务)和一个单独的 SQL 服务器。我创建了一个 ASP 页,通过在包所在的 SQL 服务器上启动代理作业来远程执行 SSIS 包。该包读取网页用户选择的 Excel 文件,处理数据并将结果存储在数据库中。
我的问题是:在运行时从 SSIS 传回 ASP 页面记录数据的好方法是什么,以便用户获得有关其请求结果的一些合理信息?
I have a web server (no Integration Services installed) and a seperate SQL server. I have created an ASP page to remotely execute a SSIS package by firing up an Agent job on the SQL server where the package lives. The package reads an excell file,chosen by the web page user, process the data and stores the results in the database.
My question is: what would be a good approach to pass back to the ASP page logging data from the SSIS during runtime, so the user has some sensible information about the outcome of his request?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
作为第一步,我建议打开本机 SSIS 日志记录并将其转储到 SQL Server 目标。这是一个 8 次点击的过程,所以没有理由不启用它。当然,可以获取 OnTaskFailed、OnError,也可能是 OnInformation 和 OnWarning,具体取决于您想要返回给用户的信息类型。
完成后,当包运行时,如果您选择的数据库中尚不存在表,SSIS 会足够智能地在以下位置创建 msdb.dbo.sysdtslog90 / msdb.dbo.sysssislog (2005 / 2008+) 的副本:该数据库并开始记录到它。
此时,您的作业已经运行,执行历史记录会自动转储到该日志表中,您可以提取该信息。当作业运行时,会生成一个新的 GUID,并且您可以通过该 ExecutionId 将特定运行的所有活动绑定在一起。
我不确定您如何将有关要处理哪个 Excel 文件的信息传递给作业,也许您不允许并发执行,并且一次只能运行一个文件。如果是这种情况,那么您始终可以在日志中查询最近的执行,并假设它与站点上的用户相关。
否则,我可能会考虑执行类似在日志中发出唯一文件名的操作 [Script task, ~ Dts.Events.FireInformation(String.Format("FileName:{0}", Dts.Variables[MyExcelCM].Name. ToString()),...);] 然后执行一些巫术来解析日志,假设您不能只创建一个文件名来执行 id 运行表,那将是更干净的绑定方法运行到特定文件,这将允许您链接回 syssisslog。
编辑
在包中,将“执行 SQL 任务”拖到控制流上,并将连接管理器指向具有上表的数据库。你的查询看起来像
INSERT INTO dbo.ExecutionToFileMapping (executionid, file_name) SELECT ?, ?
在“参数映射”选项卡上,连接与 Excel 文件名对应的局部变量,然后使用系统变量 ExecutionInstanceGUID。当该语句触发时,它将使用执行 GUID 和文件名在表中创建一个条目。
然后您可以将日志记录结果链接到特定文件
end edit
最后,正如我所言喜欢 SSIS,使用 Excel 作为数据源会带来很大的挫败感,尤其是在涉及用户生成的电子表格时。我无法计算“电子表格看起来相同”的实例数量,但 SSIS 却表示格式不同。我通过 OLEDB 查询 Excel 获得了更好更好的体验,就像这个问题讨论在 C# 中查询 excel 表 根据您的 SQL Server 版本,我然后利用 2008+ 中的表值参数,基本上将内容直接转储到表中。
As a first cut, I'd suggest turning on the native SSIS logging and dumping that to SQL Server destination. It's about an 8 click process so really no reason not to enable it. Grab OnTaskFailed, OnError for sure, maybe OnInformation and OnWarning, depending on what sort of information you'd like to return to the user.
Once that's done, when the package runs if a table does not already exist in the database the you selected, SSIS is smart enough to make a copy of the msdb.dbo.sysdtslog90 / msdb.dbo.sysssislog (2005 / 2008+) in that database and begin logging to it.
At this point, your job has run, the execution history is automagically dumped to that log table and you can pull that information out. When the job runs, a new GUID is generated and that ExecutionId is how you can tie all the activities of a particular run together.
I'm not sure how you are passing the information to the job about which Excel file to process, perhaps you don't allow for concurrent execution and only one file will ever be run at a time. If that's the case, then you can always query for the most recent execution in the log and assume it ties to the user on the site.
Otherwise, I'd probably look at doing something like emitting the unique filename in the log [Script task, ~ Dts.Events.FireInformation(String.Format("FileName:{0}", Dts.Variables[MyExcelCM].Name.ToString()),...);] and then do some voodoo to parse the log, assuming you can't just create a filename to execution id run table, that'd be the cleaner means of tying a run to a particular file which would allow you to link back to the syssisslog.
Edit
Within the package, drag an Execute SQL Task on the control flow and point your connection manager to the database with the above table. Your query would look like
INSERT INTO dbo.ExecutionToFileMapping (executionid, file_name) SELECT ?, ?
On the Parameter Mapping tab, wire up the local variable that corresponds to the Excel filename and then use the system variable ExecutionInstanceGUID. When that statement fires, it will make an entry into the table with the execution GUID and the file name.
You can then link the logging results to a particular file(s)
end edit
Finally, as much as I enjoy SSIS, using Excel as a data source is a recipe for great frustration especially when user generated spreadsheets are involved. I can't count the number of instances of "the spreadsheets look the same" yet SSIS went tits up indicating the format was different. I have had a much better experience just querying Excel via OLEDB like this SO question discusses Query excel sheet in c# Depending on your SQL Server version, I'd then took advantage of table valued parameters in 2008+ and basically dumped things straight into tables.