問題タブ [custom-pipeline-component]

パイプライン内の (読み取り/書き込み) 文字列からすべての先頭および末尾のスペースを削除する非常に単純なコンポーネントがあります。私が見る限り、開発マシンにはこの dll のバイナリが 1 つしかありません。別の開発マシンに転送して GAC に登録していますが、2 台目のマシンにコピーしたパッケージを開くと、次の警告が表示されます。

エラー 1 検証エラー。データ フロー タスク: DTS.Pipeline: "コンポーネント "TrimColumnsComponent" (1909)" のコンポーネント メタデータを新しいバージョンのコンポーネントにアップグレードできませんでした。PerformUpgrade メソッドが失敗しました。LD_CXSUM.dtsx 0 0

ツールボックスにコンポーネントがあり、別のコンポーネントをデータフロー キャンバスにドラッグできますが、問題はないようです。

これは、両方のマシン上の SQL Server 2005 と Visual Studio 2005 です。

2 番目のマシンでは、パッケージを最初から作成でき、コンポーネントをビルドしたマシンに読み込まれます (ただし、アイコンは、2 番目のマシンと同じ標準のユーザー コンポーネント アイコンです)。ビルド マシンで最初からパッケージを作成すると、正しいアイコンが表示されますが、非ビルド マシンではアップグレード メッセージが表示されます。ファイルは components ディレクトリで同一であり、同じコンポーネント クラス ID を持ち、GAC に登録されています。

XML を調べて手動で dtsx ファイルを確認しましたが、ビルド マシンと非ビルド マシンで作成されたパッケージでは、クラス ID と公開キーがマシン間で同一です。

何が原因でしょうか?

BizTalk Server (2006 および 2009) で受信パイプライン用のカスタム パイプライン コンポーネントを構築しています。コンポーネントをストリーミング方式で構築しています。

私の質問: 単一の受信メッセージについて、逆アセンブル コンポーネントがある場合、単一の受信メッセージから n 個のメッセージを作成すると、(本文) ストリームを読み取り、メッセージをメッセージに永続化するときに、メッセージ エージェントは常に単一のスレッドを使用しますか?箱？私はそう思いますが、確認は役に立ちます。

逆アセンブラーで 5 つのメッセージを作成した場合、これらのメッセージのいずれかが同じスレッドから順番に永続化されるでしょうか? または、これらのメッセージを並行して処理できますか?

メッセージを受け取り、追加の別のパーツを動的にアタッチするカスタム パイプライン コンポーネントを作成しようとしました (逆アセンブル ステージ中)。BizTalk が何を処理しようとしているのかを確認できるように、送信ポートを設定していません。体の部分しか見えず、追加部分は見えません。これは私が使用したコードです：

ありがとうございました。

テキストを含むストリームがあり、そのストリームの一部のテキストを編集 (一部の値を置換) したいと考えています。

ストリームを壊さずにこれを行う最も効率的な方法は何ですか? のカスタム パイプライン コンポーネントでこれを使用したいと考えていますBizTalk。

これはコードですが、ご覧のとおり、実行するとストリームが中断されますsr.ReadToEnd()。

これを行うより良い方法はありますか？

メッセージを 2 つのメッセージに分割するカスタム パイプライン コンポーネントを作成することは可能ですが、送信ポート内にありますか? 逆アセンブラー インターフェイスを使用して受信ポートで可能であることがわかりましたが、これを送信パイプライン コンポーネントで使用できますか? 誰かがこれを達成する方法の例を教えてもらえますか?

どうも

BizTalk 用のカスタム パイプライン コンポーネントがあり、(プロパティ ウィンドウから) いくつかのプロパティを設定できます。プロパティの 1 つは、Windows フォーム (ユーザーが値を追加できる場所) を利用します。問題は、ユーザーがビジュアルスタジオから何かをコピーしたい場合、最初にウィンドウを閉じ、テキストをコピーしてからウィンドウを再度開く必要があることです。これは、Windows フォームの外側をクリックできないためです (Visual Studio 内で動かなくなっています)。Visual Studio からテキストを選択できるように、これを修正する方法はありますか? 多分ウィンドウスタイルなどを変更しますか？

どうも

構成可能な値をSSOに保存し、実行時にカスタムパイプラインコンポーネントで取得する必要があります

これに関する助け...

これが私のシナリオです。BizTalk は、共有/中央ドキュメント ライブラリからファイルを転送する必要があります。まず BizTalk は、ライブラリ内のこのドキュメントへの参照/パスを含む受信メッセージを受信します。次に、このライブラリからそれを読み取って送信する必要があります (場合によっては別のアダプターを介して)。これは本質的に、ClaimCheck EAI パターンからそれほど離れていないシナリオです。

クレーム チェックを実装するいくつかの方法が文書化されており、特にBizTalk ESB ツールキット クレーム チェックと BizTalk 2009: 非常に大きなメッセージの処理、パート I およびパート IIです。ただし、これらの実装では、送信パイプラインが「チェックイン」されたストリームをすぐに読み取ることができるという前提があります。</p>

これは私の場合ではありません。ドキュメントが共有ライブラリで利用可能になるまでには時間がかかるため、最初に受信したメッセージを遅らせることはできません。つまり、オーケストレーションを介して遅延を導入するか、ドキュメントがまだ存在しない場合に送信ポートが後で再試行されるようにするかの 2 つのオプションがあります。

(遅延はオーケストレーションによってのみ導入できます。BizTalk には時間ベースのサブスクリプションはありません。そうですか?)

これはメッセージのみのフローなので、オーケストレーションをスキップできると思います。「パイプラインを使用したメッセージのみのソリューションでカスタム再試行ロジック」を使用する方法を見てきましたが、必要なのは、(アダプターによって実行される) 再試行動作を制御する方法だけでなく、パイプライン内からそれを強制する方法でもあります。 …</p>

これまでに行ったすべての試みは、送信アダプターに再試行が構成されていても、自動的に再試行されない中断されたメッセージで終わりました...これが実際に可能である場合、どこで/何をすべきですか?

そうそう…そして待ち行列があります…残念ながらオンプレミスでもクラウドでもありません;）

OK、私は限界を押し広げているかもしれません…しかしただの好奇心から…</p>

あなたの助けと提案に感謝します！

BizTalk 展開フレームワーク (BTDF) を使用してプロジェクトを展開していますが、そのプロジェクト内にパイプライン コンポーネントがあります。コンポーネントは、BizTalk インストールのパイプライン コンポーネント フォルダーにある dll を正常に展開しているように見えます。ただし、ツールボックスには表示されず、ツールボックスをリセットしようとするとVS2010がクラッシュし、コンポーネントが削除されるまで再起動しません...

他の誰かがこのようなものに出くわしますか?