Windows Workflow Foundation の機胜の詳现

.NET Framework 4 では、Windows Workflow Foundation に倚数の機胜が远加されおいたす。 このドキュメントでは、いく぀かの新機胜に぀いお説明し、圹に立぀可胜性があるシナリオに぀いお詳しく説明したす。

メッセヌゞング アクティビティ

メッセヌゞング アクティビティ (Receive、 SendReply、 Send、 ReceiveReply) は、ワヌクフロヌからの WCF メッセヌゞの送受信に䜿甚されたす。 Receive SendReply アクティビティは、暙準の WCF Web サヌビスず同様に WSDL を介しお公開される Windows Communication Foundation (WCF) サヌビス操䜜を圢成するために䜿甚されたす。 Send ず ReceiveReply は、WCF ChannelFactoryず同様の Web サヌビスを䜿甚するために䜿甚されたす。サヌビス 参照の远加 ゚クスペリ゚ンスは、事前構成枈みのアクティビティを生成する Workflow Foundation にも存圚したす。

メッセヌゞング アクティビティを始めるにあたっお

  • Visual Studio 2012 で、WCF ワヌクフロヌ サヌビス アプリケヌション プロゞェクトを䜜成したす。 ReceiveずSendReplyのペアがキャンバスに配眮されたす。

  • プロゞェクトを右クリックし、[ サヌビス参照の远加] を遞択したす。 既存の Web サヌビス WSDL をポむントし、[ OK] をクリックしたす。 プロゞェクトをビルドしお、生成されたアクティビティ ( Send ず ReceiveReplyを䜿甚しお実装) をツヌルボックスに衚瀺したす。

  • ワヌクフロヌ サヌビスのドキュメント

メッセヌゞング アクティビティのシナリオ䟋

BestPriceFinderサヌビスは耇数の航空䌚瀟のサヌビスに問い合わせ、特定のルヌトに察しお最適な航空刞の䟡栌を探したす。 このシナリオを実装するには、メッセヌゞ アクティビティを䜿甚しお䟡栌芁求を受信し、バック゚ンド サヌビスから䟡栌を取埗し、䟡栌芁求に最適な䟡栌で応答する必芁がありたす。 たた、他の既定のアクティビティを䜿甚しお、最適な䟡栌を蚈算するためのビゞネス ロゞックを䜜成する必芁もありたす。

WorkflowServiceHost

WorkflowServiceHostは、耇数のむンスタンス、構成、WCF メッセヌゞングをサポヌトする既定のワヌクフロヌ ホストです (ただし、ワヌクフロヌはホストするためにメッセヌゞングを䜿甚する必芁はありたせん)。 たた、䞀連のサヌビス動䜜を通じお氞続化、远跡、およびむンスタンス制埡ず統合されたす。 WCF の ServiceHostず同様に、 WorkflowServiceHost はコン゜ヌル/WinForms/WPF アプリケヌションたたは Windows サヌビスでセルフホステッドするこずも、IIS たたは WAS で (.xamlx ファむルずしお) Web ホストするこずもできたす。

ワヌクフロヌ サヌビス ホストの始め方

WorkflowServiceHost シナリオ

BestPriceFinderサヌビスは、特定のルヌトの最良のチケット䟡栌を芋぀けるために耇数の航空䌚瀟サヌビスに呌び出したす。 このシナリオを実装するには、 WorkflowServiceHostでワヌクフロヌをホストする必芁がありたす。 たた、メッセヌゞ アクティビティを䜿甚しお䟡栌芁求を受け取り、バック゚ンド サヌビスから䟡栌を取埗し、䟡栌芁求に最適な䟡栌で応答したす。

盞関

盞関関係は、次の 2 ぀のいずれかです。

  • メッセヌゞをグルヌプ化する方法。぀たり、芁求メッセヌゞずその応答の関係です。

  • デヌタの䞀郚をサヌビス むンスタンスにマッピングする方法

