2

IIS で実行されている *.xamlx ワークフロー サービスがあり、State1、State2、および State3 があります。

Trigger T1 (State 1 -> State 2) listens to "Start" message on Receive Activity.
Trigger T2 (State 2 -> State 3) listens to "Proceed" message on Receive Activity.

私が抱えている問題は、状態マシンが状態 1 にあり、「続行」メッセージが表示されているときに、InvalidOperationException のようなものを期待していることです。ただし、キューで待機しているだけのようで、タイムアウト例外で失敗します。

ここで期待される動作を得るにはどうすればよいですか?

4

1 に答える 1

1

数年後に消えないように、MSDN フォーラムのMSFT である Jim Carleyから得た回答をここに貼り付けます。

アレクサンダー、

ワークフローに「プロトコル ブックマーク」と「非プロトコル ブックマーク」の両方がある状況に陥っています。"プロトコル ブックマーク" は、メッセージング アクティビティ (受信など) によって作成されます。「非プロトコル ブックマーク」は、メッセージング アクティビティとは関係のないブックマークです。また、State アクティビティは、非プロトコル ブックマークを内部的に作成します。

この問題は、「ピック」も使用した場合に報告されました - https://social.msdn.microsoft.com/Forums/vstudio/en-US/275f7817-1ec7-433c-89ba-fe48afd1dae8/wf4-wcf-send-message-at -wrong-time?forum=wfprerelease

以下は、そのスレッドに関する私の説明からの抜粋です。

Pick アクティビティまたは State アクティビティを使用して OperationB の Receive をカプセル化する際の動作の違い (タイムアウト) の根本的な原因は、Pick アクティビティと State アクティビティが、Receive アクティビティによって作成されたブックマークとは無関係の内部ブックマークを作成することです。

受信アクティビティによって作成されたブックマーク (「プロトコル ブックマーク」と呼びましょう) は、ワークフロー サービスによって実装されたメッセージング プロトコルを保持するために、特別な方法で処理されます。

サービスに Operation1 のメッセージング「プロトコル」があり、その後に Operation2 が続くシナリオを想像してください。

受信(操作1)

SendReply(操作1)

DoSomeOtherWork

受信(操作2)

SendReply(操作2)

DoSomeOtherWork に、ワークフロー インスタンスがアイドル状態になる可能性のある非同期操作がある場合、非プロトコル ブックマークが作成されます。これらのブックマークは、ワークフロー サービスのメッセージング プロトコル以外の方法で再開されます。

そのため、Operation1 が完了し、DoSomeOtherWork が完了する前にクライアントが Operation2 を送信する可能性があります。Operation2 をすぐに拒否したくありません。代わりに、DoSomeOtherWork によって実行されている作業が完了し、その作業に関連付けられているブックマークが再開されることを期待して、Operation2 メッセージを待ちます。DoSomeOtherWork が完了すると、Receive(Operation2) のプロトコル ブックマークが作成され、クライアントからのメッセージが正常に処理されるようになります。

DoSomeOtherWork がまだ未処理である間に、操作 2 のメッセージが受信されます。Operation2 のプロトコル ブックマークがないことがわかります。次に、インスタンスに対して未処理の非プロトコル ブックマークがあるかどうかを確認します。存在する場合 (DoSomeOtherWork がまだ未解決の場合など)、メッセージを保留します。ただし、プロトコル以外のブックマークが他にない場合は、メッセージを順不同として直ちに拒否します。

.NET 4.6 以降では、サービスの web.config ファイルで指定できる AppSetting があり、非プロトコル ブックマークと順不同メッセージの処理方法を制御します。AppSetting を構成するには、これを web.config ファイルに追加します。

この「FilterResumeTimeoutInSeconds」の値は、ワークフロー ランタイムがタイムアウトになる前に、順序が正しくないメッセージを保持する時間の長さ (秒単位) を指定します。デフォルト値は 60 です。値 0 は、まったく待機しないことを指定し、次のテキストで障害を伴う順序不同のメッセージを拒否します。

識別子 '' を持つサービス インスタンスに対する操作 '' は、現時点では実行できません。操作が正しい順序で実行されていること、および使用中のバインディングが順序どおりの配信を保証していることを確認してください。

値が 0 より大きい場合、指定された時間が経過した後もタイムアウト例外が発生します。

繰り返しになりますが、この新しい AppSetting は .NET 4.6 以降で使用できます。そして、これはすべて BufferedReceive が使用されていないことを前提としています。

これはここにも文書化されています: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announce-net-framework-4-6.aspx?PageIndex=2

于 2015-08-20T11:22:30.303 に答える