マップのトラブルシューティング

このトピックでは、マップのトラブルシューティング戦略と問題の詳細と解決に関する情報を提供します。

トラブルシューティング戦略

これは明白に思えるかもしれませんが、開発を通じて異なるポイントでマップを常に検証する必要があります。これにより、開発サイクルの早い段階で、設計、ロジック、およびスキーマの問題を特定するのに役立ちます。問題を修正したり、別のソリューションを見つけたりする方が簡単です。

注

マップを検証するとき、テストインスタンスデータはスキーマで定義されたデータ型に違反しているかどうかはチェックされません。 BizTalk エディターでマップをテストしたり、インスタンスデータを検証したりするときに、インスタンスデータを確認できます。

多くの場合、マップコンパイラによって生成された XSLT を検査すると便利です。 XSLT を検査する利点には、次のようなものがあります。

ループまたはカスタム Functoid を使用している場合は、ループの実行方法とカスタム Functoid の呼び出し方法について理解を深めます。
複雑なマップがある場合は、XSLT を確認すると、マップが変換にどのように変換されるかを確認でき、1 つまたは複数のパーツの構造、置換、または合理化を改善する方法についての洞察が得られる場合があります。
カスタムスクリプトまたはその他の成果物を使用している場合は、XSLT を確認すると、マップのスクリプト、成果物、およびその他の部分がどのように相互作用するかを確認できます。

幸い、マップの XSLT の表示は簡単なプロセスです。

Visual Studio BizTalk プロジェクトで、[ ソリューションエクスプローラー ] タブをクリックし、マップを右クリックして、[マップの検証] をクリックします。
[出力] ウィンドウをスクロールして、XSL ファイルの URL を見つけます。 Ctrl キーを押し、URL をクリックしてファイルを表示します。

マップを手動でカスタマイズする場合は、マップコンパイラによって生成されたバージョンを変更できます。変更はマッパーによって反映されず、次回ソリューションをビルドするときに失われます。

Mapsource 要素の属性をマップソース (.btm) ファイル内で直接変更することで、Mapper の既定の動作をいくつか変更できます。現在、次の 3 つの動作を変更できます。

値マッピング Functoid コード生成を最適化します。変数を if ステートメントで使用するタイミングを制御する動作を変更できます。
フットプリントが大きいスキーマを対応させる。大規模なマップで内部コンパイラノードを使用する方法を変更できます。
ループ、条件付き、および値マッピング Functoid を使用して、for-each 使用法を管理します。 xsl:for-each ステートメントを送信先スキーマ内で使用する場所を制御できます。

mapsource の変更の詳細については、「<mapsource を使用した既定のマッパー動作の管理>」を参照してください。