1

[これが少し主観的であることは承知していますが、この種の要件を処理するための書記体系の知識を持っている人がいるに違いありません。注: C#、.Net4 を使用し、SP2010 を使用しています]

私は、ワークフローを含み、バックエンド システムとの対話も必要とするカスタム ビジネス アプリケーション用に SharePoint2010 と WF4 を評価してきました。

(SP2010 も WF4 も使用せず、ステータス変更を DB に書き込み、自動化されたステージを実行するために Windows サービスを直接書き込むというオプションもあります。)

SP2010 は、ほとんどの要件について非常に急な学習曲線と制限された機能を証明しています...ただし、ワークフロー部分、特に「リストとタスク」については優れており、セキュリティを伴う新しいリストの実装の容易さはおまけです.

では、WF4 でこの機能の一部をエミュレートする方法はありますか?

考え

MVC3 アプリケーション、ユーザーの AD グループは、実行できる「キュー」と機能を決定します。
ユーザーは自分のリクエストやステータスなどを確認できます。

ワークフローをホストする WF4 サービス。一部の手順は自動です。

例 1

ユーザー NormalPerson (NP) がサイトを開き、[Create New Request] をクリックします。

フォームを使用すると、バックエンド システムからデータを検索できます (数千行、特に複数の検索とフィルター/並べ替えが必要なため、SP2010 はこれに真剣に取り組んでいますが、jQuery+DataTables+Ajax を使用するとこれが簡単になります)

NP はリクエストを保存します

WF4 は要求を「取得」し、「承認が必要」として設定し、電子メールを BackOffice (BO) グループに送信し、DB に永続化します (BLL 相互作用を介して)。

BO ユーザーは、サイトを開いて「新しいリクエスト」のリストを表示し、1 つを開いて承認することができます。

WF4 はフィールドの変更を「取得」し、電子メールを NP およびケース管理グループに送信し、DB に保持します。

CM ユーザーは「待機中のアクション」のリストを開き、アクションを実行し (バックエンド システムも更新します)、完了に設定します。

WF4 は変更を「取得」し、確認を NP に送信し、要求をアーカイブします。

例 2

NP は新しいリクエストを作成します

WF4 がメールを送信し、「承認が必要」を設定します

BO ユーザーがリストで新しいリクエストを見つけ、開くが拒否する

WF4 は、要求へのリンクを含む電子メールを NP に送信します

NP はリンクを開き、要求を修正し、保存します

WF4 は「更新された」電子メールを Bo グループに送信し、再送信済みとしてマークします

BO ユーザーは「再送信済み」リストを開き、アイテムを選択して「マネージャーの承認が必要」に設定します

WF4 がマネージャーの電子メールを送信

マネージャーは自分のリストのアイテムを見て、開いて承認します。

WF4 から CM グループにメールが送信されます...前と同じように続行します。

例 3

NP は新しいリクエストを保存します

WF4 がリクエストを受け取りました。制限が不足しているため、適切なメールで「CM」に直接送信してください

CMユーザーが拾う…………そのまま続ける。

例 4

NP は新しいリクエストを保存します

WF4 は要求を受け取り、手動での介入を必要としないため、バックエンド システム (BLL/WCF 呼び出しなど) を更新し、電子メールなどで "完了" に設定します。

CMユーザーが拾う…………そのまま続ける。

例 5

NP は新しいリクエストを保存します

WF4 は要求を受け取り、電子メールを送信し、「承認が必要」のままになります

NP はリクエストを開き、誰もが作業できるようになる前にキャンセルします。

WF4 は変更を取得し、アイテムを「キャンセル済み」に移動します。

4

2 に答える 2

0

オープンソースのワークフロー エンジンの使用を検討したことがありますか? リストは次のとおりです: http://java-source.net/open-source/workflow-engines

私のSharepointでの経験はひどいものでした。WF4のことは何も知りません。非常に多くあり、それらはオープン ソースであるため、拡張する必要がある場合はフレームワークをカスタマイズできます。

もう 1 つの可能性は、JIRA を使用することです。正式にはワークフロー ツールではありませんが、優れたワークフロー機能を備えています。各リクエストは、異なる種類のタスクと考えてください。

于 2012-10-30T05:03:54.077 に答える
0

あなたが与えた例から、WF4を使用してこの問題を解決できると思います。WF4 は、優れたトランザクション制御とフロー制御機能を提供します。

  • NP が開始する新しいリクエストごとに、ワークフローの新しいインスタンスが作成されます。
  • 各ステップ (NP がリクエストを送信し、BO がそれを承認するなど) はトランザクション スコープに含まれているため、後続のステップの結果とは無関係に、ステップに含まれるデータが確実に DB に保存されます。
  • 各ステップの後、ワークフローは DB に永続化されます (ここで WF 内で使用するセッション データには注意してください)。
  • 新しいステップが開始されると、ワークフローの同じインスタンスが DB から呼び出されるため、プロセスが一意になります。
  • 電子メール通知の送信は、SMTP サーバーの使用をカプセル化するアクティビティになります (C# には、このためのオブジェクトとメソッドが組み込まれています)。

SP2010 には制限があり、ワークフロー エンジンの .NET 3.5 実装に基づいています (SP2013 は .NET 4.5 をサポートするはずです)。私がそれにアプローチする方法は、SOAを使用することです。WF4は、ワークフロー サービス (WCF 機能を実装するアクティビティにラップされていることを除いて、通常のワークフロー) のおかげで、 Windows Communications Foundationと簡単に統合できます。ワークフロー サービスを使用すると、WCF を介してワークフローを公開します。つまり、ワークフローをサービスであるかのように使用して、SP2010 から実行するか、独自の SP2010 ワークフロー ホストを作成して、SP ワークフローから WF を実行できます (最後のワークフローについては完全にはわかりません)。事ですが、私はそれが可能だと信じています）。

したがって、WF4 と WCF の両方を組み合わせることで、思いどおりに機能するソリューションを構築できます。もちろん、ソリューションの設計は WF4 とその使用方法だけに依存するわけではありませんが、それは良い選択肢だと思います。また、任意のクライアント (MVC、モバイルなど) からプロセスを抽象化する機会も提供します。

サービスや WCF の実装に関するすべての追加の考慮事項を使用したくない場合は、このアプローチは必要ありません。私はそれが可能であることを指摘しているだけです。

お役に立てれば。

于 2012-10-30T15:50:11.083 に答える