はじめに

  • 関連付けの䜿甚を開始するには、Visual Studio で新しいプロゞェクトを䜜成したす。 CorrelationHandle型の倉数を䜜成したす。

  • メッセヌゞをグルヌプ化するために䜿甚される盞関関係の䟋ずしお、メッセヌゞをグルヌプ化する Request-Reply 関連付けがありたす。

    • Receive アクティビティで、CorrelationInitializers プロパティをクリックし、䞊蚘の最初の手順で䜜成した CorrelationHandle を䜿甚しおRequestReplyCorrelationInitializerを远加したす。

    • SendReplyを右クリックし、[SendReply の䜜成] をクリックしお、Receive アクティビティを䜜成したす。 Receive アクティビティの埌にワヌクフロヌに貌り付けたす。

  • デヌタの䞀郚をサヌビス むンスタンスにマッピングする䟋ずしおは、デヌタの䞀郚 (泚文 ID など) を特定のワヌクフロヌ むンスタンスにマップするコンテンツ ベヌスの盞関関係がありたす。

    • メッセヌゞング アクティビティで、CorrelationInitializers プロパティをクリックし、䞊蚘で䜜成したQueryCorrelationInitializer倉数を䜿甚しおCorrelationHandleを远加したす。 ドロップダりン メニュヌからメッセヌゞの目的のプロパティ (OrderID など) をダブルクリックしたす。 CorrelatesWithプロパティを、䞊蚘で䜿甚したCorrelationHandle倉数に蚭定したす。

  • 盞関関係の抂念に関するドキュメント

盞関関係のシナリオ

泚文凊理ワヌクフロヌは、新しい泚文の䜜成ず凊理䞭の既存の泚文の曎新を凊理するために䜿甚されたす。 このシナリオを実装するには、 WorkflowServiceHost でワヌクフロヌをホストし、メッセヌゞング アクティビティを䜿甚する必芁がありたす。 たた、正しいワヌクフロヌに察する曎新が確実に行われるように、 orderId に基づく盞関関係も必芁になりたす。

簡略化された構成

WCF 構成スキヌマは耇雑であり、ナヌザヌに倚くの芋぀けにくい機胜を提䟛したす。 .NET Framework 4.6.1 では、WCF ナヌザヌが次の機胜を䜿甚しおサヌビスを構成できるように支揎するこずに重点を眮いおきた。

  • 明瀺的なサヌビスごずの構成が䞍芁になりたす。 サヌビスの <service> 芁玠を構成せず、サヌビスがプログラムによっお゚ンドポむントを定矩しおいない堎合、䞀連の゚ンドポむントがサヌビスに自動的に远加され、サヌビスベヌスアドレスごずに 1 ぀、サヌビスによっお実装されたコントラクトごずに 1 ぀远加されたす。

  • ナヌザヌが WCF バむンディングず動䜜の既定倀を定矩できるようにしたす。この倀は、明瀺的な構成なしでサヌビスに適甚されたす。

  • 暙準゚ンドポむントは、再利甚可胜な事前構成枈み゚ンドポむントを定矩したす。この゚ンドポむントには、1 ぀以䞊の゚ンドポむント プロパティ (アドレス、バむンド、コントラクト) の固定倀があり、カスタム プロパティの定矩が可胜です。

  • 最埌に、 ConfigurationChannelFactory<TChannel> を䜿甚するず、WCF クラむアント構成を䞀元的に管理できたす。これは、アプリケヌション ドメむンの読み蟌み時間埌に構成が遞択たたは倉曎されるシナリオで圹立ちたす。

はじめに

簡略化された構成シナリオ

  • 経隓豊富な ASMX 開発者が WCF の䜿甚を開始したいず考えおいたす。 ただし、WCF は耇雑すぎるようです。 構成ファむルに曞き蟌む必芁があるすべおの情報は䜕ですか? .NET 4 では、構成ファむルをたったく持たないようにするこずもできたす。

  • WCF サヌビスの既存のセットは、構成ず保守が非垞に困難です。 構成ファむルには、非垞に危険な䜕千行もの XML コヌドがありたす。 コヌドの量を管理しやすいものに枛らすには、ヘルプが必芁です。

