1

Biztalk ESB Toolkit 2.0との単純な統合パターンを実装しようとすると、オーケストレーション後に発生する変換旅程サービスを解決しようとするときに問題が発生します。

BREリゾルバーを使用して、コンテキストメッセージタイププロパティを検査して使用する適切なマップを決定する必要があるルールを実行しています。ただし、メッセージが変換サービスに関連付けられた旅程のステップに到達すると、マップの実行に失敗します。

注意深い調査から、メッセージタイプはBREリゾルバーによって内部的に使用される「Resolution」オブジェクトに提供されていないようです。実際、前のオーケストレーションを離れるメッセージはタイプされているので、メッセージSystem.Xml.XmlDocumentのタイプはコンテキストから「デモート」されます。

ルールエンジンの実行を追跡することで、BREリゾルバーに到達したときにメッセージのタイプが実際に失われていることを確認できます。メッセージのタイプは空ですが、強くタイプされたドキュメントはMicrosoft.XLANGs.BaseTypes.Anyです。

私が使用しているオーケストレーションサービスは、ESBToolkit2.0に付属しているサンプルから直接取得されています。

旅程のオーケストレーション後にコンテキストベースのBRE解決を実行する方法はありますか？

4

1 に答える 1

0

私自身の質問に答える...要するに、重要なのは、元のメッセージのコンテキストを先取りし、MessageTypeコンテキストプロパティをプロモートすることです。次の段落では、ブログに次の投稿を複製します。

オーケストレーション旅程サービス101

この作業を行うのに苦労し、さまざまな解決策を試した後、私はついに従うべき一連の簡単なルールに成功しました。この投稿では、旅程サービスとして使用でき、メッセージのコンテキストタイプに基づいた動的な変換のためにビジネスルールエンジンリゾルバーを利用できる、正常に動作するESBToolkit2.0対応のオーケストレーションを構成するものについて概説します。 。

旅程サービスのコンテキストサブスクリプション

まず、旅程サービスとして使用するように設計されたオーケストレーションには、次のようにESB対応のサブスクリプションを定義する受信シェイプにリンクされた直接バインドされた論理ポートが必要です。

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"

ドキュメントにはこれについては記載されていませんが、これにより、直接バインドされたポート操作をSystem.Xml.XmlDocumentタイプのメッセージにマップする必要があることが明確になります。実際、そうでない場合、オーケストレーションは実行に失敗し、ルーティング失敗エラーメッセージがメッセージボックスに登録されます。

ちなみに、これはメッセージの種類そのものがまったく考慮されていないことを意味します。そしてこれは、オーケストレーションの実行後、ビジネスルールエンジンリゾルバーが正しい変換を決定できない理由を主に説明しています。

旅程を取得する

オーケストレーションの開始時に式シェイプに含まれる次のコードは、現在の旅程ステップを取得するのに役立ちます。

// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);

元のメッセージのコンテキストを保持する

次に、オーケストレーションの各ステップで、元のメッセージのコンテキストを（ほとんどの場合）保持する必要があります。これは、手元にある特定のシナリオを実行するためにオーケストレーションにいくつかの中間構造の形状がある場合に特に重要です。

OutboundMessage(*) = SourceMessage(*)

上記の文に「大部分」と書いていることに注意してください。実際、すぐにわかるように、結果のメッセージのタイプは、オーケストレーションの最後のコンテキストに存在する必要があります。ほとんどの場合、これは元の受信メッセージとは異なるタイプになります。また、読み取り専用のBTS.MessageTypeプロパティに割り当てることはできないため、これを実現するのは非常に難しい場合があります。

これを実現するには、オーケストレーション内でカスタムパイプラインを実行するか、他のエキゾチックな手法を実行する必要がある場合があります。ただし、ほとんどの場合、上記の構文は機能するはずです。

旅程を進める

次の非常に単純なコードは、オーケストレーションの最後に忘れてはなりません。

itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);

コンテキストプロパティのプロモート

ドキュメントには、従う必要のある正確な手順が明確に記載されていません。また、プロパティをそのようなオーケストレーションから昇格させる必要がある場合でも、ソースコードとして提供されているサンプルを見ると、次のプロパティが解決に参加していることがわかります。機構：

プロパティのプロモートhttp://public.blu.livefilestore.com/y1pLURN1zH2vdRuLcF5yyAiHZQQ9rkdlrqG-QH01Nn8hEY5zH1W9TjjtNc0Z9421eFC2gUVG-srs2-NdcliI3XD1w/orchestration_service

ただし、この投稿で概説されているシナリオでは、これは間違いなく十分ではありません。

オーケストレーション後にコンテキストベースのルールを機能させるには、BTS.MessageTypeプロパティもプロモートする必要があります。これは、オーケストレーションの最後に送信シェイプの相関を初期化することで簡単に実現できます。

メッセージタイプの相関関係http://public.blu.livefilestore.com/y1pQb-dkmbNBcur7CwdyudiIE9EMKGnZ0LoGuFpfDLseAWsiUz9C1EC1ZR5pn0gI4tgr3syEN2y-cfPB9EgEzlgtA/message_type_correlation.png?psid

そしてそれは動作します！

結果のメッセージのコンテキストでメッセージタイプを宣伝することは、私の最初の試みでは欠けていたものでした。これが特定されると、旅程は魅力のように機能しました！

ルール発火ログhttp://public.blu.livefilestore.com/y1pGVViJM7SFbopcnYODHkqGUbkgS1RQR8a7ASVsNVDu8Krdhb_Vyj4PugbMPSFcfMEZ1P_3a7It0QQpXdF_dnvDg/rule_firing_log.png？

事後に解決策は明白に見えるかもしれませんが、私が以前にそれを知っていたならば、それは確かに私を助けたでしょう。この投稿が同じ問題を抱えている人たちに役立つことを願っています。

于 2010-06-15T17:44:01.907 に答える