Windowsワークフロー - 私たちがする必要があるビジネス・プロセス持っている私たちの会社でPersistableIdle

Question

：

1. はYユーザー待ち
2. X
からのデータは、研究
3. を行うために取得するステップ2に基づいてZからデータを取得します。データ

これを調べるには、ワークフローでこれを実装するオプションがいくつかあるようです。

1. ステップ1（ワークフローアクティビティ）とステップ3（ワークフローアクティビティ）の間に遅延アクティビティを追加します。その後、PersistableIdleイベントの間、ワークフローをアンロードします。手順2でユーザーが完了したら、データベースからワークフローを再読み込みします。
2. 遅延アクティビティの代わりにブックマークを使用する点を除いて、＃1と同じです。

より良い一致（1,2、または別のオプション）がありますか？

他のすべてのアクティビティはAsyncCodeActivitiesなので、PersistableIdleイベントを発生させないようにしていますが、ワークフローが誤ってアンロードされていないことを確認したいと思います。その他の場合。ここにリスクはありますか？ワークフローを強制的にアンロードするアクティビティを作成する方法はありますか？

Answer 1

より良いアプローチ（1,2、または別のオプション）がありますか？

一見して、＃2は必要なように聞こえる。ブックマークを使用する理由は、いつでも再開できることです。これにより、ユーザーYの調査が終了し、ワークフローはいつでも実行を再開できます（遅延が期限切れになるまでブロックされるのではなく）。

＃1が必要かもしれないという反対意見は、ワークフローアクション（リマインダーが発動、例外、キャンセルなど）をトリガする時間制限を設定したい場合があるということです。

どのように決定するのですか？私は答えが普通＃3だと思います：両方

ピックアクティビティの使用は両方を行うのに最適です。 1つのPickBranchトリガーでブックマークアクティビティーを使用し、他のPickBranchトリガーで遅延アクティビティーを使用すると、ユーザーYまたはタイムアウトのいずれかが処理されるワークフローを作成できます。

あなたが提起する副次的な質問は、ワークフローがアンロードされることを望まないときにワークフローを停止させるにはどうすればいいですか？

まあ、それに依存します。 WorkflowServiceHostを使用している場合、WorfklowServiceHostは、より多くの作業（受信メッセージの処理や遅延からの再開）が必要なときにワークフローを再読み込みするのに十分スマートなので、ワークフローをアンロードすることは大きなリスクのように感じません。

WorkflowServiceHostを使用していない場合は、ホストを作成している可能性があります。作業によっては同じ効果が得られます。または、ホストへの書き込み時にアンロードポリシーを制御するWorkflowApplicationのイベントを介して

その他のその他の点： - 非同期コードアクティビティは、非同期作業中にワークフローが永続することを防止します。私は彼らが意図的に抗持続メカニズムとして使用されるべきではないと思っています。もしあなたがそれらの1つを望むなら、NoPersistZone activityをチェックしてください。

- 「アンロード」アクティビティはありませんが、「持続」アクティビティがあります。ワークフローは進捗状況を保存したいと言うことができますが、アンロードが発生したときにホストが最終的な決定を下すことになります。