2

ご意見やアドバイスをよろしくお願いします！

長時間実行されるワークフローの永続性を必要とする大規模なプロジェクトでWF4を使用しています。デプロイメントの一貫性の理由から、インスタンスストアオブジェクトに代替スキーマ名を使用すると便利です。たとえば、System.Activities.DurableInstancing.InstanceTableはDurableInstancing.InstanceTableなどになります。

このサーバー側を実現するためにSQLスクリプトを更新することは難しくありませんが、私が知る限り、コマンドを生成するときにSqlWorkflowInstanceStoreによって使用されるデフォルトのスキーマを変更する方法はありません。スキーマ名は、定数であるSqlWorkflowInstanceStoreConstants.DefaultSchemaから読み取られているようです（名前が示すとおり）。SqlWorkflowInstanceStoreは封印されており、独自のInstanceStoreをロールするのはかなりの作業のように思われるため、そのオプションを追求することには消極的です。

私が行方不明になっているかもしれないこれを行うためのより簡単な方法を誰かが知っていますか？また、スキーマ名を変更すると、将来のインスタンスストアの更新を適用するための手順が追加されることを認識していますが、他の潜在的な問題を予測できる人はいますか？

4

2 に答える 2

0

私はそれを試したことはありませんが、私が知る限り、SqlWorkflowInstanceStore はストアド プロシージャのみを呼び出します。これらはすべて System.Activities.DurableInstancing DB スキームにある必要がありますが、テーブルとビューを別の DB スキームに移動できるはずです。

率直に言って、サポートされているシナリオではなくなり、メリットが見られないことを意味するため、おそらくそれを行うことはありません。何らかの理由で System.Activities.DurableInstancing テーブル/ビューを照会する必要があり、別の DB スキームにある必要があるアプリのセットアップ方法のために、元のテーブルを指すビューを作成するだけです。

于 2012-11-14T08:23:07.053 に答える
0

独自の InstanceStore を実装することは難しくありません。私たちも似たような状況にありました。自分たちのスキーマとワークフロー SQL という 2 つのスキーマを持ちたくありませんでした。独自の InstanceStore を実装しました。約 280 行のコードです。スキーマに 1 つのテーブルを追加し、既存のテーブルにいくつかのフィールドを追加する必要がありました。

独自の InstanceStore を実装してみることをお勧めします。

于 2012-11-14T15:25:35.743 に答える