如何处理“接收”呼叫不按顺序进行？
我有一个模拟销售漏斗的 WF4 服务。它的工作原理是从“注册”接收呼叫开始。之后，有 10 个类似的阶段（每个阶段包含 2 个接收）。在当前阶段验证收到的数据之前，您无法前进到某个阶段。但我不确定的是，即使我的客户端应用程序不允许这样做，我怎样才能使我的工作流程阻止任何人乱序调用接收操作？在我的测试控制台应用程序中，我让用户调用任何接收操作（只是因为我想看看会发生什么）。
例如，如果我先调用 Register，然后在“AddProspect”接收之前调用“AddQualification”，则测试应用程序返回时会出现如下异常：
此时无法对标识符为“1984c927-402b-4fbb-acd4-edfe4f0d8fa4”的服务实例执行“AddQualification|{http://tempuri.org/}IZSalesFunnelService”操作。请确保操作按照正确的顺序执行，并且使用中的绑定提供有序交付保证
有两件事我不知道该怎么做：
首先，我如何处理故障异常，以有意义的方式通知客户端……
其次，因为我正在使用持久性（和属性提升），当我进行无序调用时，升级的属性会卸载。客户获得例外后，他们不会再次晋升。
有什么想法吗？
I have a WF4 service that emulates a sales funnel. It works by starting with a "Registration" receive call. After that, there are 10 similar stages (comprised of a 2 receives at each stage). You can't advance past a stage until after the current stage validates the data received. What I'm unsure about though is, even though my client app wouldn't allow for it, how can I make my workflow prevent anyone from calling the receive operations out of order? In my test console app, I let the user call any receive operation (just because I wanted to see what happens).
For example, if I call the Register first and then the "AddQualification" receive before the "AddProspect" receive, the test app returns with an exception like this:
Operation 'AddQualification|{http://tempuri.org/}IZSalesFunnelService' on service instance with identifier '1984c927-402b-4fbb-acd4-edfe4f0d8fa4' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees
2 things come from this that I don't know how to do:
First, how do I handle the Fault Exception to notify the client in a meaningful way and...
Second, because I'm using persistence (and property promotion), when I make the out of order call, the properties that are promoted unload. They are not promoted again after the client gets the exception.
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
抱歉，我的服务器有点繁忙，所以博客暂时停止播放。
关于第二个问题，您需要确保将工作流服务设置为“放弃”以处理未处理的异常。以下是此设置的 AppFabric 的文档：
放弃。服务主机中止内存中的工作流服务实例。数据库中实例的状态保持“活动”。工作流管理服务从持久性数据库中保存的最后一个持久性点恢复废弃的工作流实例。
放弃并暂停。服务主机中止内存中的工作流服务实例，并将持久性数据库中的实例状态设置为“挂起”。稍后可以使用 IIS 管理器恢复或终止挂起的实例。工作流管理服务不会自动恢复这些实例。
终止。服务主机中止内存中的工作流服务实例，并将持久性数据库中的实例状态设置为“已完成（终止）”。已终止的实例稍后无法恢复。
取消。服务主机取消工作流服务实例，导致调用所有取消处理程序，以便工作流以优雅的方式终止，并将持久性数据库中的实例状态设置为“已完成（已取消）”。
放弃是唯一将您的工作流程保留在持久性存储中的设置，以便您可以再次调用它。
希望这有帮助。
Sorry, my server is playing up a little so the blog keeps going off the air temporarily.
With regard to your second question, you need to make sure that your workflow service is set to Abandon for unhandled exceptions. Here is the doco for AppFabric for this setting:
Abandon. The service host aborts the workflow service instance in memory. The state of the instance in the database remains “Active”. The Workflow Management Service recovers the abandoned workflow instance from last persistence point saved in the persistence database.
Abandon and suspend. The service host aborts the workflow service instance in memory and sets the state of the instance in the persistence database to “Suspended”. A suspended instance can be resumed or terminated later by using IIS Manager. These instances are not recovered by the Workflow Management Service automatically.
Terminate. The service host aborts the workflow service instance in memory, and sets the state of the instance in the persistence database to “Completed (Terminated)”. A terminated instance cannot be resumed later.
Cancel. The service host cancels the workflow service instance causing all the cancellation handlers to be invoked so that a workflow terminates in a graceful manner, and sets the state of the instance in the persistence database to “Completed (Cancelled)”.
Abandon is the only setting that will hold onto your workflow in the persistence store so that you can then call it again.
Hope this helps.
关于你的第一个问题，我会看看 Rory Primroses 关于如何屏蔽内容关联失败的帖子：管理内容关联失败。在这里，他将异常转换为有效的业务异常。
Regarding your first question I'd look at Rory Primroses post on how to shield Content Correlation Failures: Managing Content Correlation Failures. In here he translates an exception into a valid Business Exception.