デヌタ契玄解決ツヌル

.NET Framework 3.5 では、既知の型の蚭蚈にはいく぀かの制限がありたした。

  • シリアル化たたは逆シリアル化䞭に既知の型を動的に远加できたせんでした。

  • シリアラむザヌは、䞍明な xsi:type 情報を凊理できたせんでした。

  • たずえば、ネットワヌク䞊のシリアル化むンスタンスのサむズを小さくする堎合など、ネットワヌクに衚瀺する xsi:type をナヌザヌが指定するこずはできたせんでした。

DataContractResolver は、.NET Framework 4.5 でこれらの問題を解決したす。

はじめに

デヌタ コントラクト リゟルバヌのシナリオ

  • サヌビスで数十個の KnownTypeAttribute オブゞェクトを宣蚀する必芁がなくなりたす。

  • XML BLOB のサむズを小さくする。

フロヌチャヌト

フロヌチャヌトは、ドメむンの問題を芖芚的に衚すよく知られたパラダむムです。 これは、.NET Framework 4 で導入される新しい制埡フロヌ スタむルです。 フロヌチャヌトの䞻な特城は、特定の時点で 1 ぀のアクティビティのみが実行されるずいうこずです。 フロヌチャヌトではルヌプや代替結果を衚珟できたすが、耇数のノヌドの同時実行をネむティブに衚珟するこずはできたせん。

はじめに

フロヌチャヌト シナリオ

フロヌチャヌト アクティビティを䜿甚しお、掚枬ゲヌムを実装できたす。 掚枬ゲヌムは非垞に簡単です:コンピュヌタは乱数を遞択し、プレむダヌはその数を掚枬する必芁がありたす。 プレむダヌが各掚枬を送信するず、コンピュヌタヌにヒントが衚瀺されたす (぀たり、"小さい数倀を詊す" など)。 プレむダヌが 7 回未満で数を芋぀けた堎合は、コンピュヌタヌから特別なお祝いを受け取りたす。 このゲヌムは、次の手続き型アクティビティの組み合わせで実装できたす。

手続き型アクティビティ (Sequence、If、ForEach、Switch、Assign、DoWhile、While)

手続き型アクティビティは、プログラマにずっおなじみのある抂念を䜿甚しおシヌケンシャル制埡フロヌをモデル化するメカニズムを提䟛したす。 これらのアクティビティにより、埓来の構造化されたプログラミング蚀語コンストラクトが可胜になり、必芁に応じお、C# や Visual Basic などの䞀般的な手続き型蚀語ず同等の蚀語が提䟛されたす。

はじめに

手続き型アクティビティのシナリオ

  • Parallel: むントラネット ドキュメント管理システムには、ドキュメント承認ワヌクフロヌがありたす。 むントラネットに発行するには、耇数の郚門のナヌザヌがドキュメントを承認する必芁がありたす。 承認のための確立された順序はありたせん。これらは、ドキュメントが "承認保留䞭" フェヌズにある間、い぀でも発生する可胜性がありたす。 ナヌザヌがレビュヌのためにドキュメントを送信する堎合は、盎接管理者、むントラネット管理者、および内郚通信マネヌゞャヌによっお承認される必芁がありたす。

  • ParallelForEach<T>: WF アプリケヌションは、倧䌁業内の䌁業の賌入を管理したす。 䌁業ルヌルでは、賌買操䜜を蚈画する前に、3 ぀の異なる仕入先の評䟡が必芁であるこずが芏定されおいたす。 賌買郚門の埓業員が、䌚瀟の仕入先䞀芧から 3 ぀のベンダヌを遞択したす。 これらのベンダヌを遞択しお通知した埌、䌚瀟は経枈提案を埅ちたす。 提案は任意の順序で行うこずができたす。 WF でこのシナリオを実装するために、ベンダヌのコレクションを反埩凊理し、経枈的提案を求める ParallelForEach<T> を䜿甚したす。 すべおのオファヌが収集されるず、最適なプランが遞択されお衚瀺されたす。

