位置ベースのデータを txt 形式で受け取る必要があります。
レコードの最初の 2 文字は、メッセージの種類を識別するのに役立ちます。
いいえ、40 以上のメッセージ タイプがあるため、メッセージ タイプに基づいて、受信パイプラインで xsd を取得する必要があります。
実行時にパイプラインで xsd を動的に取得する最良の方法は何ですか?
位置ベースのデータを txt 形式で受け取る必要があります。
レコードの最初の 2 文字は、メッセージの種類を識別するのに役立ちます。
いいえ、40 以上のメッセージ タイプがあるため、メッセージ タイプに基づいて、受信パイプラインで xsd を取得する必要があります。
実行時にパイプラインで xsd を動的に取得する最良の方法は何ですか?
短い答え
必要なのは、組み込みのフラットファイルコンポーネントのインスタンスをホストするが、 IProbeMessageインターフェイスも実装するカスタムフラットファイル逆アセンブラコンポーネントを作成することです。
このインターフェイスを使用すると、BizTalkランタイムは、受信パイプラインの逆アセンブル段階でいくつかのコンポーネントから選択できます。
このカスタムパイプラインのいくつかのバージョンを使用することで、利用可能なフラットファイル.XSDスキーマごとに1つずつ使用することができます。
残念ながら、このソリューションはすぐにメンテナンスの悪夢とパフォーマンスの問題になります。したがって、さらに一歩進んで、使用するフラットファイルスキーマを動的に選択する単一のコンポーネントを構築することをお勧めします。
このためには、IProbeMessageの実装を駆動するプラグインシステムを構築する必要があります。プラグインの各インスタンスは、正しいフラットファイル.XSDスキーマを返し、受信したメッセージの入力ストリームで形式が一致するかどうかをチェックするように構成されます(おそらく最初の数バイトに基づいて)。次に、カスタムパイプラインコンポーネントは、メッセージが認識されてフラットファイルの.XSDスキーマが返されるまで、そのIProbeMessage実装をさまざまなプラグインに委任します。
長い答え
ここで長い答えを再現することもできますが、ブログに書いた次の一連の記事をご覧ください。これらの投稿では、上記で説明したのとまったく同じ手法を使用して、実行時に使用するフラットファイル.XSDスキーマを動的に解決するカスタムフラットファイル逆アセンブラーコンポーネントの実装について説明します。
ここから始めてください:
タグ識別子と呼ばれるプロパティがありますが、それがあなたのシナリオに当てはまるとは思えません。私がやろうとしているのは、パイプライン コンポーネント (逆アセンブル ステージ) のどこか (データベースまたは BRE) にメッセージ タイプ マッピング テーブルを維持することです。メッセージ。
これは多くの方法で行うことができます。
フラット ファイル スキーマ ウィザードでタグ識別子を使用します。2 文字のフィールドを定義し、タイプを設定して、40 種類すべてのメッセージ構造を定義します。タグ識別子によってそれらが整理されます。
マルチパート/エンベロープメッセージとして行うことができます。最初の部分は 2 文字の識別子 (メッセージ タイプ) で、もう 1 つはメッセージの残りの部分です。フラット ファイル パイプラインを使用して、入力をメッセージに変換します。タグフィールドを昇格させてください。次に、タグ付きの最初のメッセージ部分を使用して、各タイプの正しいマップを選択できます。メッセージタイプが変更されることが予想される場合は、これがはるかに優れています。