質問

BizTalk ESB ツールキット 2.0 の使用

私たちは、DLL である Web サービスへのプロキシを呼び出す必要があるプロジェクトに取り組んでいます。静的ポートを使用し、BizTalk 管理インターフェイスのアセンブリを指す Web サービス設定で SOAP アダプターを使用するように構成できるため、オーケストレーションを介してこれを実行することに問題はありません。ただし、動的ポートには SOAP アダプターを使用するオプションがないため、旅程ではこれを行う明確な方法はないようです。

これを行うのには十分な理由があります。心配しないでください。

これに続いて、カスタム アダプター プロバイダーを実装しましたが、動作させるのに問題が発生しています。

ここで示した (古い) 例に従いました ここ:

カスタム アダプター プロバイダーは BaseAdapterProvider を継承し、SetEndPoint(Dictionary, IBaseMessageContext) メソッドをオーバーライドします。

このメソッドは、リゾルバー ディクショナリ経由で渡されるアセンブリ名、型名、およびメソッド名を抽出し、それらをパイプライン コンテキストに書き込みます。

pipelineContext.Write("TypeName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName", 
   "http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);

そして、トランスポート タイプを SOAP に設定します。

pipelineContext.Write("TransportType",
    "http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");

その他すべての点では、アダプター プロバイダーは、SMTP から SOAP への明らかな変更を除いて、上記のリンクに示されている例とほぼ同じです。

アダプター プロバイダー アセンブリは署名され、GAC を受けて、esb.config に追加されます。

アダプター プロバイダーは、サービスを呼び出して応答を返すだけの行程から呼び出されます。ツールキットに同梱されている旅程テスト クライアントから旅程をテストしています。カスタム アダプター内のイベント ログには、アダプター コードが呼び出されていることが示されます。問題は、メッセージがサービス プロキシにルーティングされていないことです。イベント ビューアでは次のエラーが表示されます。

メッセージングエンジンは、Adapter:SOAPソースURL:/esb.itineraryservices.response/processitinerary.asmxによって送信されたメッセージの処理に失敗しました。詳細:購読者が見つからなかったため、公開されたメッセージをルーティングできませんでした。このエラーは、購読オーケストレーションまたは送信ポートが入隊していない場合、またはサブスクリプション評価に必要なメッセージプロパティの一部が宣伝されていない場合に発生します。BizTalk Administration Consoleを使用して、この障害をトラブルシューティングしてください。

グループ概要で一時停止されたサービス インスタンスを調査すると、次の 2 つのことがわかります。アセンブリ名、型名、メソッド名の値が正しく設定されています。メッセージ本文がありません。送信ポートの送信パイプラインと受信パイプラインを XMLTransmit/XMLReceive と ItinerarySendPassthrough/PassthroughReceive の両方になるように構成してみましたが、違いはありません。

私たちが見落としている可能性がある明らかな何かがあるでしょうか?メッセージ本文を明示的に渡す必要がありますか?もしそうならどうやって?

編集:

次の BizTalk ESB ツールキット フォーラムからのリクエスト 旅程、コンテキスト、送信ポートフィルターのスクリーンショットを投稿しています。

旅程, コンテクスト, ポートフィルター.

ありがとう、ナイジェル。

役に立ちましたか?

解決

まず第一に、あなたはソリューションを過剰に設計しようとしていると言いたいと思います。アダプターの開発は簡単ではなく、考慮する必要があるさまざまな点があります。アダプターの開発とデプロイは、環境全体に影響を与えるプラットフォームの変更として分類されるため、慣れていない場合は実行しないでください。他のルートを取ることをお勧めします。現時点では、私個人としては ESB の内部について十分な洞察を持っていないため、それについてコメントすることはできません。最悪の場合、アダプターを構築するよりも、オーケストレーション (式またはメッセージ シェイプ) 内で .NET プロキシ DLL を直接使用した方が良い場合があります。推奨されていないアプローチではありますが、それでもカスタム アダプターのアプローチよりも優れていると感じます。

他のヒント

意味的には、WCF-BasicHtpp アダプターを含むソリューションがシナリオで機能しない理由がわかりません。いずれにせよ、WCF-BasicHttp アダプターで何が起こるかを試してみて、有効な解決策が得られたら、本当に必要な場合はカスタム SOAP アダプターに切り替えるつもりです。

現在、あなたのソリューションは奇妙です - オフランプに直接接続されたオンランプがあるという意味です。私の旅程ではそんなことは一度も見たことがありません。場合によっては、中間メッセージングまたはオーケストレーション旅程サービスを間に作成する必要があります。

それ以外の場合、メッセージは実質的にメッセージ ボックスに発行され、明らかにそのメッセージの購読者が存在しないため、エラーが発生します。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top