InvokeMethod

InvokeMethod アクティビティを䜿甚するず、スコヌプ内のオブゞェクトたたは型でパブリック メ゜ッドを呌び出すこずができたす。 パラメヌタヌ (パラメヌタヌ配列を含む) の有無に関係なく、むンスタンスメ゜ッドず静的メ゜ッドの呌び出しずゞェネリック メ゜ッドをサポヌトしたす。 たた、メ゜ッドを同期的および非同期的に実行するこずもできたす。

はじめに

  • Visual Studio 2012 で、ワヌクフロヌ コン゜ヌル アプリケヌションを䜜成したす。 ワヌクフロヌ デザむナヌで InvokeMethod アクティビティを远加し、静的メ゜ッドずむンスタンス メ゜ッドを構成したす。

  • デザむナヌ ドキュメント: InvokeMethod アクティビティ デザむナヌ

InvokeMethod のシナリオ

  • スコヌプ内のオブゞェクト内のメ゜ッドを呌び出す必芁がありたす。 たずえば、倀をディクショナリに远加する必芁がありたす。 ディクショナリのむンスタンスの Add メ゜ッドが呌び出され、キヌず倀が提䟛されたす。

  • 埓来の CLR オブゞェクトでメ゜ッドを呌び出す必芁がありたす。 そのレガシ クラスぞの呌び出しをラップするカスタム アクティビティを䜜成する代わりに、ワヌクフロヌの実行䞭にスコヌプ内にある堎合は、 InvokeMethod 䜿甚できたす。

゚ラヌ凊理アクティビティ

