SSIS包执行异常：网页触发SQL作业时跳过Kingsway Soft任务求助

我来分享几个针对这个问题的排查和解决思路，结合SSIS、SQL Agent作业和KingswaySoft插件的常见坑点：

• 检查执行上下文的权限细节
  虽然你已经排查过权限，但要区分SSMS触发和网页触发的执行账户差异：SSMS用的是你的登录账户，网页触发用的是应用池账户。需要确认：

  • KingswaySoft插件所需的CRM权限是否完全覆盖，比如特定实体的写入权限、OAuth认证的权限（如果用现代认证）。可以尝试用应用池账户在服务器上手动运行dtexec /f "你的SSIS包路径"，看是否能复现问题，或者直接看到组件的报错信息。
  • SQL Agent作业的步骤是否配置了代理账户？如果SSMS触发时用的是默认代理，而网页触发时作业使用的是应用池对应的代理，要确认代理账户的权限完全满足KingswaySoft的运行要求。

• 深挖SSIS包的执行日志与约束逻辑

  • 开启SSIS的详细日志记录，在包的日志配置里勾选「Diagnostic」级别，或者查看SSISDB中的执行日志（如果是项目部署模式），重点看那两个被跳过的任务：是组件根本没被触发，还是执行后没生效？
  • 检查任务的优先约束设置：是否前序任务在网页触发时返回了不同的执行结果（比如“成功但无数据”），而约束条件设置为只有“成功且有数据”才触发推送任务？这种情况下很容易出现任务被跳过的假象。

• 排查KingswaySoft插件的运行环境依赖
  KingswaySoft组件对运行环境有特定要求，网页触发的上下文可能缺少这些依赖：

  • 确认应用池的.NET Framework版本是否和SSIS包设计时使用的版本一致，KingswaySoft部分组件对.NET版本有严格要求。
  • 检查CRM连接管理器的配置：是否使用了「当前用户」认证模式？网页触发时的应用池账户没有交互式会话，可能无法完成CRM的身份验证，导致组件静默失败但未标记为任务失败，最终被跳过。建议改为使用服务账户或指定凭据的认证方式。

• 检查SQL作业的执行记录与触发逻辑

  • 确认网页调用EXEC MSDB.DBO.SP_START_JOB '{0}'时是否传递了正确的作业名称，以及作业是否包含完整的步骤流程——有时候作业可能有多个步骤，而触发时只启动了部分步骤。
  • 查看SQL Agent的作业历史详细日志：即使作业显示“成功”，步骤里可能隐藏着警告或错误信息。检查那两个跳过的任务是否有执行记录，是否有未被捕获的异常。

• 模拟网页触发环境进行测试
  用应用池账户登录到服务器，手动运行SSIS包（比如通过SSDT或dtexec命令），如果能复现问题，就可以在本地调试KingswaySoft组件的执行过程；如果不能复现，那可能是网页触发时的上下文有其他限制，比如环境变量差异、服务器到CRM的网络访问权限（应用池账户是否能通过防火墙访问CRM实例？）

内容的提问来源于stack exchange，提问作者Murali Ramakrishnan