問題タブ [esb-toolkit-2.0]

BizTalk ESBToolkit2.0の使用

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

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

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

ここに示す（古い）例に従いました：

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

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

トランスポートタイプをsoapに設定します。

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

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

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

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

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

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

編集：

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

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

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

IIS にある asmx サービスにアクセスしようとしています。asmx は統合セキュリティを使用しています。ESB ガイダンス 1.0 内で構成された wcf-basichttp アダプターを使用して呼び出そうとしています。

私が得ているエラーは次のとおりです。

HTTP 要求は、クライアント認証スキーム「匿名」では許可されていません。サーバーから受信した認証ヘッダーは「NTLM」でした

エンドポイント構成で設定しようとしました：

どんなアイデアでも評価されます

オーケストレーション内から動的な旅程ルーティングを実行しようとしています。提供されている ItinerarySelectReceiveXml reveive ポートと同様に、受信パイプラインを呼び出して、特定のメッセージの旅程を解決し、ESB ルーティング用の直接バインドされたポートに送信します。セットアップは、ComposedMessageProcessor BizTalk サンプルに似ています。

ESB Itinerary Select パイプライン コンポーネント (ResolveParty ステージ) を除いて、受信パイプラインは ItinerarySelectReceiveXml とまったく同じです。接続文字列と ItineraryFactName をハードコーディングしました (例: BRI:\policy=MyResolveItineraryRule;useMsg=true)。 ;recognizeMessageFormat=true; および Resolver.Itinerary) を使用することで、ループバック アダプターを使ってトリックを実行したり、余分なメッセージ ボックスへのアクセスを発生させたりする必要がなくなります。

式の形状から受信パイプラインを呼び出すコードは次のようになります。

// ルーティングしたい最初のメッセージは、着信メッセージの単なるノードです

これはかなりうまくいきます。メッセージ タイプの正しい旅程が SQL プロファイラーを使用して解決されていることがわかります。一般的な旅程のオンランプを使用してこのメ​​ッセージ タイプに使用しているため、旅程が適切であることがわかります。

しかし、Microsoft.Practices.ESB.Itinerary.PipelineComponents.ItinerarySelector の直後にある Microsoft.Practices.ESB.PipelineComponents.Dispatcher から例外が発生しています (パーティーの解決段階で)。

ドキュメントには、ESB 旅程セレクター パイプライン コンポーネントが、correlationToken、reqRespTransmitPipelineID、interchangeId、receiveInstanceId、epmRRCorrelationToken のプロパティを使用して、旅程の Microsoft BizTalk Server セグメントを設定する必要があると記載されています。

例外は次のようになります。

値を null にすることはできません。パラメータ名: exchangeId

ソース: Microsoft.Practices.ESB.PipelineComponents.Dispatcher

メソッド: Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext, Microsoft.BizTalk.Message.Interop.IBaseMessage)

エラー ソース: Microsoft.Practices.ESB.Itinerary.OM.V1

エラー TargetSite: System.Object[] GetItineraryDataForBAM(Microsoft.Practices.ESB.Itinerary.OM.V1.Itinerary, Microsoft.Practices.ESB.Itinerary.IItineraryStep, System.String)

エラー StackTrace: Microsoft.Practices.ESB.Itinerary.OM.V1.BAMItineraryProcess.GetItineraryDataForBAM(Itinerary itinerary, IItineraryStep step, String exchangeId) で Microsoft.Practices.ESB.Itinerary.OM.V1.BAMItineraryProcess.SubmitToBAM(Itinerary itinerary, IItineraryStep) Microsoft.Practices.ESB.Itinerary.OM.V1.ItineraryV1.<>c__DisplayClassa.b__8() の Microsoft.Practices.ESB.Itinerary.OM.V1.ItineraryV1.AdvanceByOrder(ItineraryMessageDirection messageDirection, Microsoft.Practices.ESB.Itinerary.OM.V1.ItineraryV1.Advance(IBaseMessage メッセージ、IPipelineContext コンテキスト、IItineraryStep ステップ、Boolean AdvanceStep) の Microsoft.Practices.ESB.Itinerary の文字列 serviceInstanceId、IItineraryStep ステップ、Action submitToBam、Boolean AdvanceStep)。 OM.V1.旅程V1.Microsoft.Practices.ESB.PipelineComponents.Dispatcher.Execute (IPipelineContext コンテキスト、IBaseMessage msg) での Advance (IBaseMessage メッセージ、IPipelineContext コンテキスト、IItineraryStep ステップ)

どんな助けでも大歓迎です。

ps この質問は、ESB ツールキット フォームにも投稿しました。

私たちは Microsoft BizTalk Server 2009 に多額の投資を行い、すべての非同期作業にとって夢のように機能しています。しかし、私たちはそれを使ってより多くの同期作業を行いたいと考えており、それが私たちが ESB Toolkit 2.0 を真剣に検討している理由です。

しかし、私はこのツールキットで問題を次々と抱えており、私の直感では、エンタープライズ対応には達していないと感じています。言い換えれば、絶対に正しい順序でインストールする必要があるビットが多すぎて、うまくいかない可能性がある (そして実際に実行してしまう) ことが多すぎます。エラー、スペルミスのある例外メッセージなど。

その意見に共感する人はいますか？

このツールキットを本番環境で実際に使用している人はいますか? BTS 2006/2009 を入手したが、ESB Toolkit を使用しないことに決めましたか?

いくつかの意見を聞くことに本当に興味があります。

ありがとう

アンドリュー

着信メッセージをIISでホストされているWCFサービスにルーティングするESBToolkit2.0を使用できますか？WCFサービスにESBのコンテンツベースのルーティング、検証、および変換機能を使用することを考えています。

ありがとう

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

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

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

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

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

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

ESB例外管理（ESB Toolkit 2.1）を構成しようとしていますが、ESBExceptionDBを正常に作成した後、例外Webサービスを構成しようとしています。

[構成の適用]を押すと、「指定されたディレクトリサービスの属性または値が存在しません」というエラーメッセージが表示されます。

エラーログ：

私は何が欠けていますか？

私は「クラシック」BTSソリューションの実装に4年の経験を持つBTS開発者です。

明日、ESBツールキット2でサプライズプレゼンテーションを行う必要があります。理由は聞かないでください。なるべく準備をしていきたいと思います。すぐに吸収できるリソースを探しています。理想的には（重要度の大まかな順序で）：

1. 主な可動部品の技術概要
2. 実装の詳細、旅程の説明、リゾルバー、オンランプなどのいくつか。
3. インストールと展開。

迅速な支援をいただければ幸いです。

ユーザー名とパスワードのBAsic認証を期待するhrl https://xxxxx.comにPOSTする必要があります

Biztalk ESB 動的送信ポートを使用しています

バインド構成または動作を使用してこれを構成するにはどうすればよいですか、または UDDI からこれを設定できますか?

私は次のような旅程を持っています

メッセージを受信する UDDI (2 つのリゾルバーを含むメッセージング エクステンダー) を使用して 2 つのエンドポイントを解決し、次にオフランプ エクステンダー メッセージ エクステンダーを使用してマップを適用します (BRE を使用) オフランプ

私が探している結果は、2 つのメッセージ (どちらもまったく同じ) を、異なるマップが適用された 2 つの異なるエンドポイントに送信する必要があることです。

ただし、マップを解決するための BRE では、エンドポイント アウトバウンド ロケーションが空です

なぜこれが起こっているのか説明できますか

よろしくアルン