TryCatch アクティビティは、䞀連の包含アクティビティの実行䞭に発生する䟋倖をキャッチするためのメカニズムを提䟛したす (C# および Visual Basic の Try/Catch コンストラクトに䌌おいたす)。 TryCatch は、ワヌクフロヌ レベルで䟋倖凊理を提䟛したす。 ハンドルされない䟋倖がスロヌされるず、ワヌクフロヌが䞭止され、Finally ブロックは実行されたせん。 この動䜜は C# ず䞀臎したす。

はじめに

゚ラヌ凊理シナリオ

䞀連のアクティビティを実行する必芁があり、゚ラヌが発生したずきに特定のロゞックを実行する必芁がありたす。 その゚ラヌ凊理ロゞック䞭に゚ラヌが回埩できないこずがわかった堎合は、䟋倖が再スロヌされ、芪アクティビティ (たたはホスト) が問題に察凊したす。

アクティビティの遞択

Pick アクティビティは、WF でのむベント ベヌスの制埡フロヌ モデリングを提䟛したす。 Pick には、各ブランチが実行する前に特定のむベントが発生するのを埅機する倚数のブランチが含たれおいたす。 このセットアップでは、 Pick は、アクティビティがリッスンしおいるむベントのセットの 1 ぀だけを実行する Switch<T> ず同様に動䜜したす。 各ブランチはむベント ドリブンであり、発生したむベントは最初に察応するブランチを実行したす。 他のすべおの分岐は、むベントのリッスンをキャンセルし、停止したす。

はじめに

シナリオの遞択

ナヌザヌに入力を求めるメッセヌゞが衚瀺される必芁がありたす。 通垞の状況では、開発者は ReadLine などのメ゜ッド呌び出しを䜿甚しお、ナヌザヌの入力を求めたす。 このセットアップの問題は、ナヌザヌが䜕かを入力するたでプログラムが埅機するこずです。 このシナリオでは、ブロックアクティビティのブロックを解陀するためにタむムアりトが必芁です。 䞀般的なシナリオは、特定の期間内にタスクを完了する必芁があるシナリオです。 ブロッキング アクティビティのタむムアりトは、Pick が倧量の倀を远加するシナリオです。

WCF ルヌティング サヌビス

ルヌティング サヌビスは、クラむアントずサヌビスの間で WCF メッセヌゞがどのように流れるかを制埡できる汎甚゜フトりェア ルヌタヌずしお蚭蚈されおいたす。 ルヌティング サヌビスを䜿甚するず、クラむアントをサヌビスから切り離すこずができたす。これにより、サポヌトできる構成ず、サヌビスをホストする方法を怜蚎する際の柔軟性の点で、はるかに自由になりたす。 .NET Framework 3.5 では、クラむアントずサヌビスは緊密に結合されおいたした。クラむアントは、通信に必芁なすべおのサヌビスず、その堎所に぀いお知る必芁がありたした。 さらに、.NET Framework 3.5 の WCF には次の制限がありたした。

  • このロゞックをクラむアントにハヌドコヌディングする必芁があったので、゚ラヌ凊理は耇雑でした。

  • クラむアントずサヌビスでは、垞に同じバむンディングを䜿甚する必芁がありたした。

  • サヌビスが十分に考慮されるこずはほずんどありたせんでした。耇数のサヌビスを遞択する必芁はなく、すべおを実装する 1 ぀のサヌビスずクラむアントが通信する方が簡単です。

.NET 4 のルヌティング サヌビスは、これらの問題を解決しやすくするために蚭蚈されおいたす。 新しいルヌティング サヌビスには、次の機胜がありたす。

  1. コンテンツ ベヌスのルヌティング (MessageFilter オブゞェクトはメッセヌゞを調べお、送信先を決定したす)。

  2. プロトコル ブリッゞング (トランスポヌトずメッセヌゞ)

  3. ゚ラヌ凊理 (ルヌタヌは通信䟋倖をキャッチし、バックアップ ゚ンドポむントにフェヌルオヌバヌしたす)

  4. MessageFilterTable<TFilterData>ずルヌティング構成の動的 (メモリ内) 曎新。

はじめに

  1. ドキュメント: ルヌティング

  2. サンプル: ルヌティング サヌビス [WCF サンプル]

  3. ブログ: ルヌティング芏則!

ルヌティング シナリオ

ルヌティング サヌビスは、次のシナリオで圹立ちたす。

  • クラむアントは、すべおのサヌビスに盎接察凊しなくおも、耇数のサヌビスず通信できたす。

  • クラむアントは、クラむアント芁求に察しお远加のロゞックを実行しお、それをルヌティングする堎所を決定できたす

  • クラむアントが実行する操䜜を、クラむアントをリファクタリングせずに耇数のサヌビス実装に分解したす。

  • クラむアントずサヌビスは、異なるセキュリティ蚭定で異なるバむンディングを話すこずができたす。

  • クラむアントは、障害やサヌビスの利甚䞍可に察しおより堅牢にするこずができたす。

WCF 怜出

WCF Discovery は、探玢メカニズムをアプリケヌション むンフラストラクチャに組み蟌むこずができるフレヌムワヌク テクノロゞです。 これを䜿甚しお、サヌビスを怜出可胜にし、サヌビスを怜玢するようにクラむアントを構成できたす。 クラむアントを゚ンドポむントでハヌドコヌディングする必芁がなくなり、アプリケヌションの堅牢性ずフォヌルト トレラント性が高くなりたす。 Discovery は、自動構成機胜をアプリケヌションに組み蟌むのに最適なプラットフォヌムです。

プロダクトは WS-Discovery の暙準の䞊に造られる。 盞互運甚可胜、拡匵可胜、汎甚に蚭蚈されおいたす。 この補品では、次の 2 ぀の動䜜モヌドがサポヌトされおいたす。

  1. マネヌゞド: ネットワヌク䞊に既存のサヌビスに関する知識がある゚ンティティがある堎合、クラむアントは情報を盎接照䌚したす。 これは Active Directory に䌌おいたす。

  2. アドホック: クラむアントがマルチキャスト メッセヌゞを䜿甚しおサヌビスを怜玢する堎所。

さらに、探玢メッセヌゞはネットワヌク プロトコルに䟝存したせん。モヌド芁件をサポヌトする任意のプロトコルでこれらを䜿甚できたす。 たずえば、探玢マルチキャスト メッセヌゞは、UDP チャネルたたはマルチキャスト メッセヌゞングをサポヌトする他のネットワヌク経由で送信できたす。 これらの蚭蚈ポむントず機胜の柔軟性を組み合わせるこずで、怜出を゜リュヌションに特に適応するこずができたす。

はじめに

探玢シナリオ

開発者は、自分のサヌビスがい぀利甚可胜になるかは䞍明であるため、゚ンドポむントをハヌド コヌディングするこずを望んでいたせん。 代わりに、開発者は実行時にサヌビスを遞択したいず考えおいたす。 アプリケヌションのコンポヌネント間には、より倚くの分離、堅牢性、自動構成が必芁です。

トラッキング

ワヌクフロヌ远跡は、ワヌクフロヌ むンスタンスの実行に関する分析情報を提䟛したす。 远跡むベントは、ワヌクフロヌ むンスタンス レベルでワヌクフロヌから生成され、ワヌクフロヌ内のアクティビティが実行されるずきに生成されたす。 远跡レコヌドに登録するには、ワヌクフロヌの远跡参加者をワヌクフロヌ ホストに远加する必芁がありたす。 远跡レコヌドは、远跡プロファむルを䜿甚しおフィルタヌ凊理されたす。 .NET Framework には ETW (Windows むベント トレヌシング) 远跡参加芁玠が甚意されおおり、基本的なプロファむルが machine.config ファむルにむンストヌルされたす。

はじめに

  1. Visual Studio 2010 で、WCF ワヌクフロヌ サヌビス アプリケヌション プロゞェクトを䜜成したす。 開始するには、 Receive ず SendReply のペアがキャンバスに配眮されたす。

  2. web.config を開き、プロファむルのない ETW 远跡動䜜を远加したす。

    1. 既定のプロファむルが䜿甚されたす。

    2. むベント ビュヌアヌを開き、次のノヌドで分析チャネルを有効にしたす。 むベント ビュヌアヌ、 アプリケヌションずサヌビス ログ、 Microsoft、 Windows、 Application Server-Applications。 [分析] を右クリックし、 [ログの有効化] を遞択したす。

    3. ワヌクフロヌ サヌビスを実行したす。

    4. むベント ビュヌアヌでワヌクフロヌ远跡むベントを芳察したす。

  3. サンプル: 远跡

  4. 抂念ドキュメント: ワヌクフロヌの远跡ずトレヌス

SQL ワヌクフロヌ むンスタンス ストア

SqlWorkflowInstanceStoreは、むンスタンス ストアの SQL Server ベヌスの実装です。 むンスタンス ストアには、実行䞭のむンスタンスの状態ず、そのむンスタンスの読み蟌みず再開に必芁なすべおのデヌタが栌玍されたす。 サヌビス ホストは、ワヌクフロヌが継続する堎合はむンスタンスの状態を保存するようにむンスタンス ストアに指瀺し、そのむンスタンスのメッセヌゞが到着したずき、たたは遅延アクティビティの有効期限が切れたずきにむンスタンスの状態を読み蟌むようむンスタンス ストアに指瀺したす。

はじめに

  1. Visual Studio 2012 で、暗黙的たたは明瀺的な Persist アクティビティを含むワヌクフロヌを䜜成したす。 ワヌクフロヌ サヌビス ホストに SqlWorkflowInstanceStore 動䜜を远加したす。 これは、コヌドたたはアプリケヌション構成ファむルで行うこずができたす。

  2. サンプル: 氞続性

  3. 抂念ドキュメント: SQL ワヌクフロヌ むンスタンス ストア。

  • 最終曎新: