Workflow Foundation 4のプロセスを、ユーザーが次に完了する必要があるステップを示すレコードを格納するアプリケーションデータベースにリンクするワークフローサービスがあります。ワークフローの再開不可能なエラーが発生した場合、ワークフローを再開することはできませんが、アプリケーション内のデータベースエントリはまだ存在するため、ワークフローの状態と私たちのアプリケーションの状態。任意のステップでワークフローに入力する方法
私がしたいのは、失敗したワークフローの別のインスタンスを作成することですが、それをアプリケーションデータベースのエントリと同期させることです。これは、存在するアプリケーションデータベースのエントリに基づいてワークフロー内の任意のエントリポイントに移動することを必然的に伴います。
これは可能ですか？そうすることに落とし穴がありますか？ワークフローをアプリケーション依存に管理するためのより良い方法はありますか？
ワークフローは次のようになります。
-
は、ワークフローを開始し
- 。これにより、プロセスの進行状況を追跡するアプリケーションdbレコードと、次に実行する必要があることをユーザーに示すdbレコードが作成されます。
- ユーザーは、（receive/sendreplyを使用して）ワークフローサービスへの呼び出しを行うステップを処理し、dbレコードを作業の結果で更新し、ワークフローの次のステップに移動します。
- 手順2は、作業するDBレコードを作成するさまざまなステップすべてを繰り返し、プロセスが完了するまで作業結果と新しいDBレコードを作成してレコードを更新します。
私が答えようとしている質問は、ユーザーがプロセスの特定のステップを取得し、ワークフローエンジンが失敗してワークフローインスタンスが再開できない場合、どのようにアプリケーションデータベースエントリを "プロセスを再起動するプロセスを再起動して、障害の発生箇所をスキップします（最初に障害が発生した問題を解決したと仮定します）。これにより、すでに完了している作業を「やり直す」必要がなくなり、そのプロセスにとどまることがなくなります。
私は、プロセスがどこで終了したかを判断するために作成されたアプリケーションデータベースレコードを調べる方法がある場合、以前に完了したステップをスキップしてワークフローのポイントに移動できればこれらのdbレコードに基づいて失敗した場合、再処理を起こさずに（ユーザーの視点から）プロセスを「再開」することができました。
おかげで、しかし、実際には、おそらくない：
はでそれをチェックアウト。これらは潜在的に長時間実行されるプロセスであり、多くのアプリケーションデータベースレコードを作成しますが、その多くはアプリケーションに関する限り正常に機能しました。それを元に戻すことは、ユーザーにとっては悪いことです。 しかし、これらのワークフローを作成するプロセスの重要な部分を誤解している可能性があります。そのため、ワークフロー自体が失敗することはありません。それが本当の鍵かもしれない。 –
これは長い一連の変更であれば、あなたのワークフローを正常に終了させたいでしょう。いずれか、またはアプリケーションが「ペーパートレイル」を残しておくと、トランザクションIDを使用してクリーンアップできる長時間実行される各トランザクションに関連付けられるアプリの変更履歴があります。 –