我们是否应该将 SharePoint WF 主机用于包含外部（SharePoint）数据源的工作流？
我们需要构建几个需要相当高级的工作流程功能的应用程序。 计划将数据存储在 SQL Server 中，使用 Windows Workflow Foundation 作为工作流引擎，并使用 RIA 技术（例如 Flex 或 Silverlight）构建前端。
我们已经设置了 Sharepoint 2007，并且我们中的一些人（包括我）在创建处理 Sharepoint 列表中的数据的自定义 Sharepoint 工作流方面拥有一些经验。
我的问题是，在工作流程中使用 Sharepoint 是否有意义，而实际数据存储在 Sharepoint 外部的单独数据库中？ 我们需要 Sharepoint 的任务、身份验证和电子邮件功能，但我们的数据模型有点复杂，因此我们不想将数据存储在 Sharepoint 中。 我们宁愿不从头开始使用 Workflow Foundation，因为 Sharepoint 已经为我们提供了 90% 的所需功能。
有什么想法/建议吗？
We need to build a couple applications that require fairly advanced workflow functionality. The plan is to store the data in SQL Server, use Windows Workflow Foundation as the workflow engine, and build the frontend using an RIA technology such as Flex or Silverlight.
We already have Sharepoint 2007 set up, and some of us (including me) have a little bit of experience creating custom Sharepoint workflows that work with data in Sharepoint lists.
My question is, would it make sense to use Sharepoint for the workflow, while the actual data is stored outside of Sharepoint in a separate database? We need the task, authentication, and email functionality of Sharepoint, but our data model is a bit complex so we'd rather not store the data in Sharepoint. We'd rather not start from scratch with Workflow Foundation, because Sharepoint already gives us 90% of the functionality we need.
Any thoughts / advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为这是使用 SharePoint 作为平台的一个很好的例子。 我没有看到以您描述的方式使用它有任何概念问题。 我将 SharePoint 视为一个开发平台。 您可能需要记住的一件事是，如果您想让工作流程继续处理单独数据库中发生的事件，您可能必须从外部程序更新工作流程任务项等。
I think that this is a great example for use of SharePoint as a platform. I dont see any conceptual problems using it in the way that you describe. I see SharePoint as a development platform. One thing you might want to keep in mind, is if you want to make the workflow continiue on events happening in the seperate database, you might have to update for instance the workflow tasks item from an external program.
您的用例非常适合，并且 SharePoint 为其增添了巨大的价值。 我强烈建议使用 SharePoint 来托管您的工作流程。
我开发了许多 SharePoint 托管的 WF 工作流程，我遇到的唯一实际问题是调用长时间运行的 Web 服务（异步操作），因为 SharePoint WF 主机对其可以侦听事件的外部提供程序的类型有一些限制。
我开发的解决方案（一开始有点破解，但最终对我的客户有一定价值）是创建一个位于 SharePoint 外部的服务代理 (WCF)，并将调用路由到远程服务并等待他们的回应。 在进行异步调用的同时，并行活动将创建与异步操作关联的 SharePoint 任务。 然后，WF 将停止在 OnTaskCompleted 活动上，这会导致 WF 资源被释放，并且状态将保留到 SQL。 由于长时间运行的操作会返回状态更新或完成通知，外部服务将更新相关的 SharePoint 任务。 一旦任务被标记为完成，WF 就会脱水并继续执行。 这种方法的巧妙之处在于，我可以创建一个仪表板，显示在 SharePoint 外部进行的所有长时间运行的流程的状态。 最后，我将所有这些东西打包成一个复合活动，这样它就不会弄乱我漂亮的工作流程图。
Your use case is a perfect fit and one that SharePoint adds great value to. I would highly recommend using SharePoint to host your workflows.
I have developed many SharePoint hosted WF workflows and the only real problem that I ever experienced was making calls to long running web services (asynchronous operations) as SharePoints WF host has some limitations on the type of external providers it can listen for events from.
The solution that I developed (which was a bit of a hack at first but ended up being of some value to my customers) was to create a service proxy (WCF) that sat outside of SharePoint and would route calls to remote services and wait for their response. In parallel to making that asynchronous call a parallel activity would create a SharePoint task associated with the asynchronous operation. Then the WF would stop on a OnTaskCompleted activity which causes the WF resources to be released and the state to be persisted to SQL. As the long running operation would event back status updates or completion notification the external service would update the related SharePoint task. Once the task is marked completed the WF is dehydrated and continues executing. The neat thing about this approach was that I could then create a dashboard that showed the status of all the long running processes going on outside of SharePoint. Lastly I packaged all of this stuff up into a composite activity so that it didn't clutter up my pretty workflow diagrams.
SharePoint 非常适合这种场景。 我建议使用业务数据目录 (BDC) 来访问外部数据源。 它提供了巨大的好处，主要是通过使数据源可搜索以及提供 OOB Web 部件来显示具有主子关系、过滤和丰富 API 的数据。
我会警告不要让工作流程过于复杂，而是使用较小的工作流程、InfoPath 和用户操作将流程分解为多个阶段，以促进整个流程。 这就是 SharePoint 的真正亮点，因为您可以使用仪表板（如果对您的方案有意义）向组织中的其他人注入流程阶段的可见性以及协作、批准……这样的例子不胜枚举。
SharePoint is ideally suited for this scenarion. I would suggest using a Business Data Catalog (BDC) to access external data sources. It provides a tremendouse benefit primarily by making your datasource searchable as well as providing OOB web parts to display the data with master child relation ships, filtering and a rich API.
I would caution against making workflows too complex and instead break up the process into stages using smaller workflows, InfoPath and user actions to facilitate the entire process. this is where SharePoint really shines as you can interject visibility of the process stages to others in the organization using dashboards (if it makes sense for your scenario) as well as collaboration, approvals ... the list goes on.
我同意 SP 可以提供一个很好的 WF 引擎，但是让我问一下...您是否在 SharePoint 中存储任何内容？ （任务、数据源等）
我问这个问题是因为运行您自己的 WF 引擎可能很容易（而且更合适）。 如果您正在运行所有本机 WF 功能，并且只需要一个引擎，则可以编写一个可以启动工作流程的快速控制台应用程序。
如果您将 SP 用于 WF 之外的任何，那么我绝对同意使用 SP。
I agree that SP can provide a nice WF engine, but let me ask this... are you storing anything IN SharePoint? (tasks, data sources, etc)
I ask because it may be as easy (and more appropriate) to run your own WF engine. If you are running all native WF functionality, and just need an engine, you can write a quick console app that can start workflows.
If you are using SP for anything beyond WF, then I absolutely agree to use SP.