2

BizTalk ESBToolkit2.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 Source URL：/ESB.ItineraryServices.Response/ProcessItinerary.asmxによって送信されたメッセージの処理に失敗しました。詳細：サブスクライバーが見つからなかったため、公開されたメッセージをルーティングできませんでした。このエラーは、サブスクライブオーケストレーションまたは送信ポートが登録されていない場合、またはサブスクリプション評価に必要なメッセージプロパティの一部がプロモートされていない場合に発生します。この障害のトラブルシューティングには、Biztalk管理コンソールを使用してください。

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

私たちが見逃したかもしれない明らかな何かがありますか？メッセージ本文を明示的に渡す必要がありますか？もしそうなら、どのように？

編集：

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

旅程、 コンテキスト、 ポートフィルター。

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

4

2 に答える 2

1

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

于 2009-07-27T08:27:46.840 に答える
0

意味的には、WCF-BasicHtppアダプターを含むソリューションがシナリオで機能しない理由がわかりません。いずれにせよ、私は間違いなくWCF-BasicHttpアダプターで何が起こるかを確認しようとします。そして、実用的なソリューションが得られたら、それが本当に必要な場合はカスタムSOAPアダプターに切り替えます。

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

それ以外の場合、メッセージは効果的にメッセージボックスに公開され、明らかにそのメッセージのサブスクライバーがないため、エラーが発生します。

于 2011-01-17T08:20:44.763 に答える