问题标签 [sqlworkflowpersistencese]

我正在使用默认的 Sql Workflow Persistence Service 来管理我正在开发的应用程序中的工作流持久性。我使用 Microsoft 提供的脚本在 SQL 数据库中生成架构和逻辑。到目前为止，它工作得很好。但是，我想更改表和存储过程的名称以符合我选择的命名约定。

例如，Microsoft 提供的脚本生成了一个名为的存储过程RetrieveNonblockingInstanceStateIds，我想将其名称更改为wf_RetrieveNonblockingInstanceStateIds.

在即将发布的 Visual Studio 2010 之前，我正在使用 Visual Studio 2010 Beta 2 来学习使用 Workflow Foundation (WF) 4.0 版。我注意到的一件事是，如果我在 SQL 数据库持久性存储中保留一个工作流，然后稍后将其加载回应用程序并完成工作流，当工作流的最后一个活动完成时，记录将从持久存储中删除。我需要确定这个功能是否是为了防止数据库变得庞大而设计的，或者我做错了什么。

我有提交网页，提交后我将数据发送到工作流以将其保存到数据库中，这还将工作流创建的实例存储在工作流数据库中。我的期望是在 DB 中有实例作为 IDLE。每当我需要时，我都可以重新加载实例。但目前它在工作流数据库的实例表中创建记录，executionstatus = closed 和 iscompleted = 1。请让我知道如何将其设置为 IDLE（或相关状态）

我正在尝试使用 web.config 复制以下功能，因为我使用的是网络服务器托管的 .xamlx 服务

我已经从能够收集的搜索结果中尝试了以下内容，但并不满意。

任何帮助将不胜感激。

这是我更新的 web.config

这一切都编译并运行，但自定义持久性对象永远不会被调用。

我正在尝试创建托管在 IIS 中的 Windows Workflow 4 服务。我已将服务配置如下

服务不坚持！服务中没有什么神奇的东西，比如自定义值的持久化等。我已经让它在另一个具有自定义持久化方法的服务中工作，但我无法弄清楚其中的区别。

也许我的服务出错了，但我似乎也不知道如何进行调试。

任何帮助将不胜感激！

背景：

我们目前使用 WF 4 和 SQL Workflow Instance Store 将我们的工作流保存在每个书签中。第一次持久化工作流时，会在“System.Activities.DurableInstancing.InstancesTable”表中创建一条新记录。在每次后续持久化时，都会删除现有记录并插入新记录。

问题：

您如何修改此行为，以便在每次后续持久化时，都会在实例表中创建一条新记录？

笔记：

您可以创建自定义实例存储，但这样做是“不平凡的”。有没有办法可以使用 System.Activities.DurableInstancing.SqlWorkflowInstanceStore 类，但自定义此行为？

我已经使用这个 http://msdn.microsoft.com/en-us/magazine/ff646977.aspx创建了一个应用程序

我需要做的是 callWorkflow 实例动态存储，即之前

我应该能够指定 sqlworkflowinstancestore 即工作流数据所在的位置

任何帮助将不胜感激。

我有一个作为工作流服务工作的状态机，将接收/发送回复活动作为转换的触发器。

在发回回复之前，我必须做一些工作。当发送回复之前的过程中发生异常时，就会出现问题。在这种情况下，如果我不处理异常，整个工作流程就会暂停；无论如何，如果请求没有得到正确处理，我不应该进入下一个状态。

用Try/catch包装整个状态机就足够了吗？状态机会从上次持久化的状态中恢复吗（我使用的是 Sql 持久化）？还有其他解决方案吗？

备注：工作流托管在 IIS 中。

谢谢

我们有一个使用“WWF”作为其工作流引擎的系统，并且继续进行工作流的请求经常失败，并且日志中充满了这个异常。

System.Runtime.DurableInstancing.InstancePersistenceException：数据库中不存在 SqlWorkflowInstanceStore 锁。发生这种情况的原因可能是 SQL Server 正忙或连接暂时丢失。

并在此触发，event (application.Aborted = (e) =>{})有关如何解决此问题的任何想法？

这是我加载工作流程并释放锁的方式

我有一组自定义活动，用于复杂的工作流程。

我想让它们（自定义活动）持久化，而无需让工作流处于空闲状态。它应该是一种故障转移系统，因此每当工作流执行期间出现问题时，它可能是：

• 由用户暂停（随时）并稍后从暂停的书签/点恢复（例如，用户注意到外部系统已关闭，他想暂时暂停工作流程）。
• 如果出现未处理的异常，我们可以从最后一个书签/时间点重新开始执行
• WorkflowApplication 主机的停止可以随时发生，我们可以从最后一个书签/时间点重新开始执行

我已经用工作流持久性工作了几天，但我不确定我是否可以用它来实现我的目标。为什么？

• 我可以在每个自定义活动中使用阻止书签，但是阻止工作流并重新启动它只是为了让它持久化看起来并不乐观。
• 我可以使用不阻止书签，但我无法在数据库中看到它们并从中恢复。

你能告诉我吗，工作流书签是这里的路吗？

我在不阻止书签方面看到了一些亮点，但我无法保留它们并稍后恢复。您能否给我一些提示，如何为以后的简历保留非阻塞书签？

编辑：

在 wf3 中有一个属性PersistOnClose足以满足我的要求。在 wf4 中，它被替换为Persist活动，这也可能很有用，但是我不想在我已经很复杂的工作流程中进行额外的活动。

理想情况下，能够从 执行会很棒context.RequestPersist(callback)，NativeActivityContext但是这个方法是内部的（并且它里面的所有东西在原始程序集之外都是不可见的。