必要な問題報告システムがあります。
- 構成されたグループに電子メールを送信する
- Web サービスを呼び出して、問題レポートを別のチームに渡す
人間の相互作用や待機はありません。
私には、これほど単純なことにワークフローを使用するのはやり過ぎのように思えます。
私のアーキテクトは、ここではワークフローが最良の選択であると考えています。
考え?
必要な問題報告システムがあります。
人間の相互作用や待機はありません。
私には、これほど単純なことにワークフローを使用するのはやり過ぎのように思えます。
私のアーキテクトは、ここではワークフローが最良の選択であると考えています。
考え?
警告:WFでの私の経験は、.NET3.5の製品に基づいています。
私はここであなたに同意します、このシナリオではWFはやり過ぎのようです。あなたが強調したシナリオは、非常に単純であるため、BPM/ワークフローツールを実際に保証するものではないと言っても過言ではありません。
あなたの建築家があなたにそれを使うように頼むかもしれない唯一の理由は私が考えることができるでしょう
ただし、シナリオがあなたの説明どおりである場合、ほとんどのBPMツール、特にWFは、使用するのに非常に多くのリソースを消費するため、どの使用よりもはるかに大きなオーバーヘッドになります(新しいバージョンは、3.5で出荷されたものよりもはるかに改善されていると聞きましたでも)
ワークフローは、長時間実行されるプロセスに最適です。永続性と耐久性を提供するため、長期間にわたってビジネス プロセスを再開できます。
あなたのプロセスは、スクリプトまたは C# で単一のメソッドとして実装できるように思えます。
単純なことを行うには重すぎるという理由でワークフロー基盤を避ける時代は終わりました。Workflow Foundation 4.0 と現在の 4.5 は、3.5 以前に比べて非常に軽量です。あなたが説明したような単純なワークフローの作成は、作成と実行の両方が簡単で、どこからでも実行できます。
Web サービスの呼び出しはすぐに使用できるアクティビティであり、電子メールの送信はサンプルから取得できるアクティビティです。FlowChart アクティビティを使用してカスタム ワークフロー アクティビティに両方をスローし、どこかで実行するメソッドで WorkflowInvoker クラスを使用して、それを忘れます。仕事が完了しただけでなく、何が起こっているかを示すワークフロー図の形式のドキュメントが少しあります。
The Workflow Way - WF 4.0+ の利点を説明するための David Chappell による記事